Vuoden 2038 ongelma tai bugi vuoden 2038 (Kanada), joka tunnetaan myös nimellä Y2038 , on tietokone bugi samanlainen vuoteen 2000 vika , joka saattaa häiritä monien järjestelmien IT19. tammikuuta 2038on 3 h 14 min 8 s , yleinen aika . Sitten ne näkyvät13. joulukuuta 1901ja 20 h 45 min 52 s .
Tämä vika mahdollisesti vaikuttaa kaikkiin toimivia järjestelmiä ja ohjelmia , jotka käyttävät 32-bittistä tasalla edustus . Se vaikuttaa tiedostomuotoja (kuten ZIP ), tiedostojärjestelmät (kuten FAT tiedosto järjestelmää käytetään useimmissa USB-asemat ja flash-kortit) ja käyttöjärjestelmissä kaikilla tasoilla (pois ytimen järjestelmän toimintaan vuonna ohjelmointikieliä ), tai jopa reaaliaikainen kello itse.
Asia koskee ohjelmistoa, joka käyttää ajan POSIX-esitystä , jossa aika esitetään sekunteina, jotka ovat kuluneet1 st päivänä tammikuuta 1970keskiyöllä ( 0 tuntia ) universaaliaikaa . 32-bittisissä tietokoneissa eniten vaikuttavat käyttöjärjestelmät edustavat tätä lukua 32-bittisenä allekirjoitettuna kokonaislukuna, joka rajoittaa sekuntien määrän 231 - 1: een tai 2147483 647 sekuntiin (01111111 11111111 11111111 11111111 binäärisenä ). Tämä enimmäismäärä saavutetaan19. tammikuuta 2038on 3 h 14 min 7 s (Universal Time). Seuraavassa sekunnissa aikaesitys "silmukkaa" (10000000 00000000 00000000 00000000 binäärisenä) ja edustaa −2 147 483 648 kahden täydennyksessä , joten tietokone näyttää päivämäärän päivämäärän13. joulukuuta 1901.
Ohjelmistoa, jota tämä koskee, on hyvin paljon, koska UNIX- järjestelmien innoittamaa POSIX- standardia on käytetty monissa C-kielellä kirjoitetuissa ohjelmissa monille käyttöjärjestelmille. Niillä Unix-tyyppisillä, jotka edustavat aikaa allekirjoittamattomalla 32-bittisellä kokonaisluvulla (POSIX-standardin mukaiset), määräaika on vuonna 2106 eikä vuonna 2038. Nämä käyttöjärjestelmät ovat kuitenkin vähemmistössä. Siirtyminen aikaleima on 64 bittiä otettaisiin käyttöön uusi määräaika makaa sunnuntai4. joulukuuta 292277026596ap. BC 15 h 30 min 8 s (noin 21 kertaa ikä maailmankaikkeuden ) ja siten ratkaista ongelman, koska 64 bittiä sallisi tietokone työntää raja 2 63 - 1 sekuntia.
Sovellusalueella ongelma paljastettiin jo 2010-luvulla , kun vuosi 2000 oli paljastettu jo 1980-luvulla pitkän aikavälin suunnitelmien aikatauluissa ( laskentataulukoissa on sittemmin käytetty joko liukuvia päivämääriä tai pitkää muotoa) .
Tälle ongelmalle ei ole olemassa yhtä ainoaa korjausta, koska 32-bittiset aikaleimat ovat myös useissa nykyisissä tiedostomuodoissa (esim. ZIP-muodossa ). Tietokoneiden esityksen muutos tekisi ohjelmat käyttökelvottomaksi hyödyntämällä sisäisen esityksen ja tiedostomuodon nykyistä vastaavuutta. Siksi "kulissien takana" tarvitaan paljon työtä, jotta pinnalle ei tule melkein mitään, mikä oli jo tapahtunut vuoden 2000 lähestyessä.
Monilla nykyisin käytössä olevilla tietorakenteilla on aikaesitykset 32-bittisessä muodossa , erityisesti tunnetuimpia varten:
Esimerkkejä 32-bittisiä aikamuotoja käyttävistä järjestelmistä:
Kaikki 64-bittistä Linux-ydintä käyttävät käyttöjärjestelmät ovat immuuneja.
Linux-ytimen versiossa 3.17 käytetään 64 bitin päivämäärien sisäistä esitystä, joka valmistelee muut tarvittavat mukautukset C-standardikirjastojen ja sitten sovellusten tasolla.
AndroidLääkemalva versio 6.0 on Android perustuu Linux 3.10 ydin ei sisällä mitään korjauksia.
WindowsIn Visual C 8, aika on koodattu 64 bittiä oletuksena.
Visual C 7.1: ssä kehittäjän on käytettävä nimenomaisesti 64-bittistä aikaa.
Päivämääriä pidetään nyt allekirjoittamattomina, mikä pidentää niiden elinikää 68 vuodella.
Seuraavat järjestelmät koodaavat päivämääränsä 64 bitillä:
Verkon aikaprotokolla (NTP) käyttää peruspäivämäärää1. st tammikuu 1900koodattu 64 bitille, joista 32 bittiä edustaa sekunteja. Joten siihen ei liity vuoden 2038 virhe, vaan vuoden 2036 virhe.
NTPv4 käyttää "aikanumero" - ja "aikakauden alku" -kenttiä, jotka ohittavat virheen.
Seuraavat protokollaversiot käyttävät 128 bitin koodattuja päivämääriä, joista 64 bittiä edustaa sekunteja.
Vuosi 2038 -virheen seurauksena syntyviin ongelmiin ei ole olemassa yhtä koon ratkaisua. Kaikki muutokset ajan merkitsemiseksi käytetyn muuttujatyypin määrittelyyn time_taiheuttaisivat koodin yhteensopivuusongelmia kaikissa. sovellukset, joissa päivämäärän ja ajan esitys riippuu järjestelmästä, joka on suunniteltu toimimaan 32-bittisen allekirjoitetun kokonaisluvun kanssa. Esimerkiksi vaihtaminen time_tallekirjoittamattomaan 32-bittiseen kokonaislukuun, mikä mahdollistaisi järjestelmien käytön vuoteen 2106 asti, aiheuttaisi komplikaatioita ohjelmille, jotka manipuloivat tietoja, joiden päivämäärät edeltävät vuotta. Vuosi 1970, koska tällaisia päivämääriä edustaisivat negatiiviset kokonaisluvut. Lisäksi muuttujan laajentaminen time_t64-bittiseksi kokonaisluvuksi nykyisissä järjestelmissä tuottaisi yhteensopimattomia muutoksia rakenteiden organisaatiossa ja tiettyjen toimintojen binäärirajapinnassa.
Yksinkertaisin ehdotettu ratkaisu on muuttaa järjestelmää, menee 32 bittiä ja 64 bittiä . Itse asiassa useimmat tietokonejärjestelmät, jotka on suunniteltu käyttämään 64-bittistä laitteistoa, toimivat jo time_t64-bittisillä muuttujilla .