Summertime, and the living is easy…

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…

Morten Hauch

Mail: mha@openminds.dk
Mobil: +45 3023 7021

Læs mere

Seneste blogindlæg

Er ny teknologi ét skridt frem og to tilbage?

Danske virksomheder kan trække rigtig meget forretningsværdi ud af deres eksisterende it-setup uden at skulle investere i en masse ny teknologi. Men ny teknologi som fx AI og big data er blevet så hypet, at virksomhederne bliver i tvivl, om det overhovedet er muligt at udnytte data uden et CERN-lignende arrangement.

Giv jeres legacy-system en agil skygge

Legacy-systemer bliver ofte set som den tunge arv fra fortiden. En arv man gerne vil slippe af med på samme måde, som man ønsker at slippe af med en jernlænke og kugle om anklen.

Men legacy-systemet er også en værdifuld arv, man ikke kan eller vil leve uden. Årtiers investeringer i specialiseret systemudvikling fokuseret på én virksomheds (eller branches) behov kan ganske enkelt ikke erstattes med noget, der når legacy-systemet til sokkeholderne.

Sådan finder i jeres sweet spot for systemovervågning

Allerede når man begynder at udvikle software, og den første kode skrives, er der fokus på hele tiden at teste for fejl. Men for udvikleren stopper fokus på fejlsøgning ikke, når den færdige kode er sat i drift.
I godt it-udviklingsarbejde tager udvikleren også højde for den efterfølgende overvågning og vedligeholdelse af softwaren, så systemet kan holdes kørende, og fejl og uregelmæssigheder bliver opdaget og håndteret.