Hva IANA-tidssone-databasen faktisk er
Hvis du noen gang har jobbet med datoer og klokkeslett i programvare, har du stolt på IANA-tidssone-databasen, enten du visste det eller ikke. Den går under flere navn — tz-databasen, tzdata, Olson-databasen eller zoneinfo — men de refererer alle til det samme: en samarbeidsbasert, fritt tilgjengelig katalog over verdens tidssoner og reglene som styrer dem.
Ordet «katalog» undervurderer det. Databasen lister ikke bare opp hvilke regioner som ligger på hvilket UTC-avvik. Den registrerer hele historien til sivil tidsregning for hver region — hvert avviksskifte, hver overgang til sommertid, hver krigstidsklokkeforskyvning og hver planlagt fremtidig regel — og går i mange tilfeller tilbake til midten av 1800-tallet da lokal middeltid ga plass for standardiserte soner. Når kalenderappen din korrekt viser at et møte i 1985 skjedde én time forskjøvet fra samme klokkeslett i dag, er det tz-databasen som jobber.
Den er tekstbasert, menneskelesbar og liten. Den kompilerte binærformen som følger med datamaskinen din, er bare noen få megabyte. Likevel koder den et av de mest stille kompliserte datasettene i databehandling.
En kort historie
Prosjektet startet på 1980-tallet under Arthur David Olson, som satte sammen den første versjonen og hostet den på servere ved U.S. National Institutes of Health. I flere tiår ble den hovedsakelig vedlikeholdt gjennom en frivillig innsats koordinert over en offentlig e-postliste, noe som er grunnen til at det eldre navnet «Olson-databasen» fortsatt dukker opp i dokumentasjon.
Paul Eggert tok over som hovedredaktør og er fortsatt den mangeårige koordinatoren av prosjektet. Hans sammenstilling av det medfølgende theory.html-dokumentet og den omhyggelige commit-historikken har gjort databasen like mye til en historisk referanse som en teknisk en.
I 2011, etter en kort, men alarmerende juridisk tvist om de historiske dataene, flyttet forvaltningen til Internet Assigned Numbers Authority (IANA), samme organ som koordinerer andre kjerneressurser på internett. IANA publiserer nå offisielle utgivelser, noe som er grunnen til at «IANA-tidssone-databasen» har blitt det kanoniske navnet. Arbeidet utføres fortsatt av det samme fellesskapet av bidragsytere; IANA gir et institusjonelt hjem og et stabilt distribusjonspunkt.
Navnekonvensjonen: Område/Sted
Et av databasens mest særegne trekk er hvordan den navngir soner. I stedet for landsnavn eller rå avvik, bruker den et Område/Sted-format, nesten alltid forankret til en representativ by:
America/New_YorkEurope/LondonAsia/Kolkata- `Australia/Sydney»
«Området» er vanligvis et kontinent eller hav (America, Europe, Asia, Pacific), og «Stedet» er en velkjent by innenfor sonen. Dette valget ser sært ut før du forstår begrunnelsen bak det.
Byer er stabile; politiske grenser og avvik er ikke det. Land deler seg, slår seg sammen, skifter navn og endrer klokkene sine. En by er derimot et fast geografisk punkt med en kontinuerlig tidsregningshistorie. Å navngi en sone America/New_York i stedet for «US Eastern Time» eller «UTC-5» betyr at identifikatoren forblir gyldig selv når reglene knyttet til den utvikler seg.
Databasen unngår også bevisst landsnavn for å omgå politiske tvister og fordi et enkelt land ofte inneholder flere soner — USA har mer enn et dusin. Den velger den mest folkerike eller historisk betydningsfulle byen i hver distinkt sone som en nøytral etikett. Når to regioner har delt identisk klokkehistorie siden 1970, deler de én sone; i det øyeblikket historiene deres divergerer, får de separate oppføringer.
Hvorfor rå avvik ikke er nok
En vanlig nybegynnerinstinkt er å lagre en tid som «UTC+5:30» og kalle det ferdig. Dette fungerer for et enkelt øyeblikk, men det faller sammen i det øyeblikket du trenger å resonnere om fremtidige eller tilbakevendende hendelser, fordi avvik ikke er statiske egenskaper ved et sted. De er resultatet av regler som myndigheter endrer konstant og ofte brått.
Tenk på noen virkelige eksempler databasen har måttet absorbere:
- Samoa hoppet over 30. desember 2011 helt. For å justere sin arbeidsdag med Australia og New Zealand i stedet for USA, hoppet Samoa over den internasjonale datolinjen, og flyttet fra UTC-11 til UTC+13. For alle på øyene eksisterte den fredagen rett og slett ikke.
- Land avskaffer, innfører eller omplanlegger sommertid med lite varsel. EU har diskutert å avslutte sommertid; flere land og amerikanske delstater har endret sommertidsreglene sine de siste tiårene. Tyrkia, Russland og andre har endret sine standardavvik direkte.
- Sommertidsstart- og sluttdatoer forskyves. USA flyttet sommertidsgrensene sine i 2007. Ethvert system som hardkodet den gamle regelen, produserte stille feil tider i uker hvert år.
Hvis du bare lagrer et avvik, kan du ikke svare på spørsmålet «hva blir lokaltiden i Santiago 15. november neste år?» — fordi svaret avhenger av regler som kanskje ikke engang er ferdigstilt ennå. Å lagre soneidentifikatoren (America/Santiago) pluss databasen lar programvaren beregne riktig avvik for ethvert øyeblikk, fortid eller fremtid, og beregne det på nytt automatisk når reglene endres.
Dette er kjerneverdiforslaget: tz-databasen skiller identiteten til et sted fra de stadig skiftende reglene som bestemmer klokken.
Hvordan den vedlikeholdes
Vedlikehold skjer åpent. Foreslåtte endringer — en ny sommertidsregel, en korrigert historisk dato, en myndighetskunngjøring — diskuteres på den offentlige tz-e-postlisten, hvor bidragsytere siterer offisielle tidsskrifter, nyhetsrapporter og myndighetsdekreter som bevis. Nøyaktighet tas på alvor; endringer i historiske data spesielt granskes opp mot primærkilder.
Utgivelser versjoneres med et år og en bokstav: 2024a, 2024b, 2024c, og så videre. Tallet er året; bokstaven øker med hver utgivelse det året. Fordi myndigheter kunngjør klokkeendringer på sine egne uforutsigbare tidsplaner, er det ingen fast utgivelseskadens — et stille år kan se to utgivelser, mens et år med politisk omveltning ser mange. Systemer forventes å oppdatere raskt, siden en foreldet database kan bety å vise feil tid etter at en regelendring trer i kraft.
Hvem er avhengig av den
Nesten alt.
- Operativsystemer. Linux-distribusjoner leverer
tzdatasom en kjerne-pakke. macOS henter sone-dataene sine fra samme kilde. Windows bruker sine egne registerbaserte soner av historiske årsaker, men eksponerer IANA-soner gjennom ICU-biblioteket og moderne API-er. - Programmeringsspråk. I praksis leser ethvert modent dato-/tidsbibliotek fra eller inkluderer tz-databasen: Pythons
zoneinfo, Javasjava.time, ICU-prosjektet, PostgreSQL, JavaScript-motorer via ICU, Ruby, PHP, og mange flere. - Applikasjoner. Kalendere, bookingsystemer, finansielle handelsplattformer, logganalyseverktøy og planleggingstjenester stoler alle på den, vanligvis uten at utviklerne tenker over det.
Denne allestedsnærværelsen er nettopp grunnen til at databasen betyr så mye. En enkelt, delt, nøye vedlikeholdt sannhetskilde betyr at et møte planlagt i ett system vises korrekt i et annet, på tvers av operativsystemer og språk, tiår inn i fortiden eller fremtiden.
Hvis du vil utforske sonene selv, bla gjennom hele listen over IANA tidssoner eller se hvordan de kartlegges over hele verden i vår katalog over alle tidssoner.
Ofte stilte spørsmål
Er tz-databasen det samme som tzdata, zoneinfo og Olson-databasen?
Ja. Dette er alle navn for det samme prosjektet. «tzdata» refererer vanligvis til datafilene som pakket for et operativsystem, «zoneinfo» til den kompilerte binærkatalogen, og «Olson-databasen» er det eldre historiske navnet etter grunnlegger Arthur David Olson. I dag er det offisielle navnet IANA-tidssone-databasen.
Hvor ofte oppdateres databasen?
Det er ingen fast tidsplan. Utgivelser utløses av virkelige hendelser — en myndighet som endrer sommertidsreglene eller standardavviket, eller en korreksjon av historiske data. Noen år ser en enkelt utgivelse; andre ser flere. Hver er navngitt som 2024a, 2024b, med økende bokstav gjennom året.
Hvorfor navngir den soner etter byer som America/New_York?
Byer er geografisk faste og har kontinuerlige tidsregningshistorier, mens land, grenser og avvik endrer seg over tid. Å bruke en representativ by gir hver sone en stabil, politisk nøytral identifikator som forblir gyldig selv når de underliggende sommertids- eller avviksreglene endres.
Kan jeg bare lagre et UTC-avvik i stedet for et sonenavn?
Bare for et enkelt fast øyeblikk. For fremtidige eller tilbakevendende hendelser bør du lagre soneidentifikatoren, fordi avvik endres med sommertid og myndighetsbeslutninger. Sonenavnet pluss databasen lar programvaren beregne riktig avvik for enhver dato automatisk.
Hvem driver prosjektet nå?
Det publiseres av IANA, som tok over forvaltningen i 2011, og koordineres av Paul Eggert med et fellesskap av bidragsytere som jobber over den offentlige tz-e-postlisten. Det tekniske arbeidet forblir en samarbeidsbasert, frivilligdrevet innsats.