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

Яка ймовірність того, що випуск 2038 року буде дуже проблематичним?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#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 року стане «непоміченим», тоді як я очікую проблем на «належних» платформах (тобто на тих, у кого велика кількість власного програмного забезпечення), особливо якщо частина критичної частини не буде підтримуватися.

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

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

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

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

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