Unix-aikaleima ja vuoden 2038 ongelma selitettynä

Tammikuun 19. päivänä 2038 klo 03:14:07 UTC lukuisat tietokonejärjestelmät kokevat päivämäärän ylivuotamisen — Unix-aikaleiman vastine Y2K-ongelmalle.

Syy ei ole salaperäinen tai monimutkainen. Se johtuu yhdestä päätöksestä, joka tehtiin Unixin alkuaikoina: nykyisen ajan tallentaminen 32-bittisena kokonaislukuna. Se oli järkevä valinta vuonna 1970. Vuonna 2038 tila loppuu.

Voit tarkistaa, mitä aikaleima-arvo tällä hetkellä tarkoittaa käyttämällä Unix Timestamp Converter -työkalua, joka muuntaa minkä tahansa aikaleiman — myös ongelmallisen 2 147 483 647 — luettavaksi päivämääräksi välittömästi.

Kuinka Unix-aikaleima toimii

Unix-aikaleima on sekuntimaara, joka on kulunut 1. tammikuuta 1970 klo 00:00:00 UTC:sta lähtien. Tätä aloituspistettä kutsutaan Unix-aikakaudeksi.

Tällä hetkellä aikaleima on noin 1 712 000 000 — kymmennumeroinen luku, joka kasvaa yhdellä joka sekunti.

Aikaleimaa käytetään kaikkialla tietojenkäsittelyssä: palvelinlokeissa, API-vastauksissa, tietokannan tietueissa, todennusmerkeissä, tiedostojärjestelmän metatiedoissa ja käyttöjärjestelmän sisäisesti. Se on kätevä muoto, koska yksi kokonaisluku edustaa tarkkaa hetkeä ajassa, sitä on helppo vertailla ja lajitella, ja se on aikavyöhykkeiden riippumaton.

Mitä 32-bittinen kokonaisluku voi sisältää

Etumerkillinen 32-bittinen kokonaisluku voi sisältää arvoja -2 147 483 648 ja 2 147 483 647 välillä.

Kun Unix kehitettiin, aikaleimoja tallennettiin etumerkillisina 32-bittisinä kokonaislukuina. Suurin arvo — 2 147 483 647 — vastaa klo 03:14:07 UTC:ssa 19. tammikuuta 2038.

Sekunti myöhemmin laskuri ylivuotaa. Etumerkillinen 32-bittinen kokonaisluku ei voi sisältää arvoa 2 147 483 648, joten se kiertää suurimmaksi negatiiviseksi arvoksi: -2 147 483 648. Kun sitä tulkitaan Unix-aikaleimaksi, se negatiivinen luku edustaa klo 20:45:52 UTC:ssa 13. joulukuuta 1901.

Käytännön seurauksena: kaikissa järjestelmissä, jotka tallentavat aikaleimoja etumerkillisina 32-bittisinä kokonaislukuina eivätkä käsittele tätä ylivuotamista, näytetään äkillisesti vuoden 1901 päivämäärät, kun vuosi 2038 saavutetaan.

Miksi Y2K on hyvä vertailukohta

Useimmat ihmiset ovat kuulleet Y2K-ongelmasta — huolesta siitä, että vuodet kahden numeron muodossa tallennetut tietokonejärjestelmät (99 vuodelle 1999) hajoaisivat, kun ne siirtyvät 00:ksi, mikä voitaisiin tulkita vuodeksi 1900 sen sijaan, että se olisi 2000.

Vuoden 2038 ongelma on rakenteellisesti samanlainen:

  • Molemmat johtuvat tallennusmuodosta, joka vaikutti riittävältä sen valinnan aikaan
  • Molemmat ilmenevät vain tietyssä päivämäärän raja-arvossa
  • Molemmat vaikuttavat moniin järjestelmiin samanaikaisesti
  • Molemmat ovat korjattavissa, mutta vaativat tarkoituksellista siirtotyötä

Keskeinen ero on mittakaava. Y2K vaikutti pääasiassa päivämäärämerkkijonoihin ja kaksisärkisiin vuosakenttiin sovelluksissa. Vuoden 2038 ongelma vaikuttaa perustavanlaatuiseen tietotyyppiin (32-bittinen kokonaisluku), jota käytetään käyttöjärjestelmän tasolla useilla alustoilla.

Mitkä järjestelmät ovat todella vaarassa

Ei vaarassa:

  • Modernit 64-bittiset käyttöjärjestelmät (Linux, macOS, Windows 64-bittisellä laitteistolla) — ne käyttävät 64-bittisiä aikaedustuksia
  • Useimmat modernit sovellukset, jotka on rakennettu 64-bittisille alustoille
  • Uudet järjestelmät, jotka rakennettiin vuoden 2000 jälkeen ja käyttivät 64-bittisiä kokonaislukuja alusta alkaen

Mahdollisesti vaarassa:

  • Sulautetut järjestelmät, jotka toimivat 32-bittisillä prosessoreilla — nämä ovat yleisiä teollisuuslaitteissa, lääketieteellisissä laitteissa, automatiikkajärjestelmissä, verkkolaitteissa ja kuluttajaelektroniikassa
  • Vanhat ohjelmistot, jotka on käännetty 32-bittisille järjestelmille ja tallentavat aikaleimoja muodossa time_t, eikä niitä ole koskaan päivitetty
  • Vanhat tietokannat, joissa aikaleiman sarakkeet määritettiin 32-bittisiksi kokonaisluvuiksi
  • Tiedostojärjestelmät, jotka tallentavat tiedoston muokkausajat 32-bittisina arvoina (esimerkiksi Linux ext3:lla on tämä rajoitus)
  • Jotkut verkkoprotokollat, jotka koodaavat aikaleimoja 32-bittisiksi kentiksi

Sulautettujen järjestelmien kategoria on erityisen huolestuttava, koska näillä laitteilla on usein pitkät käyttöikät, ne toimivat yksinkertaistetuilla käyttöjärjestelmillä ilman automaattisia päivityksiä, ja niiden vaihtaminen tai päivittäminen ei välttämättä ole taloudellisesti kannattavaa.

Todellisuuden vaikutukset

Teollisuus- ja infrastruktuurijärjestelmät

Sähköverkkojen, vedenpuhdistuksen, valmistuksen ja rakennusautomaation hallintajärjestelmät toimivat usein sulautetulla laitteistolla, jonka käyttöikä voi olla vuosikymmenia. Vuonna 2005 asennettu ohjelmoitava logiikkakontrolleri (PLC), joka toimii 32-bitillä firmwarella, voi olla edelleen toiminnassa vuonna 2038 — ja se saattaa käyttäytyä odottamattomasti, kun aikaleima ylivuotaa.

Rahoitusjärjestelmät

Pankki- ja kaupankäyntijärjestelmät käyttävät usein vanhaa ohjelmistoa pääkoneilla tai vanhemmilla 32-bittisillä alustoilla. Kaikki järjestelmät, jotka tallentavat tapahtumien aikaleimoja 32-bittisinä kokonaislukuina, voivat tuottaa virheellisiä aikaleimoja tai hylätä tapahtumat, joiden päivämäärät on laskettu ylivuotamisen jälkeisille arvoille.

IoT-laitteet

Halpojen, matalan virrankulutuksen mikro-ohjaimien yleistyminen IoT-laitteissa tarkoittaa, että miljoonia laitteita, joissa on 32-bittiset aikaesitykset, otetaan käyttöön ja ne säilyvät palvelussa vuoden 2038 jälkeen. Kuluttajaruuterit, älykotilaitteet, teollisuusanturit — monet niistä käyttävät 32-bittisiä Linux-ytimen tai paljasta metallisia firmwarea ilman minkäänlaista 2038-palautusta.

Tiedostojärjestelmät

Tiedostojen metatiedot — luontiajat, muokkausajat, käyttöajat — tallennetaan käyttöjärjestelmän toimesta. Järjestelmissä, joissa käytetään 32-bittisiä aikakenttia näille metatiedoille, tiedostot voivat näyttää olevan muokattu vuonna 1901 ylivuotamisen jälkeen. Tämä hajottaa varmuuskopiointiohjelmiston, versionhallinnan ja kaiken, mitä käyttää tiedoston muokkausaikaa vertailuja varten.

Mitä tapahtuu 64-bittisille järjestelmille

Etumerkillinen 64-bittinen kokonaisluku voi sisältää arvoja 9 223 372 036 854 775 807 asti.

Unix-aikaleimana tuo suurin arvo edustaa vuotta 292 277 026 596. Ei ole käytännöllistä huolestuttavuutta siitä, että 64-bittiset järjestelmät loppuisivat aikaleiman tilasta — universuumi on jo kauan loppunut ennen kuin tämä luku saavutetaan.

Useimmat modernit käyttöjärjestelmät siirtyivät 64-bittisiin aikaesityksiin paljon ennen vuotta 2038:

  • Linux 64-bittisellä laitteistolla on käyttänyt 64-bittistä time_t:ä 2000-luvun alusta lähtien
  • Linux 32-bittisellä laitteistolla ratkaisi ongelman ytimen versiossa 5.6 (julkaistu 2020), joka käyttää 64-bittistä aikarajapintaa 32-bittisillä järjestelmillä
  • macOS siirtyi 64-bittiseen aikaan OS X 10.6:ssa (2009)
  • Windows käyttää 64-bittisiä FILETIME-rakenteita, jotka ovat turvallisia yli vuoden 30 000

Jäljellä oleva riski on järjestelmissä, joissa aikaleimoja tallennetaan nimenomaisesti 32-bittisiin kokonaislukusarakkeihin tietokannoissa, tai verkkoprotokollissa, joissa 32-bittisiä aikakenttiä määritellään, sen sijaan että luotaisiin OS:n time_t-tyypin varaan.

Ratkaisu

Ratkaisu on käsitteellisesti yksinkertainen: korvaa 32-bittinen aikaleiman tallentaminen 64-bitillä. Käytännössä tämä vaatii:

1. Aikaleiman tallentamiseen käytetyn tietotyypin päivittäminen koodissa (int32_t tai time_t 32-bitillä → int64_t tai time_t 64-bitillä) 2. Tietokannan sarakkeiden siirtäminen 32-bitisistä kokonaisluvuista tai TIMESTAMP-kentistä (jotka ovat usein 32-bittisiä vanhemmissa MySQL-järjestelmissä ja vastaavissa) 64-bittisiin vaihtoehtoihin 3. Verkkoprotokollien päivittäminen siellä, missä 32-bittisiä aikakenttiä on protokollan spesifikaatiossa 4. Sulautettujen laitteiden firmwaren uudelleenkääntäminen tai korvaaminen

64-bittisillä alustoilla toimivalle ohjelmistolle ratkaisu on usein yksinkertainen uudelleenkääntäminen 64-bittisellä time_t:llä. 32-bittisellä laitteistolla toimiville sulautetuille järjestelmille se saattaa vaatia laitteiston vaihtamista.

Vaadittu ponnistus vaihtelee suuresti. Hyvin ylläpidetty verkkosovellus, joka toimii modernilla infrastruktuurilla, tarvitsee todennäköisesti minimaaliset muutokset. Perinteinen teollisuuden hallintajärjestelmä, jolla on räätälöity firmware eikä aktiivista kehitysryhmää, on paljon suurempi ongelma.

Kuinka paljon aikaa meillä on?

Kirjoitushetkellä (huhtikuu 2026) jäljellä on noin 12 vuotta 19. tammikuuta 2038.

Se kuulostaa riittävältä ajaltä. Aktiivisesti ylläpidetyille ohjelmistojärjestelmille se todennäköisesti onkin — muutokset ovat hyvin ymmärretty ja ne voidaan suunnitella ja toteuttaa järjestelmällisesti.

Hylättyjen ohjelmistojen, ylläpitämättömien sulautettujen laitteiden ja vanhalla 32-bittisellä laitteistolla toimivien perintöjärjestelmien pitkään häntään 12 vuotta ei ole niin mukava aika. Laitteet, joita on vaikeinta päivittää, ovat samoja, jotka todennäköisimmin ovat edelleen käytössä vuonna 2038.

Organisaatiot, joiden tulisi olla eniten huolissaan, ovat ne, jotka käyttävät 32-bittisiä sulautettuja järjestelmiä kriittisessä infrastruktuurissa — ja nämä ovat juuri ne organisaatiot, joilla on pienin todennäköisyys saada budjettia ja institutionaalista tietoa ongelman ratkaisemiseen proaktiivisesti.

Vuoden 2038 ongelma ei saa lentokoneita putoamaan taivaalta 19. tammikuuta 2038. Mutta jotkut järjestelmät käyttäytyvät virheellisesti, jotkut lokit näyttävät järjettömiä aikaleimoja, ja jotkut laitteet tarvitsevat hätähuollon. Mitä lähempänä olet kriittistä infrastruktuuria 32-bittisellä laitteistolla, sitä kannattavampi on tarkistaa se nyt sen sijaan, että odottaisit myöhemmin.