Når vi først skal stille klokka en time fremover, er nok B-mennesker glade at det skjer natt til søndag. Det gir dem mulighet å redusere hodepinen som dukker opp på første arbeidsdag med sommertid. Men hodepine på grunn av sommertid kan også A-mennesker få, spesielt om de er utviklere og er ansvarlige for programmer som skal kjøre på spesifikke tidspunkt. La oss se litt på hva som skjer (eller ikke skjer) når maskinen stiller klokka fram en time.

Kvart over to eksisterer ikke

Vi i Norge stiller klokka en time frem siste søndag i mars, og en time tilbake på siste søndag i oktober. Når vi stiller den fremover hopper vi rett fra klokka 1.59 på natta til 3.00, og tilbake hopper vi fra 2.59 til 2.00. Det gjør at “kvart over to på natta” ikke eksisterer på søndagen i mars, men eksisterer to ganger på søndagen i oktober. Så hva skjer om du for eksempel ønsker å kjøre backuprutiner på det tidspunktet?

Som med alt innenfor dataverden kommer det an på. I dette tilfellet kommer det an på hva slags programvare du bruker for å kjøre programmer på faste tidspunkt, samt hvilken tidssone serveren kjører på. Jeg vil gjette på at de aller fleste kjenner til jobbplanleggeren cron, og det meste av jobbplanlegging utøves via en cron-implementasjon eller et bibliotek/verktøy inspirert av det.

Det mest vanlige er at jobbplanleggeren gjør en av to ting:

  1. Ikke håndterer overgangen til sommer- og vintertid på noen spesiell måte
  2. Kjører jobber som er planlagt mellom 2.00 og 3.00 akkurat en gang, selv om døgnet har 0 eller 2 av den timen

Om jobbplanleggeren ikke har noen spesiell håndtering, dvs. punkt 1, vil dette skje med backuprutinen vår:

Dette er definitivt ikke noe du ønsker at backuprutinen din gjør – du ønsker at den kjører en gang per dag, sånn ca. hver 24. time.

Om systemet bruker en tidssone som stiller klokka frem og tilbake, bør programmer som cron forholde seg til dette på en eller annen måte. Og heldigvis gjør de det. Den mest brukte implementasjonen av cron, Vixie Cron, forsikrer seg om at programmet blir kjørt akkurat en gang hver eneste dag: Manualen til Vixie Cron har mer detaljer på når dette inntreffer og ikke inntreffer. For vårt tilfelle vil jobben inntreffe på disse tidspunktene ved tidsskiftene:

Det høres jo fint og flott ut, men det er et lite problem her. Selv om Vixie Cron er den mest brukte cron-implementasjonen, er det ikke den eneste. Et raskt søk gav meg alternativene anacron, bcron, cronie, dcron, fcron og mcron, og jeg vil tippe at resten av alfabetet ville dukket opp om jeg hadde søkt litt mer. Og som jeg nevnte, så er jobbplanlegging à la cron også implementert som biblioteker for programmeringsspråk, eller i systemer som for eksempel Kubernetes.

Og de implementasjonene har ikke nødvendigvis samme oppførsel som Vixie Cron! Det fikk noen som brukte Kubernetesvarianten smertefullt erfare da de gikk over til vintertid i fjor, og en backup ble kjørt dobbelt og fintet ut en gjenopprettingskommando som begynte etter den første backupen.

Om du er avhengig av denne funksjonaliteten blir du dermed nødt til å lese dokumentasjonen til jobbplanleggeren du bruker, samt verifisere at det er den som er installert på serveren/systemet du kjører. Og selv om dette ikke nødvendigvis er vanskelig, er det et risikomoment man helst vil unngå.

Folk erfarne med systemadministrasjon og/eller tid vet allerede hva vi vanligvis gjør: I stedet for å bruke en tidssone som flytter seg frem- og bakover i tid, så bruker man alltid UTC (koordinert universaltid) på servere. Dette er ikke bare kjekt for potensielle problemer med cron, det er andre programmer og systemer som også sliter med det å flytte tid fram og tilbake.

Så la oss bare bruke det! Om vi alltid bruker UTC vil problemet vårt være løst… Eller?

La det bli lys (men ikke for tidlig)

For ting som ikke direkte eksponeres til brukere er UTC knall. Backups, oppryddingsarbeid og andre ting man må gjøre for å vedlikeholde systemet har som regel ikke noe problem med å bli utført en time tidligere eller senere relativt til “mennesketid”, så lenge det skjer sånn ca hver 24. time. Men om det er funksjonalitet tilgjengelig for brukerne vil ikke alltid UTC holde.

Jeg og samboeren var tidlig ute med å skaffe oss smartlys man kunne kontrollere via en app. Med appen kan vi blant annet be lysene skru seg gradvis på på et visst tidspunkt, og av på et annet. Og dette gikk som en klokke, helt til vi plutselig en mandag ble vekket en time tidligere enn normalt.

Hva var det som skjedde? Jo, USA stiller klokka fremover to uker før vi gjør, og tydeligvis hadde de som lagde systemet ikke tenkt på at det eksisterer folk utenfor De forente stater. For å fikse det ble vi nødt til å stille lysalarmen til å starte klokka 7.30 om vi ønsket at den skulle starte klokka 6.30. Selvfølgelig glemte jeg hele greia etter å ha oppdatert tidspunktet i appen, og to uker senere ble vi vekket en time for sent.

Selv om det var en frustrerende opplevelse, gjorde utviklerne av systemet noe delvis riktig: De forstod at folk stiller klokkene, og at det er kjipt å våkne opp for tidlig eller for sent fordi du glemte å stille inn lysalarmen. De var heldigvis raske på ballen, og kom raskt med en oppdatering som fikset dette problemet. (Hvis du lurer på hvorfor smarthusappen din trenger tilgang til hvor du bor, så er den legitime grunnen som regel dette.)

Cron er for systemer, ikke mennesker

Når vi må bruke brukernes tidssone, må vi også ta hensyn til at klokka kan stilles frem og tilbake. Hvordan man best håndterer dette er ikke opplagt, og for smartlys er det faktisk ingen løsning som både er fornuftig og enkel. Det kan best illustreres med to naboer: Sykepleieren Sivert og restaurantservitøren Runar.

Sivert jobber veldig tidlige skift på sykehuset, og må være på jobb til klokka 4.00. For å rekke det har han funnet ut at det å skru på lyset 2.15 er optimalt, for da rekker han å spise “frokost” og stelle seg. Typisk er han ute av døra klokka 3:30. Runar, derimot, ønsker at lyset skrur seg av klokka 2.15. Han er som regel hjemme rundt 1.00, og 2.15 er som regel tidspunktet hvor han har kommet seg i seng og leser litt før han legger seg.

Hvis vi bruker Vixie Cron, vil vi endre på lysinnstillingene kl 2.15 gammel tid når vi stiller klokka tilbake. Det virker forsåvidt greit nok. Men når vi stiller klokka en time fram, vil Vixie Cron endre lysinnstillingene klokka 3.00. Det er nok ikke akkurat det Sivert, Runar eller du forventer:

I dette eksempelet er de to mest naturlige tidspunktene for å endre lysinnstillingene enten klokka 1.15 eller 3.15. For Sivert er 1.15 best, da lyset alltid vil skru seg på like lenge før skiftet hans starter. For Runar er 3.15 best, da lyset vil alltid skru seg av like lenge etter at skiftet hans slutter. Men ingen av valgene vil være fornuftige for begge samtidig:

Teknisk sett kan man gjøre begge fornøyd ved å støtte begge deler, men det blir et stort UI/UX-mareritt. I tillegg må man da finne ut hvordan man skal forholde seg til lysinnstillingene mellom 1.00-2.00 og 3.00-4.00, som nå kan kollidere med de mellom 2.00-3.00. Følgelig er løsningen ofte “eh, de fleste endrer ikke lyset mellom klokka 2 og 3 på natta”, rett og slett fordi alternativet gjør brukeropplevelsen for den typiske brukeren verre. Den gode nyheten er at dette er som regel OK og mer plagsomt enn noe annet – det er ikke uten grunn at vi stiller klokka på det tidspunktet i uka hvor det nesten ikke skjer noen ting.

Men det eksisterer tilfeller hvor god håndtering av tidsskiftet er både viktig og nødvendig. Sykehuset der Sivert jobber på må for eksempel fremdeles gi medikamenter i faste intervaller, og kontinuerlig infusjon må skje uavhengig av om klokkene stilles fremover eller bakover. Dessverre takler ikke Helseplattformen overgangen til vintertid, og nettopp disse tingene og mer må skje med papir ved St. Olavs hospital når vi stiller klokken en time bakover sent i oktober.

Som du nå skjønner, er det å håndtere overgangen til sommer- og vintertid ikke bare det å forsikre seg om at jobbene kjøres og at jobbplanleggeren gjør det riktig: Man må også sette seg inn i brukerens perspektiv og forstå hva som er det mest fornuftige.

UTC for system, design for brukere

For systemoppgaver som skjer under panseret er cron supert, gitt at serverne alltid bruker UTC som tidssone. Da sparer du deg selv for mye hodebry, så lenge det går greit at disse oppgavene hopper en time fram/tilbake sammenlignet med “mennesketid”.

Men for planlagte oppgaver som omhandler brukere, må man nesten alltid ta hensyn til tidssonen brukeren er i. Det innebærer at man også må ha et eller annet forhold til hvordan man håndterer skiftet til og fra sommertid. I mange tilfeller kan man bruke en jobbplanlegger uten mye miksing og triksing, men man må være klar over hvordan den håndterer tidsskiftet, og hva brukerne faktisk ønsker at skal skje. Hvis ikke kan det hende noen ender opp med en dose medisin for lite eller for mye.