Summertime, and the living is easy…

“… og så skal de have svaret inden for tre døgn”

Så uskyldigt starter samtalen, og den forretningsansvarlige forstår ikke de ubehagelige spørgsmål, der nu følger fra udvikleren:

“Mener du 72 timer eller samme tidspunkt om tre dage?”
“Det er da det samme!”
“Hvad nu hvis vi ikke er i samme tidszone, og de fx skifter til sommertid, og vi ikke gør”
“?”
“Ja, så kan det være, at samme tidspunkt om tre dage er 72 timer hos os – men kun 71 timer hos dem. Og hvordan ved vi, hvilken tidszone de er i?”

Vi slipper den her. Det kan blive en lang snak…

Der er altid ballade med tiden

Tidspunkter er noget, der notorisk skaber ballade, når vi skriver kode.
Tænk bare på år 2000-problemet – og på, at Java har brugt tre forsøg på at lave en fornuftig repræsentation af et tidspunkt.

Et grundlæggende problem er, at en tidsangivelse består af både tidspunkt og sted.

Skønt vi stadig støder på tidspunkter uden stedsangivelse i kodningen, har de fleste forstået, at der skal mere til: “Vi er nødt til at have tidszone med”.

Men hvorfor er det så, at flere sprog tilbyder både OffsetDateTime og ZonedDateTime?

OffsetDateTime

OffsetDateTime er angivelse af tidspunkt og offset, som er forskellen til UTC (Greenwich-time). Det kunne fx være angivet som 2020-03-10T12:00:00+01:00, svarende til klokken i Danmark, da vi er en time foran UTC, når vi kører vintertid.

En måned senere skulle vi skrive 2020-04-10T12:00:00+02:00, da der er to timers forskel på dansk tid og Greenwich-time, når vi har sommertid i Danmark (det der med havemøblerne…).

I langt de fleste tilfælde er det faktisk helt tilstrækkeligt: Det gør, at vi ved præcist, hvilket tidspunkt, vi har med at gøre, og vi kan nemt regne det om til et andet offset.

Hvad så med tidszonen?

I normalsprog er tidszonen det samme som offset, men som det indledende eksempel (lidt søgt) illustrerer, kan vi faktisk have behov for at vide, hvornår der skiftes til sommertid.

Det er den problemstilling, der løses med ZonedDateTime, hvor vi kan udvide tidsangivelsen med en zone, fx “Europe/Copenhagen”. Så ved programmeringssproget, hvornår skiftet til sommertid finder sted.

I langt de fleste tilfælde er offset dog det nødvendige og tilstrækkelige – så brug det med mindre, der virkelig er grund til andet.

Hvis du vælger at gemme eller sende tidspunktet som tekst, så brug ISO-8601 med offset (som i eksemplerne ovenfor). Det virker i alle sprog, er sorteringsvenligt og læseligt for menneskeøjne.

Og forresten:

Klokken 2.30 optræder to gange i skiftet mellem sommertid og vintertid – her postfikses tidspunktet med A/B afhængigt af, om det er første eller anden gang.

Så du skal tænke dig om, hvis du sætter et planlagt job til at køre kl. 2.30 hver nat…