Vuoden 2038 ongelma

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 4. elokuuta 2022 tarkistetusta versiosta . vahvistus vaatii 1 muokkauksen .

Vuoden 2038 ongelmana tietojenkäsittelyssä on  odotettavissa ohjelmistovikoja 19.1.2038 aattona . Tämä ongelma vaikuttaa ohjelmiin ja järjestelmiin, jotka käyttävät POSIX -standardinmukaista ajanesitystä ( UNIX-aika ), joka on sekuntien määrä, joka on kulunut keskiyöstä 1. tammikuuta 1970 . Tämä ajan esitys on standardi Unix -tyyppisille käyttöjärjestelmille (johtuen C -kielen yleisestä käytöstä ).

Kuvaus

Vanhemmat 32-bittiset järjestelmät (ennen 1990-luvun puoliväliä) käyttivät tietotyyppiä time_tsekuntien tallentamiseen 32-bittisenä etumerkillisenä kokonaislukuna. Viimeisin päivämäärä, joka voidaan esittää tässä muodossa POSIX -standardissa  , on 03:14:07, tiistai 19. tammikuuta 2038 UTC .

Myöhempi aika saa tällaisen tietokentän muuttumaan negatiiviseksi, jolloin aika silmukoituu (koska ohjelmat voivat tulkita negatiivisen luvun ajankohtana vuonna 1970 tai 1901 toteutuksesta riippuen). Tämän seurauksena kaikki laskelmat, jotka sisältävät 19. tammikuuta 2038 myöhemmän päivämäärän, voivat aiheuttaa ohjelman kaatumisen tai virheellisiä laskelmia.

Y2038-ongelmaan ei ole yksinkertaista ratkaisua olemassa oleville käyttöjärjestelmien ja sovellusohjelmistojen yhdistelmille. Tyyppimääritelmän muuttaminen time_t64-bittiseksi rikkoo ohjelmien, olemassa olevien tallennettujen tietojen ja kaiken muun, joka käyttää binaarista ajanesitystä, binaarisen yhteensopivuuden. Ja suoratoisto time_tetumerkittömään kokonaislukuun voi rikkoa ohjelmat, jotka laskevat aikaeroja.

Useimmat 64-bittisten arkkitehtuurien käyttöjärjestelmät käyttävät jo 64-bittistä kokonaislukuesitystä time_t. Siirtyminen tällaisiin arkkitehtuureihin on jo käynnissä, ja sen odotetaan valmistuvan vuoteen 2038 mennessä.

Tämän lisäksi 32-bittinen muoto time_tsisältyy myös tiedostomuotomäärittelyihin, kuten kaikkialla olevaan ZIP -arkistomuotoon . Tiedostomuoto voi olla olemassa niin kauan kuin useita tietokoneiden sukupolvia, mikä tarkoittaa, että Y2038-ongelma pysyy ajan tasalla.

64-bittisen muodon käyttöönotto tuo uuden "loopback"-päivämäärän: koska enimmäisarvo on sekuntia, se tapahtuu noin 292 miljardin vuoden kuluttua [1] , mikä on paljon pidempi kuin maailmankaikkeuden ikä .

Microsoft Windows

Vuosi 2038 -ongelma koskee myös Windowsin 32-bittisiä versioita , koska merkittävä osa itse käyttöjärjestelmästä ja suuri määrä sen ohjelmia on kirjoitettu C / C ++ -kielellä . Windows-kehittäjät väittävät [2] , että he ovat korjanneet suurimman osan tämän ongelman aiheuttamasta koodista, mutta he eivät voi antaa takeita kolmannen osapuolen ohjelmistoista.

Linux

Linux-ytimen versiosta 5.6 lähtien (ydin 5) ongelma on ratkaistu, mutta vuodesta 2020 lähtien on valtava määrä ohjelmistoja, jotka on vielä korjattava [3] .

MySQL

Suositulla MySQL- ja SQL Server -tietokantajärjestelmällä TIMESTAMP-tyypille on joitain rajoituksia: arvot, jotka sisältävät päivämäärän ja kellonajan TIMESTAMP-kentässä, ovat välillä '1970-01-01 00:00:01 UTC' ja '2038-01 -19 03:14 :07 UTC' [4] .

Katso myös

Muistiinpanot

  1. ↑ sekuntia on noin ≈ vuotta
  2. ↑ Vuoden 2038 ongelma - GES Windows 7:ssä - Site Home - MSDN-blogit . Käyttöpäivä: 5. tammikuuta 2011. Arkistoitu alkuperäisestä 9. heinäkuuta 2011.
  3. ↑ Michael Larabel. Linux 5.6 on ensimmäinen ydin 32-bittisille järjestelmille, joka on valmis toimimaan viime vuonna 2038 (29. tammikuuta 2020). Haettu 13. helmikuuta 2020. Arkistoitu alkuperäisestä 6. helmikuuta 2020.
  4. ↑ MySQL Dev . Haettu 9. tammikuuta 2013. Arkistoitu alkuperäisestä 9. tammikuuta 2013.
 Päivämääräongelmat ohjelmoinnissa