Проблема року 2038 [закрито]


Відповіді:


17

Я зіткнувся з цією проблемою у вбудованій системі Linux, яка потребувала обробки дат минулого 2038 року в деяких довгострокових криптографічних сертифікатах, тому я б сказав, що ймовірність цього залежить від домену вашого додатка.

Хоча більшість систем має бути готовою задовго до 2038 року, якщо ви сьогодні знайдете підрахунок дат в далекому майбутньому, у вас можуть виникнути проблеми.


Хороший! Я не думав про той приклад! Що використовує стандарт PKI як синтаксис часу всередині сертифікатів? Я ніколи не дивився!
geoffc

@geoffc, насправді це був фірмовий формат і мав свою внутрішню структуру дати / часу, які самі були достатньо великими, щоб відповідати датам минулого 2038 року, але він використовував функції GLIBC для перетворення дати / часу. Якщо я пригадую правильно, mktimeдзвінок мовчки провалився.
Алекс Б

13

Я думаю, що це буде суттєвою проблемою, набагато згубнішою, ніж проблеми Y2K 1999/2000, тому що код, що стосується, як правило, нижчого рівня (це CTIME), і тому важче визначити місця, де таким чином зберігається час.

Щоб ще більше ускладнити справи, той факт, що Y2K сприймався як вологий скраб, ускладнить привернення уваги до проблеми під час події.

Культурна література:

Cory Doctorow випробовував нову модель для оприлюднення / публікації коротких оповідань за відкритими ліцензіями, і я запропонував тему 2038 року про одну з них, яку він блискуче зробив у Епоху: http://craphound.com/?p=2337


Виступаючи як хтось, хто працював над цим питанням у той час, Y2K зітхнув через багато роботи та планування заздалегідь. Сприйняття вологих кальмарів підкріплювалося всіма перебільшеними приреченнями в ЗМІ. Я очікую, що буде багато планування та роботи, зробленої починаючи з 2035 року, але якщо нам пощастить, ми пропустимо медіа-блиск.
Девід Торнлі

Привіт за посилання Марк.
boehj

9

Кілька років тому вже з’являлися повідомлення про проблеми в таких областях, як іпотечні програми, які проводять розрахунки за 30-річними кредитами: 2008 + 30 = 2038.


8

64-розрядна ОС в кінцевому рахунку не має значення для проблеми 2037 року. (CTIME закінчується ближче до 2037 року, ніж до 2038 року).

Питання полягає не в бітовій глибині ОС, а в тому, як ОС зберігає час. Або як стовпець бази даних вирішує зберігати час. Або як цей каталог служби атрибутів синтаксису часу зберігає час на зворотному кінці.

Це набагато більша проблема, ніж люди думають, оскільки настільки ендемічна і звичайна, що використовували 32-бітові лічильники часу.

Кожен екземпляр, який зберігає час, повинен бути переглянути, а також оновити всі API та оновити всі інструменти, які використовують його.

Шари абстракції, які дозволяють вам встановити час за допомогою читаного для людини формату часу, замість виписаних необроблених даних полегшують, але це лише один випадок.

Я підозрюю, що це буде набагато більшою угодою, ніж думає більшість людей.


1
Найбільша проблема, яку я бачу, - це формати файлів і розширення файлів, проте діапазон дат для ext4 - 2514, vfat - 2107. Проблема - з reiserfs (2038).
Maciej Piechotka

У ReiserFS є й інші проблеми. Я все ще думаю, що є багато інших прихованих місць, ніж люди думають, що цей час зберігається в CTIME. Це чортовий простий та корисний формат часу. Звичайно, у неподписаного CTIME немає проблеми 2037 року. Я думаю, що це випадок 2107.
geoffc

1
Ви думаєте про Apple HFS. FAT взагалі не використовується time_t. Він зберігає рік, місяць і день як поля в одному 16-бітному значенні: 5 біт на день, 4 на місяць, залишаючи 7 на рік. 2107 - 1980 (нуль року в землі FAT) + 2 ^ 7-1. Для більшої розваги FAT зберігає час дня так само в іншому 16-бітному значенні, але якщо ви займаєтеся математикою, то виявите, що вам потрібно 17 біт, щоб зберігати час доби таким чином. FAT долає це, скидаючи один біт роздільної здатності на секунди; FAT не в змозі розрізнити зміни менше 2 секунд. Ах, Microsoft, який би це нудний світ без ваших непотрібних несумісностей!
Warren Young

8

Це моя думка, але ця проблема пов'язана з 32-бітною лічильниковою проблемою, сьогодні більшість ОС оновлюються для обробки часу на 64 бітах (принаймні на 64-бітних комп'ютерах), тому я думаю, що всі ОС та програмне забезпечення будуть готові довго час до 2038 року, скажімо до 2020 року. Отже, у вас можуть виникнути проблеми лише в тому випадку, якщо в 2038 році ви все ще будете працювати з програмним забезпеченням з 2020 року.
Це, мабуть, не буде проблемою майже у всіх випадках. Я сподіваюсь.


Я спробував 32-бітну версію Ubuntu, і вона показала 2038 проблем, але запуск 64-бітної версії Ubuntu не показав жодної ознаки проблеми 2038 року. Я не пробував жодних інших Unixes.
Джиммі Гедман

Так, у більшості 32-розрядної версії ви побачите проблему, але не на 64-бітній версії. Ви можете сподіватися, що у 2038 році вже не буде 32-бітної ОС
радіус

2
Це смішне припущення. Ми все ще використовуємо 16 (і навіть 8 бітові) мікропроцесори в сучасному світі, що сказати, 32-бітні мікропроцесори магічно зникнуть у майбутньому? Можна сказати, що це не вплине на середнього користувача, але в крайніх випадках це може продовжувати бути проблемою.
Елі Фрей

Добре - 16-розрядні та 8-бітні комп'ютери можуть 1. перенести дату 0 (з 1970-01-01 до, наприклад, 2010-01-01) - однак це порушить певні умови API / ABI 2. розширить поле таймера ( який може у певних випадках порушити "лише" ABI).
Maciej Piechotka

1

Не така вже й велика справа.

Під час першого блиску Y2K, коли постачальники програмного та апаратного забезпечення вимагали сертифікації своєї продукції як "сумісної Y2K", щоб продати (пам'ятаю, мережеві кабелі на ПК підключення сертифіковані на сумісність з Y2K) багато компаній зробили детальний аудит всього , встановивши годинники в майбутньому і тестуючи.

У той час, оскільки вартість тестування була такою високою, вони майже завжди тестувались з кількома датами, наприклад, 1/1/99 (деякі розробники, можливо, використовували 99 як дозорний), 12/31/99, 1/1 / 00, стрибок 2000, 1/19/38 та багато інших. Ознайомтеся з тут нудним списком.

Таким чином, я вважаю, що будь-яке важливе програмне забезпечення, яке було в 1999 році, напевно, не матиме 2038 помилок, але нове програмне забезпечення, написане з тих пір неосвіченими програмістами, може. Зрештою, цілий дебакл Y2K програмісти, як правило, набагато більше усвідомлювали проблеми кодування дати, тому навряд чи це буде настільки сильним впливом, як Y2K (що саме по собі було чимось антиклімаксом).


За винятком того, що ця проблема викликана тим, що тип UNIX time_t є 32-розрядним.
Юйонг Бао

1

32-бітні системи, які до цього часу працюють, будуть проблемою.


2
Чи можете ви детальніше розглянути це, щоб зрозуміти, що саме стає проблемою, і як на це реагувати?
Антон

Проблема пов'язана з 32-бітовим цілим числом, яке використовується для обчислення часу. Час вимірюється в кількості секунд, що минули з 01 січня 1970 року. Наприклад, через один день цей лічильник буде 86400. Отже, у 2038 році це значення буде переповнене, оскільки воно буде містити значення, яке перевищує число, яке може утримуватися в 32-бітове ціле число без знака. 64-бітова система, що використовує 64 біт для часової позначки, не матиме цієї проблеми, оскільки вона зможе працювати до 15:30:08 в неділю, 4 грудня, 292,277,026,596 (292 мільярди років)
Рахул Кадукар

0
#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

він повинен бути 1 замість 9, але ctime не обробляє більшу дату:

8 - Sun Jun 13 07:26:08 1141709097

Час моєї системи (звичайно, 64 біт) може працювати навіть на 1 мільйон років. Рішення полягає в тому, щоб оновити системи до 64 біт.

Проблема в тому, що програми можуть не впоратися з цим. Особливо старі, належні та не доглянуті. Devs використовується для наступних фактів:

  • int- це 32 біти (насправді вони зберігаються як 32 біти в 64-бітних системах серед інших, оскільки передбачалося, що вони 32-бітні завжди)
  • Більшість типів (таких як time_t) можна сміливо касуватиint

У популярному програмному забезпеченні FLOSS обидві речі, ймовірно, не потраплять через огляд "багатьох очей". Від менш популярних та власних речей це буде значно залежати від автора.

Я думаю, що у вільному * nix світі 2038 року стане «непоміченим», тоді як я очікую проблем на «належних» платформах (тобто на тих, у кого велика кількість власного програмного забезпечення), особливо якщо частина критичної частини не буде підтримуватися.


Це не «система» чи «ОС». Більшість будь-яких попередніх 32-бітних ОС (чорт, навіть 16-бітна ОС) могли робити 64-бітну математику. 64-бітова глибина на рівні ОС в основному є посиланням на модель пам'яті, а не здатність робити математику. І час - це все про математику.
geoffc

Так і ні. Це правда, що 32-бітова і 64-бітна ОС можуть виконувати 64-бітну арифметику (ви можете імітувати будь-яку арифметику). Однак time_t(або еквівалент) у 32-бітовій ОС має 32 біти, в той час як time_t(або еквівалент) у 64-бітній ОС має 64 біта. Я вважав це досить зрозумілим, навіть якщо з певним спрощенням.
Мацей П'єхотка

0

Якщо це щось на зразок Y2K, деякі люди вже постраждали і змінюють програмне забезпечення, але більшість розробників буде ігнорувати це до десь у 2030-х, напевно, 2035-го чи приблизно так, в цей момент буде зроблено багато роботи, і хто-небудь достатньо старший щоб знати K&R C і ще не дуже старенький, раптом вдасться укласти контракт за багато грошей. Фактичний перехід покаже багато ще не зробленого, мабуть, нічого важливого.


-5

Проблемою Y2K були два статути, що представляли рік замість чотирьох.

Багато систем не мали змоги відрізнити 2000 рік від 1900 року, оскільки вони зберігали лише "00".

Практично всі системи або використовують 4 символи для зберігання року, або використовують якусь бібліотеку.

Тож давайте всім турбуватися про рік 10000 (Y10K). За винятком авторів ОС та Бібліотеки ...


Напевно, ніхто (ну і практично ніхто) не зберігає дату такого формату (тобто DCD або рядок) зараз. Час, як правило, обробляється об'єктами чи вкладками (тому потрібно лише оновлювати код відображення).
Maciej Piechotka

Так, точно моя думка. Y2K ефективно знищила ідею представляти дати як рядки з фіксованою довжиною.
Stephen Jazdzewski

@Stephen: Не у світі COBOL, але на щастя є мало реалізацій COBOL на Unix / Linux.
Девід Торнлі

@David: Програми COBOL здебільшого були проблемою Y2K. Чи мали системи Linux / Unix, з точки зору користувачів, проблеми з Y2K? Проста відповідь на початкове запитання - ні.
Stephen Jazdzewski

4
Плакат не запитує про проблему y2k; вони запитують про проблему y2k38, яка є зовсім іншим звіром. Перевірте en.wikipedia.org/wiki/Y2K38 на опис.
Кевін М
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.