Неужели часы Linux не сработают 19 января 2038 года 3:14:08?

21

Я немного обеспокоен этим. Это называется «проблемой 2038 года». Является ли ядро ​​Linux или Ubuntu готовым обрабатывать даты после этого, начиная с 12.04?

    
задан ThePiercingPrince 24.05.2013 в 14:00
источник

4 ответа

11

Нет, это не подведет. В худшем случае, с точки зрения программиста, он будет работать, как ожидалось: он будет сброшен до даты 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 года. Это ограничивает год до 2 147 485 547 (2 147 483 647 + 1900). Хотя это решает проблему для выполнения программ, это не решает проблему сохранения значений даты в двоичных файлах данных, многие из которых используют жесткие форматы хранения. Он также не решает проблему для 32-разрядных программ, работающих под уровнями совместимости, и может не решить проблему для программ, которые неправильно сохраняют значения времени в переменных типов, отличных от time_t .

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

Поэтому не стоит беспокоиться об этой проблеме.

Подробнее о:

ответ дан Radu Rădeanu 24.05.2013 в 14:45
источник
6

Вы можете проверить, не сработает ли время вашего компьютера, используя следующий скрипт 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 26.06.2013 в 01:13
3

Я написал и опубликовал короткую статью об этом еще в 1996 году. Это включало короткую программу на C, чтобы продемонстрировать ее. У меня также были электронные письма с Дэвидом Миллсом о подобных проблемах с NTP - Сетевым протоколом времени. На моем 64-битном ноутбуке Ubuntu 14.04 код perl не обнаружил ограничения, поэтому необходимо было изменить базовые 64-разрядные библиотеки.

Тем не менее, запуск моего давнего тестового кода показывает, что время возвращается к эпохе UNIX. Так что не все хорошо с 32-битным кодом из прошлого.

Мой документ 1996 года, Время UNIX закончится в 2038 году! был на моем сайте начиная с 2000 года. Вариант этого под названием «UNIX Time» был опубликован в 1998 году в «2000 году наилучшей практики для компьютеров тысячелетия 2000» ISBN 0136465064.

    
ответ дан oldunixguy 21.02.2017 в 00:10
2

64-разрядная версия Linux готова.

Ситуация для 32-разрядного Linux (и уровня совместимости для 32-разрядных двоичных файлов на 64-разрядной Linux) гораздо менее розовая. Он сломан и исправление его, не нарушая все существующие двоичные файлы, - непростая задача. Даже если есть некоторый уровень обратной совместимости, все двоичные файлы, которые хотят получить правильное время, должны быть перестроены для использования новых 64-битных интерфейсов времени.

Проделана определенная работа (см., например, Ссылка и Ссылка ), но afaict мы все еще далеки от полного решения. Неясно, будут ли когда-либо быть 32-разрядные дистрибутивы общего назначения, которые безопасны для Y2K38.     

ответ дан Peter Green 27.04.2016 в 02:09