Будут ли работать часы Linux 19 января 2038 3:14:08?
Я немного обеспокоен этим. Это называется «проблема 2038 года». Готово ли ядро Linux или Ubuntu обрабатывать даты после этого, начиная с 12.04?
4 ответа
Я помню, что это была та же проблема / вопрос с 16-битными машинами до 2000 года, и в конце концов это не было проблемой.
Решение из Википедии:
Большинство операционных систем, предназначенных для работы на 64-битном оборудовании, уже используют 64-битные целые числа со знаком
time_t. Использование 64-разрядного значения со знаком вводит новую дату переноса, которая более чем в двадцать раз превышает предполагаемый возраст вселенной: примерно через 292 миллиарда лет, в 15:30:08 в воскресенье, 4 декабря, 292 277 026 596. Возможность выполнения вычислений по датам ограничена тем фактом, чтоtm_yearиспользует 32-битное значение со знаком, начиная с 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 ничего не произошло:
Так что беспокоиться об этой проблеме нечего.
Подробнее о:
Я написал и опубликовал небольшую статью по этому вопросу еще в 1996 году. Это включало короткую программу на С, чтобы продемонстрировать это. У меня также были электронные письма с Дэвидом Миллсом о подобных проблемах с NTP-протоколом сетевого времени. На моем 64-битном ноутбуке Ubuntu 14.04 код perl не имел ограничений, поэтому базовые 64-битные библиотеки должны были быть изменены.
Тем не менее, выполнение моего давнего тестового кода показывает, что время возвращается к эпохе UNIX. Так что не все хорошо с 32-битным кодом из прошлого.
Моя статья 1996 года, Время UNIX закончится в 2038 году! было на моем сайте примерно с 2000 года. Вариант под названием «Время UNIX» был опубликован в 1998 году. в "Лучшем опыте 2000 года в области компьютерных технологий 2000 года", ISBN 0136465064.
Вы можете проверить, будет ли сбой вашего компьютера, используя следующий сценарий 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
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.