Mikä IANA-aikavyöhyketietokanta oikeastaan on
Jos olet koskaan käsitellyt päivämääriä ja aikoja ohjelmistossa, olet luottanut IANA-aikavyöhyketietokantaan tiesitpä sitä tai et. Se tunnetaan useilla nimillä — tz-tietokanta, tzdata, Olson-tietokanta tai zoneinfo — mutta ne kaikki viittaavat samaan asiaan: yhteistyössä ylläpidettävään, vapaasti saatavilla olevaan luetteloon maailman aikavyöhykkeistä ja niitä säätelevistä säännöistä.
Sana "luettelo" on aliarvioiva. Tietokanta ei ainoastaan listaa, millä UTC-siirtymällä mikäkin alue sijaitsee. Se tallentaa täydellisen historian siviiliajanlaskusta jokaiselle alueelle — jokaisen siirtymän muutoksen, jokaisen kesäaikasiirtymän, jokaisen sodanaikaisen kellonsiirron ja jokaisen tulevan säännön — ulottuen monissa tapauksissa 1800-luvun puoliväliin, jolloin paikallinen keskiaika väistyi standardoitujen vyöhykkeiden tieltä. Kun kalenterisovelluksesi näyttää oikein, että vuonna 1985 pidetty kokous tapahtui tunnin eri aikaan kuin sama kellonaika tänään, se on tz-tietokannan ansiota.
Se on tekstipohjainen, ihmisen luettavissa ja pieni. Käännetty binäärimuoto, joka toimitetaan tietokoneellasi, on vain muutaman megatavun kokoinen. Silti se koodaa yhden hiljaisimmista monimutkaisimmista tietojoukoista tietojenkäsittelyssä.
Lyhyt historia
Projekti alkoi 1980-luvulla Arthur David Olsonin toimesta, joka kokosi ensimmäisen version ja isännöi sitä Yhdysvaltain kansallisten terveysinstituuttien palvelimilla. Vuosikymmenten ajan sitä ylläpidettiin pääasiassa vapaaehtoisvoimin julkisen postituslistan kautta, minkä vuoksi vanhempi nimi "Olson-tietokanta" esiintyy edelleen dokumentaatiossa.
Paul Eggert otti päätoimittajan roolin ja on edelleen projektin pitkäaikainen koordinaattori. Hänen kokoamansa theory.html-dokumentti ja huolellinen versiohistoria ovat tehneet tietokannasta yhtä paljon historiallisen viitteen kuin teknisenkin.
Vuonna 2011, lyhyen mutta huolestuttavan oikeuskiistan jälkeen historiallisista tiedoista, hallinta siirtyi Internet Assigned Numbers Authoritylle (IANA), samalle elimelle, joka koordinoi muita keskeisiä internet-resursseja. IANA julkaisee nyt viralliset versiot, minkä vuoksi "IANA-aikavyöhyketietokanta" on vakiintunut nimeksi. Työn tekee edelleen sama yhteisö; IANA tarjoaa institutionaalisen kodin ja vakaan jakelupisteen.
Nimeämiskäytäntö: Alue/Paikka
Yksi tietokannan erottuvimmista piirteistä on, miten se nimeää vyöhykkeet. Maannimien tai raakojen siirtymien sijaan se käyttää Alue/Paikka-muotoa, joka on lähes aina sidottu edustavaan kaupunkiin:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
"Alue" on yleensä maanosa tai valtameri (America, Europe, Asia, Pacific), ja "Paikka" on tunnettu kaupunki vyöhykkeen sisällä. Tämä valinta vaikuttaa omituiselta, kunnes ymmärtää sen taustalla olevan logiikan.
Kaupungit ovat vakaita; poliittiset rajat ja siirtymät eivät ole. Maat jakautuvat, yhdistyvät, nimeävät itsensä uudelleen ja muuttavat kellojaan. Kaupunki sen sijaan on kiinteä maantieteellinen piste, jolla on jatkuva ajanlaskun historia. Vyöhykkeen nimeäminen America/New_York-muotoon "US Eastern Time" tai "UTC-5" sijaan tarkoittaa, että tunniste pysyy voimassa, vaikka siihen liitetyt säännöt kehittyvät.
Tietokanta myös välttää tarkoituksella maiden nimiä kiertääkseen poliittisia kiistoja ja koska yksi maa sisältää usein useita vyöhykkeitä — Yhdysvalloilla on yli tusina. Se valitsee väkirikkaimman tai historiallisesti merkittävimmän kaupungin kustakin erillisestä vyöhykkeestä neutraaliksi tunnisteeksi. Kun kahdella alueella on ollut sama kellohistoria vuodesta 1970 lähtien, ne jakavat yhden vyöhykkeen; heti kun niiden historiat eroavat, ne saavat omat merkintänsä.
Miksi raa'at siirtymät eivät riitä
Aloittelijan yleinen vaisto on tallentaa aika muodossa "UTC+5:30" ja todeta se valmiiksi. Tämä toimii yksittäiselle hetkelle, mutta se hajoaa heti, kun täytyy käsitellä tulevia tai toistuvia tapahtumia, koska siirtymät eivät ole paikan staattisia ominaisuuksia. Ne ovat sääntöjen tulosta, joita hallitukset muuttavat jatkuvasti ja usein äkillisesti.
Tarkastellaan muutamia todellisia esimerkkejä, jotka tietokanta on joutunut omaksumaan:
- Samoa ohitti kokonaan 30. joulukuuta 2011. Kohdistaakseen työpäivänsä Australiaan ja Uuteen-Seelantiin Yhdysvaltojen sijaan Samoa hyppäsi kansainvälisen päivämäärärajan yli siirtyen UTC-11:stä UTC+13:een. Saarilla asuville sitä perjantaita ei yksinkertaisesti ollut olemassa.
- Maat lakkauttavat, ottavat käyttöön tai siirtävät kesäaikaa lyhyellä varoitusajalla. Euroopan unioni on keskustellut kesäajan lopettamisesta; useat maat ja Yhdysvaltain osavaltiot ovat muuttaneet kesäaikasääntöjään viime vuosikymmeninä. Turkki, Venäjä ja muut ovat siirtäneet vakiosiirtymiään kokonaan.
- Kesäajan alku- ja loppupäivät muuttuvat. Yhdysvallat siirsi kesäaikarajojansa vuonna 2007. Mikä tahansa järjestelmä, joka kovakoodasi vanhan säännön, tuotti hiljaa vääriä aikoja viikoittain joka vuosi.
Jos tallennat vain siirtymän, et voi vastata kysymykseen "mikä on paikallinen aika Santiagossa 15. marraskuuta ensi vuonna?" — koska vastaus riippuu säännöistä, joita ei ehkä ole edes viimeistelty. Tallentamalla vyöhyketunnisteen (America/Santiago) ja tietokannan ohjelmisto voi laskea oikean siirtymän mille tahansa hetkelle, menneelle tai tulevalle, ja laskea sen automaattisesti uudelleen, kun säännöt muuttuvat.
Tämä on ydinarvolupaus: tz-tietokanta erottaa paikan identiteetin sen kelloa määrittävistä jatkuvasti muuttuvista säännöistä.
Miten sitä ylläpidetään
Ylläpito tapahtuu avoimesti. Ehdotetut muutokset — uusi kesäaikasääntö, korjattu historiallinen päivämäärä, hallituksen ilmoitus — keskustellaan julkisella tz-postituslistalla, jossa osallistujat viittaavat virallisiin lehtiin, uutisraportteihin ja hallituksen asetuksiin todisteina. Tarkkuus otetaan vakavasti; erityisesti historiallisten tietojen muutoksia tarkastellaan alkuperäislähteitä vasten.
Julkaisut versioidaan vuodella ja kirjaimella: 2024a, 2024b, 2024c ja niin edelleen. Numero on vuosi; kirjain kasvaa jokaisella julkaisulla sinä vuonna. Koska hallitukset ilmoittavat kellonmuutoksista omilla arvaamattomilla aikatauluillaan, julkaisurytmiä ei ole kiinteää — hiljaisena vuonna saattaa olla kaksi julkaisua, kun taas poliittisen muutoksen vuonna niitä on monia. Järjestelmien odotetaan päivittyvän nopeasti, koska vanhentunut tietokanta voi tarkoittaa väärän ajan näyttämistä säännönmuutoksen tultua voimaan.
Ketkä ovat riippuvaisia siitä
Lähes kaikki.
- Käyttöjärjestelmät. Linux-jakelut toimittavat
tzdata-paketin ydinkomponenttina. macOS saa vyöhyketietonsa samasta lähteestä. Windows käyttää omia rekisteripohjaisia vyöhykkeitään perinteisistä syistä, mutta paljastaa IANA-vyöhykkeet ICU-kirjaston ja nykyaikaisten APIen kautta. - Ohjelmointikielet. Käytännössä jokainen kypsä päivämäärä/aika-kirjasto lukee tai sisältää tz-tietokannan: Pythonin
zoneinfo, Javanjava.time, ICU-projekti, PostgreSQL, JavaScript-moottorit ICU:n kautta, Ruby, PHP ja monet muut. - Sovellukset. Kalenterit, varausjärjestelmät, rahoituskaupankäyntialustat, lokianalyysityökalut ja ajanvarauspalvelut kaikki nojaavat siihen, yleensä ilman että kehittäjät ajattelevat sitä.
Tämä kaikkiallisuus on juuri syy, miksi tietokanta on niin tärkeä. Yksi, yhteinen, huolellisesti ylläpidetty totuuden lähde tarkoittaa, että yhdessä järjestelmässä varattu kokous näkyy oikein toisessa, käyttöjärjestelmien ja kielten yli, vuosikymmeniä menneisyyteen tai tulevaisuuteen.
Jos haluat tutkia vyöhykkeitä itse, selaa täydellistä listaa IANA aikavyöhykkeet tai katso, miten ne kartoittuvat maapallolle hakemistossamme kaikki aikavyöhykkeet.
Usein kysytyt kysymykset
Onko tz-tietokanta sama kuin tzdata, zoneinfo ja Olson-tietokanta?
Kyllä. Nämä ovat kaikki nimiä samalle projektille. "tzdata" viittaa yleensä tiedostopakettiin sellaisena kuin se on toimitettu käyttöjärjestelmälle, "zoneinfo" käännettyyn binäärihakemistoon ja "Olson-tietokanta" on vanhempi historiallinen nimi perustaja Arthur David Olsonin mukaan. Nykyään virallinen nimi on IANA-aikavyöhyketietokanta.
Kuinka usein tietokantaa päivitetään?
Kiinteää aikataulua ei ole. Julkaisut laukaisevat reaalimaailman tapahtumat — hallitus muuttaa kesäaikasääntöjään tai vakiosiirtymää, tai korjaus historiallisiin tietoihin. Jotkut vuodet näkevät yhden julkaisun; toiset useita. Jokainen nimetään kuten 2024a, 2024b, kirjain kasvaa vuoden aikana.
Miksi se nimeää vyöhykkeet kaupunkien mukaan kuten America/New_York?
Kaupungit ovat maantieteellisesti kiinteitä ja niillä on jatkuva ajanlaskun historia, kun taas maat, rajat ja siirtymät muuttuvat ajan myötä. Edustavan kaupungin käyttäminen antaa jokaiselle vyöhykkeelle vakaan, poliittisesti neutraalin tunnisteen, joka pysyy voimassa, vaikka taustalla olevat kesäaika- tai siirtymäsäännöt muuttuvat.
Voinko tallentaa vain UTC-siirtymän vyöhykenimen sijaan?
Vain yksittäiselle kiinteälle hetkelle. Tuleville tai toistuville tapahtumille sinun tulisi tallentaa vyöhyketunniste, koska siirtymät muuttuvat kesäajan ja hallituksen päätösten myötä. Vyöhykenimi ja tietokanta antavat ohjelmiston laskea oikean siirtymän mille tahansa päivämäärälle automaattisesti.
Kuka pyörittää projektia nyt?
Sen julkaisee IANA, joka otti hallinnan vuonna 2011, ja sitä koordinoi Paul Eggert yhteisön kanssa, joka työskentelee julkisella tz-postituslistalla. Tekninen työ on edelleen yhteistyöhön perustuva, vapaaehtoisvoimin tehtävä ponnistus.