19 януари 2038 г.: Денят, в който времето свършва

С помняте ли си 1999 г., когато всички се вълнуваха от Проблем 2000?

Страхът беше, че когато 99-та година премине в 00-та, компютрите няма да могат да разберат, че векът се е променил; датата ще бъде върната обратно на 1900 г. и компютърно зависимите системи по целия свят ще се сринат и изгорят. Резултатът? От „няколко забавни грешки в електронните календари“ до „буквален срив на цивилизацията, каквато я познаваме“, в зависимост от това кого питате, припомня IFLscience.

В крайна сметка, разбира се, новата година се оказа сравнително безпроблемна - в немалка степен благодарение на широко разпространените и съгласувани усилия зад кулисите да се избегне катастрофата. И това беше всичко, нали? Спокойно плаване оттук нататък?

Чакай - има продължение?

Какъв е проблемът през 2038 г.?

19 януари 2038 г.: денят, в който времето свършва. Поне ако сте компютър, който използва 32-битово Unix време - а това правят почти всички. 

„Подписаното 32-битово цяло число може да съхранява само числа от -2147483648 до 2147483647“, обяснява Tanium, компания за киберсигурност и управление на системи със седалище в Къркланд, Вашингтон. „Това означава, че най-високият времеви печат, с който тези системи могат да работят, е 2147483647, който съответства на 19 януари 2038 г., 03:14:07 UTC.“ 

За една 32-битова система това е твърде много цифри, за да ги задържи - затова броячът прави единственото, което му е достъпно, и се връща отново в началото.

„Времевата марка ще се препълни и ще стане отрицателно число, което ще доведе до грешка в датата и часа“, обясняват от Tanium.

„Например, времевият печат за [03:14:08 UTC] 20 януари 2038 г. в Unix време е 2147483648. Тъй като това не е валиден времеви печат, използвайки формата на Unix, той ще се препълни и ще стане -2147483648, което съответства на 13 декември 1901 г., в 20:45:52 UTC. Това е грешката от 2038 г.“

Трябва ли да се притесняваме?

След цялата шумотевица около Проблема 2000 или Y2K се надяваме да сме си научили урока, когато става въпрос за подготовка. В края на краищата знаем за грешката от 2038 г. поне от 2006 г., когато подобен проблем засегна софтуера, поддържащ уеб сървъра на AOL - със сигурност 32 години са повече от достатъчно време за намиране на решение? 

Всъщност проблемът с 2038 г. може да се реши много лесно, и то направо пред очите ни: Пол Буде, главен изпълнителен директор на независимата консултантска компания Paul Budde Consulting, пише в Independent Australia през 2022 г.: „Решението е да се премине към 64-битова поддръжка на времето“.

„С 64 бита има повече от достатъчно място за съхраняване на времеви стойности далеч след обозримото бъдеще, дори ако се използват времеви стойности с висока разделителна способност (базирани на наносекунди).“, казва той.

Шестдесет и четири може и да не изглеждат толкова много по-големи от 32 - но когато боравим с експоненти, това е разликата между „13 години“ и „около 21 пъти възрастта на Вселената“. Можем да кажем, че преминаването към по-голяма система за съхранение ще отложи проблема толкова много, че той може да бъде и напълно решен. И така, масово ли сме преминали към тази система? 

Ами... не. „Няколко типа бази данни, включително релационни и NoSQL бази данни“ все още разчитат на 32-битово време, посочва Tanium, както и всички програми, написани на езици, базирани на C, като C++ и PHP. Те отбелязват, че устройствата, работещи под Windows, Linux, Android или iOS, могат да бъдат изложени на риск, както и „медицински устройства, промишлени системи за управление на съоръжения като електроцентрали, транспортни системи, автомобили с бордови компютърни системи, които наблюдават електронния контрол на стабилността и контрола на сцеплението, маршрутизатори, превключватели, сензори, датчици и IoT устройства като интелигентни уреди“.

Като цяло, тя има потенциал да бъде изключително разрушителна. И така, доколко сме готови за него?

Готови ли сме за грешката от 2038 г.?

Трудно е да се каже колко точно сме готови за 2038 г. - с въвеждането на по-нови операционни системи много от тях стандартно разполагат с 64-битово цяло число. По-големият проблем обаче е с вече съществуващите системи: преминаването от 32- към 64-битово време за операционните системи с изходен код „далеч не е тривиално“, пише Михал Гурни, разработчик на Linux дистрибуцията Gentoo, в публикация в блога 2024 по темата.

„Преди всичко става дума за преломна промяна на ABI. Това е „всичко или нищо“, пише той. „Ако дадена библиотека използва time_t в своя API, всичко, което се свързва с нея, трябва да използва същата ширина на типа [...] смесването на програми и библиотеки с time32 и time64 може да доведе до ужасни грешки по време на изпълнение.“

В общи линии внезапното преминаване от 32-битови към 64-битови времеви марки ще накара куп вече съществуващи програми да се борят да разберат новата система. Това е все едно да се пренесете в средновековна Англия и да искате да общувате с местните жители: технически ще говорите на един и същ език, но практически? Нямаше да знаете напълно какво се случва във всеки един момент.

И това е само началото. Имахме - и все още имаме - много време да се подготвим за проблема през 2038 г., а когато той настъпи, „всички настоящи компютърни системи ще бъдат модернизирани много преди това“, прогнозира Буде. „Въпреки това [...] повечето от тези проблеми ще бъдат в стари програми, които никой никога не си спомня да актуализира и тества“, предупреждава той - „това не е нещо, което компютърните инженери биха искали да оставят за последния момент, както се случи с проблема Y2K“.

Дори ако всяка 32-битова система, зависима от времето, бъде намерена и обновена, последствията от такива масови промени „първо ще трябва да бъдат картографирани, а след това задълбочено проучени, за да се намерят подходящи решения, които да предотвратят нежелани странични ефекти“, предупреждава Буде. „И на свой ред тези решения могат да създадат свои собствени странични ефекти.“

Така че... да. Стискаме палци, а, хора?

Да се учим от грешките си

Слушайте: нека бъдем оптимисти. Да речем, че напълно решим проблема с 2038 г. и всички свързани с него вълнообразни ефекти и никоя компютъризирана система няма дори и едно забиване в 03:14:08 ч. на 20 януари 2038 г. Можем ли всички просто да въздъхнем с облекчение и да забравим за цялото това нещо?

Е, можем, но вероятно не трябва да го правим. Само след няколко десетилетия отново ще се сблъскаме със същото нещо: на 7 февруари 2106 г., в 06:28:15 UTC, проблемът ще засегне всички системи, които съхраняват времето като цяло число без знак (unsigned 32-bit integer) - т.е. използват същия брой цифри, но не дават нито една от тях за отрицателни числа.

Превъртете напред приблизително същия период от време и Windows ще се сблъска със своя собствена версия на грешката: „Windows NT използва 64-битово цяло число за проследяване на времето“, отбелязва HowStuffWorks. „То обаче използва 100 наносекунди като стъпка, а началото на времето е 1 януари 1601 г., така че NT страда от проблема с 2184 година.“

Покрай това има проблем с 2262 г., проблем с 2262 г. и дори проблем с 2446 г. Всички те са свързани с предположенията на програмистите от миналото за това колко дълго ще продължим да използваме протоколите, изобретени в средата на 20-ти век. Бихме казали, че това е било недалновидно от тяхна страна - но нека си признаем: съвсем скоро така или иначе ще имаме много по-големи проблеми за решаване.