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
- emailE-mail
- linkKopier link
- Sortér efter chevron_right
- Trådet debat
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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
- more_vert
- insert_linkKopier link
Jeg skulle bruge et Self-Signed cert til en IIS7.5.....
Fandt svaret her:
Bare sæt dato "korrekt".. :-)
/dan
- more_vert
- insert_linkKopier link
"Microsoft's Azure cloud down and out for 8 hours" - http://www.theregister.co.uk/2012/02/29/windows_azure_outage/
"We have identified the root cause of this incident. It has been traced back to a cert issue triggered on 2/29/2012 GMT".
- more_vert
- insert_linkKopier link
- more_vert
- insert_linkKopier link
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...
- more_vert
- insert_linkKopier link
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 :-))
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
Desværre maa jeg konstatere, at ingen af mine pensionsudbetalinger kom en dag for tidligt.
- more_vert
- insert_linkKopier link
- more_vert
- insert_linkKopier link
Ganske vist ikke specielt højteknologisk:
- more_vert
- insert_linkKopier link
Ganske vist ikke specielt højteknologisk:</p>
Er der overhovedet noget der ikke kommer bag på DSB?
<p>Den 29. kom bag på DSBs klippeautomater
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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 :-)
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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 :-(
- more_vert
- insert_linkKopier link
Jeg antager du svarer mig, men det er lidt svært at vide når du ikke quoter indhold.Hvad er det du skal regne på tid i lokal tid for? Lokalt tidspunkt af dagen kan være meget interessant.
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.
- more_vert
- insert_linkKopier link
@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.
- more_vert
- insert_linkKopier link
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?
- more_vert
- insert_linkKopier link
Hvordan vil du repræsentere skudsekunder i Unix UTC?
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
Men kun for de som følger den gregorianske kalender. Der er vist stadig nogle enkelte som følger den julianske.
- more_vert
- insert_linkKopier link
Der er vist stadig nogle enkelte som følger den julianske.
Ja astronomer er glade for den julianske. Et lysår er f. eks. den afstand lys rejser på et juliansk år (265.25 dage) i et vacuum.
Maagaard skrevet 2455986.86600 (Julian Date)
- more_vert
- insert_linkKopier link
Et lysår er f. eks. den afstand lys rejser på et juliansk år (265.25 dage) i et vacuum.
Arrgh dumme fingre det er 365.25 på et juliansk år.
Maagaard
- more_vert
- insert_linkKopier link
arh, det må være et andet stof end vacuum, der jo forresten må være grundstof nummer 0......
- more_vert
- insert_linkKopier link
- bør vel opstå den 24.,da det er skuddagen?
- more_vert
- insert_linkKopier link