Onlangs kwam in het nieuws dat Noord- en Zuid-Korea de klok gelijk gaan zetten. Het gaat om een verschil van 30 minuten. Dat bracht me tot nadenken. Tijd lijkt zo simpel. We rekenen er allemaal dagelijks mee, maar er zit eigenlijk veel complexiteit achter. Denk aan tijdzones die verticaal lopen of waar de tijd niet een geheel uur opschuift. Hoe zit het nu met tijd en tijdzones en wat heb ik er als Developer mee te maken?
Als de datum in zicht komt dat een domeinnaam vervalt of moet worden verlengd, dan gaat het vaak om berekeningen waarbij je een relatief aantal dagen vooruit wilt kijken. De verloopdatum van een product is één jaar na de aanschaf. Soms heb je ook te maken met tijdzones, bijvoorbeeld als je informatie opvraagt over domeinen bij de betreffende registry.
Als mensen denken we vaak in termen van ‘één jaar later’ of ‘over een maand’, maar die concepten zijn lastig uit te leggen aan een computer. Bijvoorbeeld, als je een product aanschaft op 29 februari, wat is dan één jaar later? Is dat 28 februari of 1 maart? En als je het op 30 januari over ‘één maand later’ hebt, is dat dan het 28 februari of 2 maart?
Deze berekeningen zijn al best complex om goed te doen en het wordt niet gemakkelijker gemaakt door hoe tijdzones zijn ingedeeld. Tijdzones zijn onderhevig aan verandering en niet altijd even logisch ingedeeld. De tijdzone in China is bijvoorbeeld UTC+8 (China Standard Time of CST) en dat terwijl China dermate groot is dat het vijf geografische tijdzones overspant. In 1949 is besloten om in heel China dezelfde tijdzone te gebruiken. Daarna kwam in 1991 het besluit om geen zomertijd meer aan te houden.
Standaardtijd
Vroeger gebruikte men Greenwich Mean Time (GMT) als standaardtijd. Deze standaard is gebaseerd op de stand van de zon in Greenwich, London. In GMT is 12:00 uur ‘s middags gedefinieerd als het moment waarop de zon gemiddeld, gedurende een jaar, op z’n hoogst staat. Door de tijd aan de zon te koppelen, zorg je ervoor dat de tijd niet verschuift ten opzichte van de dag. Iedere dag om 13:00 uur is het lunchtijd bij Antagonist en de zon staat dan altijd net iets voorbij z’n hoogste punt.
Er is echter een addertje onder het gras, de rotatiesnelheid van de aarde (oftewel, de lengte van een dag) is niet constant. Dit zorgt ervoor dat dagen, uren, minuten en seconden in GMT niet altijd even lang zijn. Volgens GMT is een dag precies de tijd die de aarde nodig heeft om een rondje om z’n eigen as te draaien. Een uur is 1/24ste dag, een minuut is 1/1440ste dag en een seconde is 1/86400 dag. Dat betekent dat de lengte van een dag verandert als de uren, minuten en seconden ook veranderen.
Die variabele lengte van de seconde is erg onhandig als je precieze metingen probeert uit te voeren. Om die reden is er een nieuwe standaard in het leven geroepen, namelijk: International Atomic Time (TAI). In TAI zijn dagen, uren en minuten gedefinieerd aan de hand van de seconde, dat is dus omgekeerd van GMT. De lengte van een seconde is vastgelegd als ongeveer 9,1 miljard oscillaties van een Caesium-atoom. Een seconde in TAI is dus altijd even lang, ongeacht de rotatiesnelheid van de aarde.
Dit levert echter weer een nieuw probleem op, want als GMT en TAI het niet eens zijn over de lengte van een seconde, dan lopen de twee standaarden langzaam uit elkaar. Universal Coordinated Time (of UTC) werd geïntroduceerd om dit probleem op te lossen. Het doel is om een accurate en vaste definitie van de seconde te combineren met de logische tijdsindicatie van GMT.
Coordinated Universal Time
De naamgeving van UTC is enigszins bijzonder. Engelstaligen wilde de standaard Coordinated Universal Time (of CUT) noemen, Franstaligen juist Temps Universel Coordonné (of TUC). Uiteindelijk besloot men voor UTC te gaan, een afkorting die dus nergens voor staat.
De seconde in UTC is vastgelegd op dezelfde manier als in TAI en is dus constant. Maar om ervoor te zorgen dat UTC niet te ver afwijkt van GMT worden er af en toe schrikkelseconden toegevoegd. De verschillen in rotatiesnelheid zijn niet constant en niet goed te voorspellen. Daarom worden er soms twee, soms één en soms nul schrikkelseconden per jaar toegevoegd.
Tijdens het schrijven van dit blog is de laatste schrikkelseconde 31 december 2016 ingevoerd. In 2018 zullen er geen schrikkelseconden worden ingevoerd. Door af een toe een schrikkelseconde toe te voegen, probeert men het verschil tussen GMT en UTC altijd kleiner dan één seconde te houden.
Tijdzones
De standaardtijd UTC zorgt er dus voor dat 12:00 uur UTC altijd min of meer het hoogste punt van de zon in Greenwich representeert. Maar deze conventie is ook handig om te gebruiken buiten Greenwich, daarom zijn er tijdzones uitgevonden. Alhoewel de tijdzones al lang bestonden vóór de invoering van UTC, zijn ze tegenwoordig op UTC gebaseerd.
De aanduiding voor tijdzones is UTC + of – afwijking. Bijvoorbeeld UTC+2 of UTC-8. Veel tijdzones hebben ook een naam, bijvoorbeeld Central European Summer Time (CEST) dat is UTC+2. Een ander voorbeeld is Eastern Time (ET); de tijdzone in New York, dat is UTC-5. Als je naar het westen gaat, dan loopt de tijd terug. Als je naar het oosten gaat, loopt de tijd vooruit.
Dit lijkt allemaal heel simpel, maar er zijn allerlei kleine dingen die ervoor zorgen dat tijdzones een stuk lastiger zijn dan ze lijken. Zo zijn tijdzones onderhevig aan verandering. Een simpel voorbeeld is dat de tijdzone in Nederland wisselt tussen Central European Time (CET) en Central European Summer Time (CEST).
Complexiteit bij tijdszones
Australië is een goed voorbeeld van alles wat onduidelijk kan zijn aan tijd. De overgangen tussen de tijdzones zijn in sommige gevallen groter dan één uur en niet alle staten hanteren zomertijd. Daarnaast overlappen de tijdzones van Australië met de grenzen tussen de staten en dat zorgt ervoor je in de noord-zuidrichting kunt reizen en toch een tijdzone kunt oversteken. Ik kan dit in tekst gaan uitleggen, maar een plaatje zegt meer dan 1000 woorden.
De twee staten in het midden, Northern Territory en Southern Australia, delen dezelfde tijdzone, namelijk Australian Central Standard Time (of ACST). Deze tijdzone is UTC+9:30, terwijl de tijdzone in het naastgelegen Western Australia UTC+8:00 is. Dat is dus een stap van anderhalf uur, maar daar komt ook nog bij dat Southern Australia wél zomertijd hanteert en Northern Territory niet. Dus als de zomertijd ingaat, dan kun je van noord naar zuid reizen en daarbij een tijdzone oversteken.
Hulpmiddelen: tz-database en pytz
Gelukkig zijn er hulpmiddelen om met datums en tijden te rekenen. Elke programmeertaal heeft daar z’n eigen faciliteit voor. In Python gebruiken we een package die pytz heet, waarbij ’tz’ staat voor ’timezone’. Dit maakt gebruik van de tz-database en een grote verzameling van informatie over tijdzones.
De tz-database bevat niet alleen tijdzones per locatie, maar ook informatie over veranderingen in tijdzones. Denk aan overgangen naar zomertijd en aanpassingen aan tijdzones, zoals in China in 1949. De reden dat de tz-database zoveel historische data bevat, is omdat deze data nodig zijn om terug te rekenen. Als je bijvoorbeeld iets wilt uitrekenen met een datum in China vóór 1991, dan zul je er rekening mee moeten houden dat de zomertijd toen nog gebruikt werd.
De tz-database, die vrij beschikbaar is, maakt het rekenen met datums en tijden een stuk gemakkelijker. De meeste programmeertalen hebben een faciliteit om te rekenen met datums, tijden en tijdzones, en maken daarbij over het algemeen gebruik van deze database. Ook in PHP kun je er gebruik van maken met de DateTime en DateTimeZone-classes.
Tot slot
Zoals je ziet, is het met tijd lang niet zo simpel als op het eerste gezicht lijkt. Ik maak dan ook dankbaar gebruik van de hulpmiddelen die er beschikbaar zijn. Dat maakt het flink eenvoudiger om te zorgen de datums van jouw producten in je klantaccount van Mijn Antagonist altijd kloppen! 🙂
P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.