Problema anului 2038

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 4 august 2022; verificarea necesită 1 editare .

Problema Anului 2038 în calcul  este de așteptat erori de software în ajunul zilei de 19 ianuarie 2038 . Această problemă va afecta programele și sistemele care utilizează reprezentarea standard POSIX a timpului ( timpul UNIX ), care este numărul de secunde care au trecut de la miezul nopții , 1 ianuarie 1970 . Această reprezentare a timpului este standardul pentru sistemele de operare asemănătoare Unix (datorită utilizării omniprezente a limbajului C ).

Descriere

Sistemele mai vechi pe 32 de biți (înainte de mijlocul anilor 1990) foloseau un tip de date time_tpentru a stoca secundele ca un întreg semnat pe 32 de biți. Cea mai recentă dată care poate fi reprezentată în acest format în standardul POSIX  este 03:14:07, marți, 19 ianuarie 2038 UTC .

O dată ulterioară va face ca un astfel de câmp de date să devină negativ, astfel încât timpul să fie în buclă (deoarece un număr negativ poate fi interpretat de programe ca un timp în 1970 sau 1901, în funcție de implementare). În consecință, orice calcule care includ o dată ulterioară datei de 19 ianuarie 2038 pot cauza blocarea programului sau pot duce la calcule eronate.

Nu există o soluție simplă la problema Y2038 pentru combinațiile existente de sisteme de operare și aplicații software. Schimbarea definiției tipului time_tla 64 de biți va rupe compatibilitatea binară a programelor, a datelor stocate existente și a oricărui alt lucru care utilizează o reprezentare binară a timpului. Și turnarea time_tla un întreg fără semn poate rupe programele care calculează diferențele de timp.

Majoritatea sistemelor de operare pentru arhitecturi pe 64 de biți folosesc deja o reprezentare întregă pe 64 de biți în time_t. Tranziția la astfel de arhitecturi este deja în curs și este de așteptat să fie finalizată până în 2038.

În plus, formatul pe 32 de biți time_teste inclus și în specificațiile formatului de fișier, cum ar fi formatul omniprezent de arhivă ZIP . Formatul de fișier poate exista atâta timp cât mai multe generații de computere, ceea ce înseamnă că problema Y2038 va rămâne relevantă.

Introducerea formatului pe 64 de biți introduce o nouă dată „loopback”: întrucât valoarea maximă va fi secunde, aceasta va avea loc în aproximativ 292 de miliarde de ani [1] , ceea ce este mult mai lung decât vârsta Universului .

Microsoft Windows

Problema Anului 2038 este relevantă și pentru versiunile pe 32 de biți ale Windows , deoarece o parte semnificativă a sistemului de operare în sine și un număr mare de programe pentru acesta sunt scrise în C / C++ . Dezvoltatorii Windows susțin [2] că au remediat majoritatea codului afectat de această problemă, dar nu pot oferi nicio garanție cu privire la software-ul terților.

Linux

Începând cu versiunea 5.6 a nucleului Linux (kernel 5), problema a fost rezolvată, dar din 2020, există o cantitate imensă de software care trebuie să fie remediat [3] .

MySQL

Popularul SGBD MySQL și SQL Server pentru tipul TIMESTAMP are câteva limitări: valorile care conțin data și ora în TIMESTAMP sunt în intervalul „1970-01-01 00:00:01 UTC” până la „2038-01”. -19 03:14:07 UTC' [4] .

Vezi și

Note

  1. ↑ secunde este aproximativ ≈ ani
  2. ↑ Problemă din anul 2038 - GES pe Windows 7 - Site Home - MSDN Blogs . Data accesului: 5 ianuarie 2011. Arhivat din original pe 9 iulie 2011.
  3. ↑ Michael Larabel. Linux 5.6 este primul kernel pentru sistemele pe 32 de biți gata să ruleze în ultimul an 2038 (29 ianuarie 2020). Consultat la 13 februarie 2020. Arhivat din original pe 6 februarie 2020.
  4. ↑ MySQL Dev . Consultat la 9 ianuarie 2013. Arhivat din original pe 9 ianuarie 2013.
 Probleme de date în programare