I slutten av august måtte NTB komme med en pinlig innrømmelse:
Mens hele Norge har lagt om dusjerutinene sine til å treffe de billigste timene for strøm, har NTBs strømpristjeneste konsekvent bommet med én time gjennom mesteparten av sommeren.
Årsaken var sommertid, eller rettere sagt, at NTBs konsument av et API hos Nordpool ikke justerte for norsk sommertid.
Noe av de flaueste som kan skje for et nyhetsbyrå er at de selv, på utilsiktet vis, blir en nyhet. Men nettopp det har altså nå skjedd med NTB.
Strømpriser har vært i fokus hos veldig mange de siste månedene, og mange har nok sjekket på nett når på dagen det er billigst å ta seg en dusj, sette på vaskemaskinen eller gjøre noe annet som forbruker mye strøm. Nå viser det seg at tjenesten NTB leverer til en rekke nettaviser ikke tok hensyn til norsk sommertid. Dermed har grafene hos forskjellige nettaviser i sommer vist feil tid for når det er billig eller dyrt å bruke strøm.
Trodde du at det var lurt å vente til kl. 13 for å sette på oppvaskmaskinen en eller annen dag tidlig i august? Kan hende at du egentlig skulle ha ventet til kl. 14…
Derfor skaper skuddsekunder trøbbel for utviklere - og derfor har Meta fått nok
Korrekt tid vs brukervennlig tid
Ut fra dokumentasjonen for Nordpools API kan jeg ikke se noe annet enn at de i alle tjenestene sine har brukt såkalt zulu-tid for å representere tidspunkt. Jeg vil dermed tro at de har sitt på tørre, og at feilen har oppstått internt hos NTB i konverteringen fra teknisk korrekt zulu-tid til brukervennlig norsk tid, men altså uten å ta hensyn til sommertid.
Det er en liten tabbe, og i dette tilfellet er konsekvensene heldigvis sannsynligvis heller begrenset. Uten å ha sjekket det vil jeg tro at de billigste timene ofte kom rett etter en time som også hadde relativt lav pris, men det har sikkert vært en del prishopp rundt den billigste time også.
Uansett så er det kjedelig og litt pinlig, men selv har jeg gjort alt for mange lignende feil, og føler derfor mye sympati for utvikleren som i vår sjekket inn koden for tidskonverteringen i NTBs koderepo.
Måten mennesker definerer og håndterer tid på er notorisk vanskelig. Som om det ikke var vanskelig nok å håndtere skuddår og skuddsekunder har vi også sommertid (som jeg mener vi aldri vil kunne forklare til et utenomjordisk vesen uten å miste vår status som «intelligent liv på jord», om vi i det hele tatt hadde kvalifisert til det).
Pluss en del triksing med tidssoner (samme kommentar). Det er klart det blir mange feil og bugs av sånt.
«Å kalle feilen for amatørmessig, som jeg har sett noen gjøre i et kommentarfelt, ville jeg ikke gjort.»
Fysiske størrelser
Men problemet er større enn bare tid. Fordi tid er så vanskelig å håndtere riktig, er det ironisk nok kanskje den fysiske størrelsen som oftest – men altså ikke alltid – blir håndtert korrekt i software. Det vil si gjennom spesifikke klasser fra et spesialisert eller standard bibliotek, og ikke som et tall (en int eller en float) som bare sendes rundt uten enhet.
Men vi gjør det siste også, for eksempel som «Unix-tid», antall sekunder siden midnatt 1. januar 1970.
Men hvor ofte har du sett at en lengde eller en temperatur i et API ble håndtert som… en lengde eller en temperatur? Min erfaring er at fysiske størrelser som oftest blir håndtert som floats eller doubles, og at du må se på parameternavnet eller slå opp i dokumentasjonen om forventet enhet er meter, kilometer, millimeter eller noe annet.
Jeg mener at bruk av tall for å representere fysiske størrelser er direkte i strid med DDD-prinsippene. En lengde er en lengde, og ikke et tall, og bør derfor representeres som en lengde, og ikke et tall. Jobber man på tvers av organisasjoner vil det nesten garantert dukke opp konverteringer, og dermed også problemer.
Det er ikke alltid at konverteringsfeil forblir uoppdaget til det er for sent og fører til så store konsekvenser som for Mars Climate Observer i 1999, men likevel koster de tid og penger.
Tid - hvor vanskelig kan det være?
Også SI-systemet byr på overraskelser
Men så er det igjen overraskende hvor vanskelig vi mennesker har laget det for oss selv. På overflaten fremstår SI-systemet som et ganske logisk og rasjonelt opplegg. Men kommer man litt ned i detaljene, ikke minst når man skal utføre beregninger med fysiske størrelser, så står overraskelsene og problemene nærmest i kø.
Alle vet at 1 m + 1 m er 2 m. Men hvor mye er 1 °C + 1 °C? Svaret er: Det kommer veldig an på. Snakker vi bare om en temperatursendring, som for eksempel at temperaturen ute var 1 °C for en time siden, og at det siden har blitt 1 °C varmere, så er svaret enkelt nok 2 °C. Men i visse situasjoner representerer temperatur en energimengde, og da er svaret på 1 °C + 1 °C «selvfølgelig» 275,15 °C, som tilsvarer 548,3 K.
Men 1 m°C + 1 m°C derimot, det er alltid 2 m°C, for da snakker vi bare om to temperaturforskjeller. Slike eksempler viser at det er et sjansespill å bruke floats eller doubles for fysiske størrelser, selv om man holder seg til SI-systemet.
Og ikke prøv å hjemmesnekre klasser for fysiske enheter og størrelser heller, men bruk biblioteker som tilbyr korrekt konvertering og aritmetikk!
Advarer utviklere: Frykter Y2K-bug om sommertid forsvinner
Kaste stein i glasshus
Det er lett å mene at NTB dummet seg ut da de glemte å håndtere norsk sommertid i strømpristjenesten sin. Det virker som om NTB har lagt seg ganske flat overfor abonnentene, så de er nok enige i det også.
Men å kalle feilen for amatørmessig, som jeg har sett noen gjøre i et kommentarfelt, ville jeg ikke gjort. Jeg har gjort alt for mange lignende feil selv, i tillegg til at jeg opp gjennom årene har bygget mange glasshus basert på andre fysiske størrelser enn tid.
På tide at vi kaller en spade for en spade og modellerer en lengde for en lengde, og ikke et tall!
