Ahh, den 29 februar

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

Kommentarer (31)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Udby

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.

  • 6
  • 0
Jacob Christian Munch-Andersen

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.

  • 1
  • 1
Johannes Ulfkjær Jensen

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.

  • 0
  • 0
Esben Nielsen

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 :-(

  • 0
  • 0
Johannes Ulfkjær Jensen

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.

  • 2
  • 0
Jacob Christian Munch-Andersen

@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.

  • 1
  • 0
Johannes Ulfkjær Jensen

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?

  • 0
  • 0
Steen Eugen Poulsen

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.

  • 0
  • 1
Leif Neland

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.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize