1234567890

"Akkurat nå" er et historisk sekund. Nå er nemlig klokka nøyaktig 1234567890!

I dataverden er det viktig å telle sekunder, men det ville blitt litt vel mange om en skulle begynt å telle ved Kristi fødsel. 2000 år med sekunder, blir et uhensiktsmessig stort tall. En bestemte seg derfor rett og slett for å lage en helt ny tidsregning til bruk i dataverdenen. Denne heter Unix time, Posix time, eller Unix epoch om du vil, og i dataverdenen snakker en ofte om et (Unix) tidsstempel.

Det er mulig du leser dette for sent til å overvære hendelsen, men med "akkurat nå" menes i det sekundet dette innlegget ble publisert. Dette er en sannhet med modifikasjoner, fordi innlegget ble publisert den 14.februar 2009 kl 00:31, uvisst nøyaktig på hvilket av de 60 sekundene i minutt 31. På dette tidspunktet sov jeg forresten, men jeg fikk til å publisere sånn omtrentlig på Unix-tidspunktet 1234567890 rett og slett takket være Unix time! [1]

Unix time fungerer på følgende måte:

• "Klokka" startet på tallet 0 den 1.januar 1970 (UTC-tid)
• Hvert sekund øker tallet med 1, så den 2.januar 1970 var Unix time blitt 60 sekunder x 60 minutter x 24 timer = 86.400. Unix time øker altså med 86.400 hvert døgn.
• Det tas ikke hensyn til såkalte Leap Seconds [2]. Leap seconds er juksesekunder som legges til våre vanlige klokker (dvs atomklokkene) for å justere tiden slik at den er helt i synk med jordrotasjonen. Unix time har altså ikke slike juksesekunder, og sakker dermed etterut sammenliknet med vår tid...

Akkurat nå (når dette innlegget ble publisert) er altså klokka 1234567890, eller 1.234.567.890 for å tydeliggjøre hvor stort dette tallet er. Altså litt over 1 millliarder. Eller 14.februar 2009 kl 00:31:30 sagt på forståelig norsk!

Hvis Unix time øker hvert sekund, når passerte da Unix time 1.000.000.000? Det skjedde den 9.september 2001 og ble feiret av datafolk verden over, blant annet en kollega. Hendelsen medførte også problemer. Noen datasystemer taklet nemlig ikke at tiden passerte 999.999.999. Vi støter nok på et nytt problem i januar 2038, for da er grensen nådd for hvor stor Unix-tallet kan bli for de systemer som har avsatt "bare" 32 bits til klokkeinformasjonen. Et 32-bits tall representert binært, kan bare bli en viss størrelse stort, og denne størrelsen er antall sekunder som forekommer på ca 136 år. Fra 1970 til 2038 er det 136 år? Nei, det er det ikke, men hvis du går like langt bakover i tid (noe mange datasystemer gjør) så blir det totalt 136 år. Fra 1970 til 2038 er det nemlig 136/2 = 68 år, og fra 1970 til 1901 er det også ca 68 år. Spennet går nøyaktig fra 13.desember 1901 til 19.januar 2038, og er på ca 136 år. Hva som typisk vil skje når den binære representasjonen av 2038 nås, er vist i figuren under (hentet fra Wikipedia)

Det er lett å regne med sekunder. I programmeringsspråk fins det en rekke funksjoner for å omgjøre fra et Unix tidsstempel til det tilsvarende tidspunktet i vanlig datoformat, og omvendt. Selv liker jeg best PHP som språk, og da kan du for eksempel finne ut hvilken dato det er nøyaktig 8 uker fra nå av. I PHP brukes da funksjonene time() og date(), slik:

  $datoenOm8Uker = time() + (7 * 8 * 24 * 60 * 60);
  echo 'Nå er det den:       '. date('d-m-Y') ."\n";
  echo 'Om 8 uker er det den: '. date('d-m-Y', $datoenOm8Uker) ."\n";

Poenget er at funksjonen time() returnerer tidsstempelet som er akkurat nå (hos tjeneren der PHP-programmet utføres). Dette er altså et tall som er antall sekunder siden 1.januar 1970. For å få datoen 8 uker fram i tid, er det bare å plusse på det antall sekunder som 8 uker er, med andre ord 60 sekunder i 60 minutter i 24 timer i 7 dager i 8 uker. Enkelt og greit! Variabelen $datoenOm8Uker har nå et tall som er over 1 milliard stort og som representerer 8 uker fram i tid. Dette tallet (som nå er i sekunder) kan gjøres om til en menneskelig lesbar dato på ønsket form ved å sende det inn som andre argument til funksjonen date(). Dette er gjort i siste setning.

Et tankeeksperiment: Per og Kari har kanskje 39 års bryllupsdag den 11.mai 2009. Dette er interessant nok, men det er mer interessant for den hengivende Per å fortelle sin Kari når de har 1234567890 sekunders-bryllupstid! Siden de giftet seg den 11.mai 1970, så betyr det at de på 14+31=45 dager etter sin opprinnelige bryllupsdag, kan feire 1234567890 sekunder sammen! 1234567890 Unix time tok utgangspunkt i 1.januar (1970) og det er 45 dager mellom 1.januar og 14.februar (uavhengig av årstall). Derfor må bryllupstiden "1234567890" til Per og Kari være 45 dager etter deres egentlige bryllupsdag, altså 45 dager etter 11.mai 2009. Dette betyr videre at dersom du er født en gang etter 14.februar 1970, så kan du bare regne ut og begynne nedtellingen til når du blir 1234567890 sekunder gammel!

Vil du lage deg en PHP-snutt som viser når Per og Kari skal feire begivenheten? Den blir for eksempel slik:

  $datoSomSekunder = mktime(0,0,0,5,11,2009);
  //har nå fått 11.mai 2009 som antall sekunder etter 1.1.1970
  $dagerFramITid = 60 * 60 * 24 * 45;
  $begivenhetenIUnixTid = $datoSomSekunder + $dagerFramITid;
  echo "45 dager etter den 11.mai 2009 er det den: ";
  echo date("d.m.Y", $begivenhetenIUnixTid);

Altså har Per og Kari vært gift i 1234567890 sekunder den 25.juni 2009 gitt at de giftet seg den 11.mai 1970. Her brukes mktime() for å regne om fra en dato til den tilsvarende Unix-tiden. Det fins sikkert enda mer elegante måter å regne om dette på med færre kodelinjer.

Oppdatering noen timer senere: Nedtellingen skjedde for øvrig en rekke steder i verden, også på Twitter (bildet leses nedenfra og opp)

Unix time er ikke nerdete, men gøy, eller hva?

[1]: Datasystemer, for eksempel bloggen min hos Google, kan nemlig publisere ting automatisk frem i tid. Dette er basert på når den tilsvarende Unix-tiden for publisering (publiseringstidspunktet jeg har satt) "blir tatt igjen" av den virkelige Unix-tiden som tikker og går. Snedig. Det er muligens bare en teller som øker og øker for hvert sekund og to tall som hele tiden sammenliknes, men det er trolig implementert på en litt mer effektiv måte i operativsystemet på tjeneren hos Google. Unix time er i bunn og grunn en teller, og de fleste datasystemer gjør bruk av slike tellere på en eller annen måte.

[2]: Siste gang et leap second ble lagt til, var på nyttårsaften 2008. Unix time legger altså ikke plutselig til et ekstra sekund, og det er rett og slett fordi at om en la til et ekstra sekund når resten av verden gjør det, så vil det nærliggende sekundet "forsvinne". Dette betyr i praksis at noen tall ikke eksisterer, og det passer dårlig i dataverdenen å hoppe over noe ved telling eller å si at et tall ikke eksiterer. Det kan for eksempel medføre at en if-test aldri blir utført, noe som er uholdbart fra et programmeringsteknisk synspunkt.