Käytä UTC-aikaa sovelluksissa

Universal time, Coordinated eli lyhemmin UTC tai koordinoitu yleisaika on nollameridiaanilla käytetty aikavyöhyke. UTC-aikaan ei vaikuta vuodenaika eli mahdollinen kesä- ja talviajan vaihtelu. Yleensä kaikissa järjestelmissä on helppo toimia UTC-ajan puitteissa, eikä sen käyttäminen vaadi erityisiä muunnoksia.

Mitä hyötyä on UTC-ajan käyttämisestä sovelluksen sisäisenä aikana? UTC-aika helpottaa ajan käsittelyä sovelluksen sisällä ainakin Suomessa, koska talvi- ja kesäaikaa ei tarvitse huomioida muuten kuin korkeintaan käyttöliittymässä. Sovelluksen ulkoisissa rajapinnoissa on hyvä käyttää UTC-aikaa, koska mikäli sovelluksen rajapintoihin ollaan yhteydessä muualta kuin Suomen aikavyökkeeltä, ei asiakassovellusten tarvitse välttämättä tehdä lainkaan muunnoksia aikavyöhykkeiden välillä (jos myös asiakas käyttää UTC-aikaa sisäisesti) eikä asiakassovelluksen tarvitse huomioida Suomen kesä- ja talviajan vaihtelua.

Käytännössä ainoastaan ihmiskäyttäjää kiinnostaa tietää mitä sovelluksen käyttämä aika on käyttäjän paikallisessa aikavyöhykkeessä. Käyttöliittymässä on hyvin yksinkertaista tehdä muunnokset UTC-ajasta paikalliseen aikaan ja takaisin. Usein ainoastaan käyttöliittymä tietää mikä on käyttäjän paikallinen aika, ellei käyttäjän aikavyöhykettä sitten välitetä jatkuvasti taustajärjestelmään ja toteuteta taustajärjestelmässä tarvittavat muunnokset. Aikavyöhykkeen esitysongelmat tulevat esiin erityisesti paikkariippumattomien asiakassovellusten, kuten puhelinten ja muiden kannettavien laitteiden kanssa sekä selainpohjaisissa sovelluksissa, joita käytetään monelta aikavyöhykkeeltä.

UTC-aikaa käyttävä palvelinsovellus on helppo asentaa tai siirtää toiselle aikavyöhykkeelle. Palvelinsovellus toimii oikein eikä käyttöympäristön aikavyöhyke sotke aikaleimoja suuntaan tai toiseen. Mikäli sovellusta käytetään monikansallisessa ympäristössä, käyttöympäristö voi hyvinkin vaihtua toiseen maahan sovelluksen elinkaaren aikana.

UTC-ajan käyttö helpottaa sovelluksen testaamista. Kesä- ja talviajan vaihtumiset aiheuttavat usein yllättäviä tilanteita, mikäli testaamista ei ole suoritettu huolella. UTC-ajan käyttäminen sovelluksen sisällä ei poista kesä- ja talviajan vaihtumisen testaamisen tarvetta käyttöliittymästä, mutta muualta järjestelmästä ongelman pitäisi hävitä.

Olen nähnyt useita projekteja, joissa aikavyöhykeongelmien tai kesä- ja talviaikaongelmien huomioiminen tai huomiotta jättäminen projektin alussa on tuottanut ongelmia projektin edetessä tai vasta tuotantokäytössä.

Eräässä järjestelmässä samaa palvelinsovellusta ajettiin yhden maan sisällä kahdessa eri paikassa. Koska kyseessä oli suuri maa ja nämä kaksi eri paikkaa sijaitsivat eri aikavyöhykkeillä, eivät sovelluksen eri instanssit toimineet keskenään suunnitellusti. Ongelma johtui siitä, että molemmat instanssit toimivat eri aikavyöhykkeillä, eikä tätä oltu mitenkään huomoioitu sovellusten välisessä tiedonsiirrossa. Vastaavia ongelmia ei olisi ilmennyt, mikäli koko järjestelmä olisi toiminut UTC-ajassa.

Toisessa järjestelmässä palvelinsovellus toimi yhdellä aikavyöhykkeellä ja palvelimen asiakkaat ympäri maailmaa. Järjestelmässä ei oltu huomioitu toimimista usealla aikavyöhykkeellä, vaikka se oli keskeistä järjestelmän toiminnan kannalta. Järjestelmän sisällä aikaleimat olivat aluksi käytännössä satunnaisia, koska aikavyöhyketietoja ei ollut käytettävissä. Ongelmia ei toki olisi ollut, mikäli sovelluksen rajapinnoissa olisi välitetty aikavyöhyketieto ja rajapintojen takana olisi tehty sopivia muunnoksia. Näin kansainvälisessä sovelluksessa olisi kuitenkin kannattanut käyttää palvelimella pelkästään UTC-aikaa, koska aikaleimojen muuttaminen paikalliseen aikaan ei olisi kuitenkaan hyödyttänyt ylläpitäjiä. Asiakassovelluksien käyttämä aika olisi ollut hyödyllistä pitää myös UTC-aikana, koska käyttäjän oletettiin liikkuvan maasta toiseen, jolloin käyttäjän päätteenkin aikavyöhykkeen voi olettaa vaihtuvan. Lisäksi kaikkien osapuolten käyttäessä UTC-aikaa sisäisesti ja rajapinnoissaan ei minkään osapuolen tarvitsisi tehdä aikavyöhykemuunnoksia kuin korkeintaan käyttöliittymässä.

Kolmantena esimerkkinä vielä tilanne, jossa palvelinsovelluksen tiedetään pysyvän yhdellä aikavyöhykkeellä eikä sen sijaintia aiota ikinä vaihtaa toiselle aikavyöhykkeelle. Vaikka mielestäni on rohkeata olettaa, että hyödyllistä sovellusta ei ikinä siirretä muualle eikä siihen tule ulkoisia kansainvälisesti käytettäviä rajapintoja, tämä lienee yleisin argumentti paikallisen ajan käyttämiseen sovelluksen sisällä. Mielestäni kuitenkin UTC-ajan käyttäminen tällaisessakin tapauksessa on hyödyllistä, koska UTC-aikavyöhykkeen käytöllä vältetään ongelmat kesä- ja talviajan kanssa. Esimerkiksi ajastuksia käytettäessä täytyy huomioida, että talviaikaan siirryttäessä kellonaika siirtyy tunnilla taaksepäin. Jos talviaikaan siirtymistä ei huomioi, saattaa käydä niin, että ajastettu operaatio suoritetaan kahdesti ja tästä aiheutuu virhetoimintaa.

Vaikka järjestelmä toimii sisäisesti UTC-ajassa, pitää käyttäjän edelleen käyttää järjestelmää omassa ajassaan ja huomoioida sovelluksen käyttö halutussa aikavyöhykkeessä. Jos esimerkiksi sovelluksen tarjoaman palvelun laskutus riippuu kellonajasta siten, että osa päivästä on halvempaa kuin muuten, pitää käyttäjän luonnollisesti konfiguroida sovelluksen laskutus nimenomaan haluttuun aikavyöhykkeeseen nähden. Jos käytössä on kaksi instanssia sovelluksesta kahdessa eri aikavyöhykkeessä, kuten aiemmassa esimerkissä, pitää olla erityisen tarkkana, että palvelun laskutus toimii molemmissa aikavyöhykkeissä perustuen oikeaan aikaan. Jos kahden instanssin järjestelmässä olisi erillinen laskutuspalvelu ja molemmista instansseista tulisi UTC-aikaleimoja, pitäisi laskutuspalvelun kohdella erillisiä instansseja kuitenkin eri tavalla, vaikka kaikki käyttäisivät UTC-aikaa. Aikavyöhykkeet aiheuttavat siis ongelmia, vaikka sovelluksessa olisi olisi käytössä sisäisesti vain yksi aikavyöhyke.

Mitä haittaa on UTC-ajan käyttämisestä sovelluksen sisällä? Ensinnäkin useimmiten kaikki järjestelmät toimivat oletuksena paikallisessa ajassa. Aluksi on työlästä selvittää ja huomioida eri järjestelmien konfigurointi UTC-aikaan tai järjestää yhteensopivuuskerros, joka paikallisen aikavyöhykkeen huomioi. Sovelluksen ylläpitäjän täytyy mahdollisesti oppia huomioimaan se, että aikaleimat ovat lokeissa ja tietovarastoissa UTC-ajassa. Mikäli järjestelmässä mahdollisesti olevat ajastukset konfiguroidaan UTC-ajassa, ylläpitäjän pitää tämäkin huomioida konfigurointeja tehdessään.

Itse rinnasta aikavyöhykeongelman kaikille tuttuun merkistön koodausongelmaan. Useimmiten merkistöongelmat ratkeavat, kun sovellus käyttää mahdollisimman useassa kohtaa vain ja ainoastaan UTF-8 -koodausta. Tästä on helppo tehdä tarvittavat muunnokset ja toisaalta järjestelmän on helpompaa toimia sisäisesti vain yhdessä merkistökoodauksessa. Analogisesti järjestelmän on helpompaa toimia sisäisesti vain yhdessä aikavyöhykkeessä ja konversiot tehdään vai järjestelmän ulkopuolisia tahoja varten, joista yksi on loppukäyttäjä.

Ajan kanssa tulee olla joka tapauksessa tarkkana, sillä varsinkin viranomaiskäytössä sekä esimerkiksi laskutuksessa väärä aikaleima voi merkittävästi vaikuttaa palvelun oikeellisuuteen.