Чи вийде з ладу годинник Linux 19 січня 2038 р. 3:14:08?

23

Я трохи стурбований цим. Це називається "проблема 2038 року". Чи готові ядро Linux або Ubuntu після обробки даних після 12.04?

time

— ThePiercingPrince
джерело

8

Ви спробували встановити годинник на щось на зразок 19 січня 2038 р. 3:14:07 і зачекати секунду?

— gertvdijk

2

Припустимо, що ця проблема існує і ще не виправлена. 12.04 не буде підтримуватися вічно, тож ви та всі інші люди будете оновлюватися, поки це не відбудеться, оскільки між ними багато років. Оновлення легко. Одне з цих оновлень обов’язково містить виправлення. Тож немає причин для занепокоєння, але це справді цікаве питання.

— verpfeilt

3

Помилка вже виправлена.

— ThePiercingPrince

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

— Пісквор

1

@hmayag: Я не думав "тостер", більше схожий на "контролер світлофора". Ці речі трохи більш міцні , ніж споживчий клас електроніка, і можуть легко перевищити цей термін (з частиною заміни, але , можливо , без апгрейдів) - IIRC, там були деякі проблеми з такими 1980s електронікою тільки після Y2K.

— Пісквор

13

Ні, це не вийде. У гіршому випадку, з точки зору програміста, він буде працювати так, як очікувалося: він буде перероблений на дату 1901-12-13 20:45:52:

введіть тут опис зображення

Це на випадок, якщо ви не будете оновлювати свої поточні дистрибутиви, поки цього не станеться. " Оновлення просте. Одне з цих оновлень обов'язково містить виправлення ", як сказав chocobai .

Я пам’ятаю, що це була та сама проблема / питання з 16-бітними машинами до 2000 року, і врешті-решт це не було ніяких проблем.

Рішення з Вікіпедії:

Більшість операційних систем, призначених для роботи на 64-розрядному апаратному забезпеченні, вже використовують підписані 64-бітні time_tцілі числа. Використання підписаного 64-бітного значення вводить нову дату обгортання, яка в понад двадцять разів перевищує орієнтовний вік Всесвіту: приблизно 292 мільярди років з цього часу, о 15:30:08 в неділю, 4 грудня, 292,277,026,596. Можливість робити обчислення за датами обмежена тим, щоtm_yearвикористовує підписане 32-бітове значення int, починаючи з 1900 року. Це обмежує рік до максимуму 2147,485,547 (2,147,483,647 + 1900). Хоча це вирішує проблему для виконання програм, це не вирішує проблему збереження значень дат у бінарних файлах даних, багато з яких використовують жорсткі формати зберігання. Він також не вирішує проблему для 32-бітних програм, що працюють під шарами сумісності, і не може вирішити проблему для програм, які неправильно зберігають значення часу у змінних інших типів time_t.

Я використовую Ubuntu 13.04 на 64-розрядному і, з цікавості, змінив час вручну на 2038-01-19 03:13:00. Після 03:14:08 нічого не сталося:

Дата та час до 2038-01-19 03:14:08 Дата та час після 2038-01-19 03:14:08

Тож немає чого турбувати цю проблему.

Більше про:

— Раду Радеану
джерело

9

Якщо вона скидається, вона не працює, тому що під "провалом" я маю на увазі "не працювати або працювати неправильно".

— ThePiercingPrince

1

@LinuxDistance Це відбувається з вашого погляду. Але з точки зору програміста він буде працювати так, як очікувалося: він скинеться . Те саме було з кінцем календаря майя: через це світ не провалився.

— Radu Rădeanu

10

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

— Нанна,

3

Це обговорення в коментарях є безглуздим. Питання "Чи готові ядро Linux або Ubuntu обробляти дати після цього?". Що ж, він не здатний обробляти такі дати, тому не вдається в контексті цього питання.

— gertvdijk

2

@gertvdijk "Чи готовий " поточний / фактичний "ядро Linux або Ubuntu для обробки дат після цього?"

— Radu Rădeanu

7

Ви можете перевірити, чи закінчиться час вашого комп'ютера, скориставшись наступним сценарієм Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Якщо ваш комп’ютер буде добре, ви отримаєте це:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Якщо ваш комп’ютер такий, як мій, він обернеться так:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Це також може зробити це:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

— SkylarMT
джерело

Я думаю, ви тестуєте Perl тут, а не реальну операційну систему в основі. Або ти з використанням ctime?

— gertvdijk

@gertvdijk Ну, це дає перший вихід на виправлених комп'ютерах, а мій ноутбук Ubuntu дає другий, а третій - з мого сервера Debian. Я насправді не написав код, він у всьому Інтернеті в тій же точній формі.

— SkylarMT

2

підтверджено. якщо у вас 64-бітна машина, то це буде добре. Окрім того, хто з нас матиме 32-бітні машини лише у 2038 році?

— jrg

1

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

— jrg

@James, можливо, мимоволі. Напевно, буде вбудований 32-розрядний Linux в IoT-пристрої тоді, без патч. Кінець світу? Ні. Деякі проблеми в деяких місцях? Безумовно.

— Проф. Фолкен підтримує Моніку

3

Я написав і опублікував короткий документ про це ще в 1996 році. Це включало коротку програму C, щоб продемонструвати це. У мене також було повідомлення з Девідом Міллсом про подібні проблеми з NTP - Network Time Protocol. На моєму 64-розрядному ноутбуці Ubuntu 14.04 код perl не мав обмежень, тому основні 64-розрядні версії повинні бути змінені.

Однак запуск мого давнього тестового коду показує повернення часу до UNIX Epoch. Тож не все добре з 32-розрядним кодом минулого.

Мій документ 1996 року, час UNIX закінчиться в 2038 році! на моєму веб-сайті близько 2000 року. Варіант цього під назвою "Час UNIX" був опублікований у 1998 р. у "2000 найкращих практиках для обчислень тисячоліття Y2K" ISBN 0136465064.

— oldunixguy
джерело

2

64-розрядний Linux готовий, принаймні, якщо ви говорите про основні інтерфейси ОС (окремі програми, звичайно, все-таки можуть його викрутити). time_t традиційно визначається як псевдонім для "long" і "long" на 64-розрядному Linux є 64-розрядним.

Ситуація для 32-бітного Linux (і рівня сумісності для 32-бітових бінарних файлів на 64-розрядному Linux) набагато менш яскрава. Це зламано, і виправити його, не порушуючи всіх існуючих бінарних файлів, непросте завдання. Ціла купа API-файлів використовує time_t, і в багатьох випадках вона вбудовується як частина структури даних, тому не тільки в API повинні дублюватися структури даних, з якими вони працюють.

Навіть якщо існує певний рівень зворотної сумісності, всі бінарні файли, які хочуть отримати правильний час, потрібно буде перебудувати для використання нових 64-бітних інтерфейсів часу.

Було виконано певну роботу (див., Наприклад, https://lwn.net/Articles/643234/ та http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ), але ми маємо на увазі все ще довгий шлях від повного рішення. Незрозуміло, чи будуть коли-небудь 32-бітові дистрибутиви загального призначення, які є безпечними для Y2K38.

— Пітер Грін
джерело