Dette indlæg er alene udtryk for skribentens egen holdning.

Ahh, den 29 februar

31 kommentarer.  Hop til debatten
Blogindlæg29. februar 2012 kl. 08:28
errorÆldre end 30 dage

Normalt er det skudsekunder jeg brokker mig mest over, men det er altid underholdende når d. 29 februar dukker op.

F.eks skulle jeg idag logge ind på både ing.dk, version2.dk og forskellige andre hjemmesider uden for tur, skal vi gætte på at der er noget cookie-timeout-fræs der ikke helt virker med en ekstra dag i Februar ?

Kom med dine skuddags-bugs i debatten...

phk

31 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
29
29. februar 2012 kl. 19:28

Er det ikke os nørder der ikke har fattet en meter af en måned frem?

Hvis datoen er 13 Feb kl 13:13:13 så er en måned frem 13 Marts 13:13:13. Du lægger bare en til måned.

Der hvor en måned frem er noget frygteligt rod er når det er sidste dag i en måned med flere dage en den måned du flytter til.

Jeg vil tro mange computer folk begår den fejl at en måned frem i den situation bliver til to måneder frem (1. 2. 3. I måneden after, den du løb tør for dage i), men det er så igen en fejl fordi du gerne vil havde 1 måned til at være et tal, men det er det jo ikke så en måned frem må altid være en dag i den næste måned (den sidste hvis du løber tør for dage).

år/måned frem eller tilbage i tiden er ikke et tal, men en formular og du kan derfor ikke oversætte det til sekunder.

28
29. februar 2012 kl. 18:27

select sysdate - interval '1' year from dual; giver ORA-01839: date not valid for month specified

select add_months (sysdate, -12) from dual; giver 28-FEB-2011

20
29. februar 2012 kl. 13:15

Ny bugreport: Datoselector får app'en til at crashe. Forventet opførsel: Dataselector vises med dags dato.

Efter lidt testarbejde var resultatet:

  • Samsung Galaxy S: Crasher med IllegalArgumentException
  • Sony Ericson Experia: Viser 30. februar 2012
  • Google Nexus S: Virker som forventet.

Suk...

26
29. februar 2012 kl. 17:06

Det er da meget logisk med SonyEricsson - 30/feb kan jo være en lovlig dato i sverige (vel, én gang i 17-hundrede og hvidkål :-))

18
29. februar 2012 kl. 12:44

Jeg har en fast kontooverførsel kørende på "månedsultimo" i min netbank hos en af sparekasserne.

Den blev kørt d. 28. februar og ikke d. 29., som den egentligt skulle når der var gået løn ind.

16
29. februar 2012 kl. 11:37

Desværre maa jeg konstatere, at ingen af mine pensionsudbetalinger kom en dag for tidligt.

11
29. februar 2012 kl. 10:12

Så kunne det jo være fint med et link til et writeup af diverse fælder man kan hoppe i. Det bedste jeg kunne finde var dette på Stackoverflow men det handler nærmest udelukkende om zoner.

5
29. februar 2012 kl. 09:32

og bug eller ej men for mange år siden troede konen at hun skulle have 12 par handsker, og jeg hørte ikke helt efter hvad hun sagde, mumlede bare ja ja - og bum så klappede fælden :-)

4
29. februar 2012 kl. 09:20

Oversæt kun fra Unix UTC når tiden skal vises til brugeren, så er det værste der kan ske at tiden bliver vist forkert.

De fleste anvendte programmeringssprog har nu om dage ganske god tidshåndtering, så egentlig tror jeg ikke at vi ser særligt mange fejl. Men selv det bedste bibliotek kan selvfølgelig ikke forhindre at nogen har skrevet noget klump.

30
29. februar 2012 kl. 23:22

Oversæt kun fra Unix UTC når tiden skal vises til brugeren, så er det værste der kan ske at tiden bliver vist forkert.

Slightly OT:

Firmaer, der skriver telefontider på deres hjemmeside, og regner med at have andet end lokale kunder, bør skrive det lokale klokkeslet også.

Det er frustrerende at få at vide at der er åbent 9AM til 4PM, og man så skal til at finde ud af, hvilken tidszone firmaet er i, og om der er forskellige sommertider her og der. Så et lille (It's now 2:31AM here) ville være til stor hjælp.

7
29. februar 2012 kl. 09:45

Oversæt kun fra Unix UTC når tiden skal vises til brugeren, så er det værste der kan ske at tiden bliver vist forkert.

Kun og kun. Ofte er det også nødvendigt at have tid i den tiltænkte zone før man med rimelighed kan regne på det. Meget beregning af tid handler om andet end at addere et antal sekunder til et timestamp. Specielt når vi snakker zoner som Europe/Copenhagen.

12
29. februar 2012 kl. 10:29

Hvad er det du skal regne på tid i lokal tid for? Lokalt tidspunkt af dagen kan være meget interessant.

Jeg er bare nysgerig, for jeg er godt nok efter folk som vil oversætte til "menneske tid" (måned, år, dag, timer, minutter, sekunder), når tidstempler skal gemmes eller sendes over netværk, frem for bare at flytte UNIX sekunder + evt. milli- el. nanosekunder. Det første er måske mere menneskelæseligt, men meget sværere at parse op. Og så er der problemer med være enige om tidszonen.. Men desværre siger mange standearder, at man skal bruge det første :-(

14
29. februar 2012 kl. 10:52

Hvad er det du skal regne på tid i lokal tid for? Lokalt tidspunkt af dagen kan være meget interessant.

Jeg antager du svarer mig, men det er lidt svært at vide når du ikke quoter indhold.

Det er alle tilfælde hvor du ikke kan koge det ned til læg X sekunder til. F.eks. kan en specifikation sige at noget skal ske "1 måned efter" et andet tidspunkt, hvor det er implicit at vi er i Europe/Copenhagen. Det giver en del problemer:

  • Hvor mange dage er der i en måned ? (28/29/30/31)
  • Hvor mange timer er der i en dag ? (vintertid/sommertid)
  • Hvor mange leap seconds er der i et minut?

Nogle af disse informationer kommer fra bl.a. zonen. Og de er nødvendige for at kunne finde en UTC tid, som jo er det man gemmer sine tidsdata i.

17
29. februar 2012 kl. 12:07

@Johannes Ulfkjær Jensen Man skal selvfølgelig bruge tidszonen engang imellem, men den behøver ikke at være indregnet i datostemplet. Hvis du så vil lave en operation hvor tidszonen gør en forskel må du først lægge den til, sværere er det ikke.

"1 måned efter" er i øvrigt en tidsangivelse som det uanset om man kender tidszonen ikke er muligt at give en ordentlig definition af.

Ser du fx. på forvaltningsret vil du finde at praktisk talt alt er angivet i dage. Så jo, at lægge et antal sekunder til er næsten altid hvad man har brug for.

19
29. februar 2012 kl. 12:55

Man skal selvfølgelig bruge tidszonen engang imellem, men den behøver ikke at være indregnet i datostemplet

Det har jeg vist heller ikke sagt.

Ser du fx. på forvaltningsret vil du finde at praktisk talt alt er angivet i dage. Så jo, at lægge et antal sekunder til er næsten altid hvad man har brug for.

Dit eksempel og din konklusion hænger jo ikke sammen. Under antagelse af at 1 dag betyder: næste dag, samme tidspunkt... hvordan er det helt præcist du vil finde ud af hvor mange sekunder du skal lægge til nu når en dag ikke er et fast antal timer hele året i Europe/Copenhagen?

6
29. februar 2012 kl. 09:33

Hvordan vil du repræsentere skudsekunder i Unix UTC?

2
29. februar 2012 kl. 08:51

Sad hos en kunde for præcis 12 år siden. De havde gjort meget ud af at være år-2000 parate.

Men, den 29. feb 2000 havde alle problemer med at logge på deres mainframe...

Uden i øvrigt at kende detaljerne, så var historien at en eller anden havde gjort sig meget umage med det der med skudår og antal dage i februar. Vedkommende havde husket de 2 første regler og glemt den sidste: hvert 4. år men ikke hvert 100. år men alligevel hvert 400. år.

Problemet blev løst i løbet af dagen, men der må være nogen der har siddet med meget røde ører.

9
29. februar 2012 kl. 09:49

arh, det må være et andet stof end vacuum, der jo forresten må være grundstof nummer 0......

1
29. februar 2012 kl. 08:50
  • bør vel opstå den 24.,da det er skuddagen?