En liten historie om tid

For å besvare flere av disse spørsmålene er vi avhengig av å kunne beregne og lagre tid på en nøyaktig måte, og innen IT har vi et enormt sett med utfordringer som har med tid å gjøre. Tid er et komplekst tema som er sterkt knyttet til vår verdensforståelse, og i hverdagen er tiden helt essensiell - hele samfunnet vårt strukturerer seg rundt hva klokka er.
Noe som gjør det vanskelig å regne ut tid nøyaktig er blant annet konsepter som skuddår, politisk bestemte tidsendringer, og det faktum at en dag ikke varer nøyaktig 86400 sekunder. Når man jobber med tid innen IT er det helt essensielt at man ikke er for naiv i hvilken praksis man bruker, men at man tar velinformerte valg ved å sette seg inn i problemstillingen og velge den rette løsningen.

Det var en gang – tidens opprinnelse

For gamle kulturer var det viktig å ha oversikt over sesonger, slik at de visste når det var varmt, når de skulle plante eller så, og når det ble regntider eller tørkeperioder. Forståelse for tid var med å definere kulturelle normer, og jegere og stammer hadde en tendens til å samle seg rundt bålet på nattestid istedenfor å vandre rundt. Forhistorisk forståelse av tid var ofte delvis astrologisk, og var avhengig av stjerners, planeters og månens bevegelser. Selv om jorda går i bane rundt sola, er dette noe også andre planeter gjør, så det er komplisert å predikere hvor ting kommer til å være. Jorda vingler også på sin egen akse, noe som fører til konsepter som jevndøgn og lignende. Det å bare se opp på himmelen gir altså ikke veldig god anelse om hva klokka er, i det minste ikke uten en god del ekstra arbeid. I jegernes, bøndenes og de forhistoriske sivilisasjoners tid var det ikke veldig viktig med punktlighet, og hverken tidssoner eller annet var særlig veldefinert. Men med vår teknologiske utvikling har også vår nøyaktighet innenfor tidsberegning utviklet seg.
Noe som virkelig endret behovet vårt for å vite hva klokka er, var den industrielle revolusjon. Med innføring av industrielle prosesser som transport og togavganger ble det essensielt å vite når avreise og ankomst var. I tillegg har lengre sjøreiser vært avhengig av nøyaktig tidsberegning for å finne ut lengdegrader. Det at folk begynte å bevege seg raskere med de nye transportmidlene gjorde at man kunne gjøre nøyere planlegging, da man faktisk hadde mulighet til å rekke flere ting. I tillegg gjorde raskere reisebevegelse at konseptet om tidssoner ble tatt i bruk.

Hva med i det moderne samfunnet?

Det å beregne klokka mer nøyaktig ble et behov da vår teknologiske utvikling begynte å akselerere. I dagens samfunn er det et hav av ulike mekanismer som er helt avhengige av svært nøyaktige tidsberegninger. Måten vi beregner tid er typisk ved å bruke atomisotopen Cesium 133 i det vi kaller atomklokker. Det er atomenes syklus i strålingsnivå som definerer hvor lang tid som har gått, og SI-enheten sekund har blitt definert som tiden et Cesium-atom bruker på 9 192 631 770 radioaktive sykluser. Her begynner vi å bevege oss inn på et område med svære tall og en litt mer ubegripelig skala på ting (overgangen hit fra oldtidens solur virker temmelig stor!). Det er flere områder i vårt moderne samfunn hvor nøyaktig beregning er kritisk for at ting skal gå rundt. Uten de atomdrevne urene ville det for eksempel ikke vært vits å installere GPS i bilene, da vi ville hatt mye bedre sjanser for å finne frem med klassisk kart og kompass.

GPS og sikkerhet

For at GPS skal fungere er det essensielt at man har et svært lite avvik, da man kalkulerer avstand (og dermed posisjon) ut ifra hvor lang tid signalene bruker på å reise mellom satellittene og målestasjonene. Hvis man feilberegner tida med bare tre og et halvt nanosekund, altså tre milliarddeler av et sekund, vil man bomme med en meter. Dette betyr at en bom på et par mikrosekunder vil føre til at man har bare en kilometers nøyaktighet for posisjonen sin. Dette ville gjort GPS fullstendig ubrukelig til å gjennomføre dagens oppgaver, der vi ønsker hjelp til å finne fram i en bys gatenettverk. I tillegg til å vite hvor vi er, ønsker vi også å sørge for at vi vet hvem vi er. Nettopp dette er spørsmålet vi ønsker et pålitelig svar på når vi identifiserer oss på digitale tjenester. Hvem er du, hvorfor skal vi autentisere deg?
Flere autentiseringsprotokoller har en tidskomponent i seg for å unngå det som kalles “replay attacks”. Nøkkelen du får er bare gyldig i en kort tidsperiode, og etter det må du få en ny en, slik at eksponering av gamle nøkler ikke fører til at en hacker kan lese alle dine tidligere meldinger. I tillegg benytter vi gjerne nøyaktig tidsberegning for å håndtere load balancing og forhindre DoS-angrep. For å holde tritt i utvikling av disse konseptene i IT-systemer er det viktig med noen standarder. Et verdensomspennende format som er et forsøk på standardisering kalles Coordinated Universal Time, og er flittig brukt i IT-systemer.

UTC-formatet og variasjoner

Coordinated Universal Time (UTC) er en universell tid man har blitt enig om, som avviker fra soltid på null grader lengdegrad med omtrent ett sekund. Det er ganske likt Greenwich Mean Time (GMT), men det viser seg at GMT ikke lenger er presist definert. UTC defineres av International Telecommunications Union, og er standarden som brukes av både værmelding, luftfart og på den internasjonale romstasjonen ISS.
Dagene på jorda er delt inn i timer, minutter og sekunder, der hver dag har 24 timer og hver time 60 minutter. Dette er helt forutsigbart. Når vi kommer ned til minutter derimot, har vi noe som faktisk varierer litt. Som oftest varer et minutt i 60 sekunder, men ved en sjelden anledning vil det vare i 59 eller 61 sekunder i stedet. Det som ligger til grunn for dette er et konsept vi kaller skuddsekund, noe som finnes fordi jordas rotasjon opplever små, spontane endringer. Skuddsekunder oppstår i gjennomsnitt hver 19. måned, og blir annonsert av en egen internasjonal komité for rotasjon og referansesystemer. De varsler om skuddsekund minst seks måneder i forveien, men kan ikke legge en langsiktig plan for det på grunn av hvor vanskelig det er å predikere jordas rotasjon. Det kan tenkes mange tilfeller av software som har problemer på grunn av skuddsekunder, da unøyaktighet på et helt sekund er svært uakseptabelt. I ett tilfelle var Google sin måte å håndtere skuddsekund å bruke det de kalte “leap smear”, ved å innføre en liten endring i sekundenes lengde i et tidsvindu før skuddsekundet. Amazon på sin side annonserte at de skulle gjøre noe lignende, men selvfølgelig ikke på helt samme måte.

I tillegg til at vi har både skuddår og skuddsekund, er politisk bestemt tid noe som til programmereres store frustrasjon fører til endringer og feil når man minst venter det. Det er da snakk om ting som sommertid, vintertid og tidssoner. Tidssonene i UTC er definert av positive og negative avvik, og går teoretisk fra –12 timer UTC til +12 timer UTC. Likevel finnes det unntak, som da øy-nasjonen Kiribati flyttet tidssonene –10 og –11 UTC til +13 og +14 UTC, for at deres øvrige to øyer skulle ha én og to timers tidsdifferanser til hovedstaden istedenfor 22 og 23.
Det finnes også flere land som bruker halvtimes og 45 minutters tidsforskyvninger i stedet for hele timer. Chatham Islands, som tilhører New Zealand, har faktisk en offset på +13:45 UTC!
Og fra litt nærmere breddegrader så har vi jo øst-Finnmark, som egentlig skulle hatt samme tid som Finland - men det har de ikke, altså politisk bestemt tid der også.

Så har vi dette med sommertid. I kode24 ble det før sommeren publisert en artikkel der det uttrykkes mulig bekymring dersom vi skulle velge å avskaffe sommertiden i Norge. Rett og slett et nytt Y2K-problem?

Intern chatting om sommetid og vintertid

Når vi endrer fra vintertid til sommertid kan den samme lokale tiden peke til to ulike UTC-tider. Man vet altså ikke om det er snakk om klokkeslettet før eller etter klokka ble stilt. Dette er et konsept som førte til en lang diskusjon i en av Kantegas interne faggrupper, der vi drøftet hvorvidt avskaffelse av sommertid ville være problematisk når man skal håndtere bilutleie:

Det som her poengteres i chatten er at ting som har skjedd i fortiden må lagres i UTC for å være sikker på når ting faktisk skjedde. Derimot må fremtidige avtaler lagres i lokale tidsstempler (som LocalDateTime i Java) i den tidssonen det gjelder for å få den tiden som er aktuell for brukeren. Folk kikker nemlig ikke på verdensuret, men på klokka de har på armen (les: smart-device) når de skal forholde seg til et avtalt tidspunkt. Løsningen for å håndtere overgangen når et tidspunkt går fra å være fremtid til fortid er å lagre både avtalt hentetid, og reell hentetid. Man lagrer når man avtalte å hente bilen i LocalDate og når man faktisk hentet bilen (som jo er avhengig av når brukeren faktisk dukket opp) i en Instant (UTC).
Videre fortsatte diskusjonen med flere spørsmål; kan man ikke bare lagre et tidsstempel med når reservasjonen av bilen fant sted, og så utlede hvilket tidspunkt man mente? Og kan man ikke lagre stempel med tidssone, og dermed kunne få tak i riktig tid når man spesifiserer dette?

Absolutt tid versus politisk tid

Nei, dette går fortsatt ikke i bileksempelet, man kan ikke bare sette timestamp og så regne om til tidssone når man henter ut tida. Brukeren var ikke interessert i å få en bil når klokken slår 10:00 på Greenwich den 1. Juli 2020. Snarere gir brukeren blaffen i om klokken er 10 eller 11 i Greenwich, men vil ha bilen når klokken er 12 i Norge sånn som avtalt, uansett om sommertidsreglene har blitt endret eller ei. Når brukeren har avtalt at bilen hentes 01.07.2020 kl. 12:00 Europe/Oslo og man lagrer det i UTC, blir det omregnet idet man lagret tidspunktet. Hvis sommertid har blitt droppet i mellomtiden, er dermed tidspunktet man får tilbake når man skal sjekke den lagrede tiden, 11:00 istedenfor 12:00. Det var samme øyeblikk i UTC, men for brukeren endte det med å bli feil tidspunkt. Det hjelper ikke å sette riktig tidssone når klokkeslettet skal hentes ut, fordi det lagrede tidspunktet er feil. Årsaken til at det blir feil er fordi det lagres som et absolutt tidspunkt som stemte overens med den politisk bestemte lokale tiden idet det ble lagret. Så vi har dermed en mulig konflikt mellom absolutt tid som vi regner ut, og politisk tid som kan endre seg ved et nytt politisk vedtak.

Et annet problem kan komme dersom man velger å benytte seg av en løsning som praktiseres i tognæringen, nemlig det å lagre starttidspunkt pluss varighet. Løsningen fungerer fint dersom man skal beregne et transportmiddels ankomst på tvers av tidssoner og lignende. Men når man skal håndtere billån i vårt eksempel kan man støte på en utfordring, som ble godt beskrevet av Ove Nipen under diskusjonen:

"Hvis du leier bil 26. oktober kl. 12 og skal levere den tilbake 27. oktober kl. 12 (da har vi altså stilt tilbake fra sommertid til normaltid i mellomtiden) så er det uvesentlig om du har hatt bilen i 24 eller 25 timer. Det vesentlige er at vi har avtalt et tidspunkt du skal levere bilen tilbake. Om sommertid blir avviklet så skal du ikke plutselig levere den tilbake kl. 13 i stedet. Vi avtalte jo kl. 12! Særlig hvis noen andre har bestilt den fra kl. 12 den 27. oktober. De vil nok neppe være forståelsesfulle dersom bilen er en time sent tilbake bare fordi sommertiden ble avviklet. Imens med togreiser så går jo toget i en viss hastighet etter en rute, så da er toget fremme etter seks timer uansett hva politikerne måtte finne på å gjøre med klokken underveis. Så estimert ankomsttid for toget fra Bergen til Oslo er uansett 6 timer etter det forlot stasjonen i Bergen."

Det er altså essensielt å vite hva tiden skal brukes til før man avgjør hvordan den skal lagres, og det ble nevnt av en deltaker at diskusjonen koker ned til semantikken:

Er det man skal lagre et tidspunkt eller et klokkeslett og en dato?

Som utvikler bør du aldri undervurdere beregning av tid, og det er en hel haug av ting som kan gå galt. Prøv for all del ikke å hacke sammen beregning av tid selv, og hold deg langt unna kjente svake biblioteker som Date-klassen i Java! Veien å gå er heller å ta i bruk velprøvde biblioteker, der folk har spesialisert seg i å gjøre disse greiene riktig. Det er liten feilmargin dersom man skal sjonglere med både tidssoner, skuddsekunder og mer. Dermed kan hele diskusjonen om tid sammenfattes til en anbefaling: Det går ikke an å "bare" lagre alt i UTC og konvertere til lokal tid når man trenger det, og så regne med at alt går greit. Man må starte med en god forståelse av problemet man forsøker å løse, og velge riktig strategi for bruk og lagring av dato og tid ut fra kravene man har å jobbe med.

Om du skal jobbe med tid, ta altså ikke for lett på det, og ta gjerne kontakt hvis du har lyst til å snakke mer om temaet.

Kilder

Complete Developer Podcast: https://completedeveloperpodcast.com/tag/history-of-time/​

Kantegas Fagruppe "Backend og Arkitektur”, der vi hadde diskusjon om sommertid/vintertid

Lenken fra Kode24: https://www.kode24.no/kodenytt/frykter-ny-y2k-bug-om-sommertid-forsvinner/70232173​