Вы пытались установить часы на что-то вроде 19 января 2038 3:14:07 и подождать секунду?
gertvdijk
2
Давайте предположим, что эта проблема существует и еще не устранена. 12.04 не будет поддерживаться вечно, поэтому вы и все остальные люди будете в обновленном дистрибутиве, пока это не произойдет, поскольку между ними много лет. Обновление легко. Одно из этих обновлений наверняка будет содержать исправление. Так что нет причин для беспокойства, но это действительно интересный вопрос.
verpfeilt
3
Ошибка была уже исправлена.
ThePiercingPrince
Системные часы не работают (во всяком случае, не на достаточно свежем ядре); некоторые структуры данных (и программы, использующие их) могут демонстрировать аномальное поведение. На мой взгляд, это будет проблемой для встраиваемых устройств - они гораздо реже используют текущий код.
Писквор
1
@hmayag: я не думал «тостер», больше как «диспетчер светофора». Эти вещи немного более прочные , чем потребительский класс электроника, и могут легко превысить этот срок (с частью замены, но , возможно , без апгрейдов) - IIRC, там были некоторые проблемы с такими 1980s электроникой только после Y2K.
Писквор
Ответы:
13
Нет, это не подведет. В худшем случае, с точки зрения программиста, он будет работать как положено: он будет сброшен до даты 1901-12-13 20:45:52:
Это в случае, если вы не будете обновлять ваши текущие дистрибутивы, пока это не произойдет. « Обновление легко. Одно из этих обновлений наверняка будет содержать исправление », - сказал Чокобай .
Я помню, что это была та же проблема / вопрос с 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 ничего не произошло
Если он сбрасывается, он терпит неудачу, потому что под «неудачей» я имею в виду «не работает или работает неправильно».
ThePiercingPrince
1
@LinuxDistance Это происходит с вашей точки зрения. Но с точки зрения программиста он будет работать как положено: он будет сброшен . То же было и с окончанием календаря майя: мир не рухнул из-за этого.
Раду Рэдяну
10
Я не согласен? с точки зрения программиста часы не должны сбрасываться, поэтому они выйдут из строя
Nanne
3
Это обсуждение в комментариях бессмысленно имо. Вопрос в том, «готово ли ядро Linux или Ubuntu обрабатывать даты после этого?». Ну, он не способен обрабатывать такие даты, поэтому он терпит неудачу в контексте этого вопроса.
gertvdijk
2
@gertvdijk "Готово ли" текущее / реальное "ядро Linux или Ubuntu обрабатывать даты после этого?"
Раду Рэдяну
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
Я думаю, что вы тестируете Perl здесь, а не настоящую операционную систему в ядре. Или вы, с использованием ctime?
gertvdijk
@gertvdijk Что ж, он выдает первый вывод на пропатченных компьютерах, а мой ноутбук с Ubuntu - второй, а третий - с моего сервера Debian. На самом деле я не писал код, он есть в Интернете в одной и той же форме.
SkylarMT
2
подтверждено. если у вас есть 64-битная машина, то это будет хорошо. Кроме того ... у кого из нас будут только 32-битные машины, работающие в 2038 году?
JRG
1
Я искал это, чтобы проиллюстрировать проблему 2038 года коллеге, и через 2 года после того, как я высказал вышеупомянутый комментарий, у меня очень мало сомнений в том, что в 2038 году у нас будут 32-битные машины, которые выйдут из строя. Ах, молодой оптимизм.
JRG
@ Джеймс, может быть, некоторые невольно. Вероятно, в то время в IoT-устройствах будет встроен 32-битный Linux, без исправлений. Конец света? Нет проблем в некоторых местах? Определенно.
Профессор Фалькен поддерживает Монику
3
Я написал и опубликовал небольшую статью по этому вопросу еще в 1996 году. Это включало короткую программу на Си, чтобы продемонстрировать это. У меня также были электронные письма с Дэвидом Миллсом о подобных проблемах с NTP-протоколом сетевого времени. На моем 64-битном ноутбуке Ubuntu 14.04 код perl не имел ограничений, поэтому базовые 64-битные библиотеки должны были быть изменены.
Тем не менее, выполнение моего давнего тестового кода показывает, что время возвращается к эпохе UNIX. Так что не все хорошо с 32-битным кодом из прошлого.
Моя статья 1996 года, время UNIX истечет в 2038 году! был на моем веб-сайте с 2000 года. Вариант под названием «Время UNIX» был опубликован в 1998 году в «Лучшем опыте 2000 года для компьютерных вычислений тысячелетия», ISBN 0136465064.
64-битная версия Linux готова, по крайней мере, если вы говорите об основных интерфейсах ОС (отдельные приложения, конечно, могут все испортить). time_t традиционно определяется как псевдоним «long», а «long» в 64-битной Linux - 64-битная.
Ситуация для 32-битного Linux (и уровня совместимости для 32-битных двоичных файлов в 64-битном Linux) гораздо менее радужна. Он сломан, и исправить его, не сломав все существующие двоичные файлы, не простая задача. Целый набор API использует time_t, и во многих случаях он внедряется как часть структур данных, поэтому API-интерфейсы не только должны дублироваться, но и структуры данных, с которыми они работают.
Даже если существует некоторый уровень обратной совместимости, все двоичные файлы, которые хотят получить правильное время, необходимо будет перестроить для использования новых 64-битных временных интерфейсов.
Ответы:
Нет, это не подведет. В худшем случае, с точки зрения программиста, он будет работать как положено: он будет сброшен до даты 1901-12-13 20:45:52:
Это в случае, если вы не будете обновлять ваши текущие дистрибутивы, пока это не произойдет. « Обновление легко. Одно из этих обновлений наверняка будет содержать исправление », - сказал Чокобай .
Я помню, что это была та же проблема / вопрос с 16-битными машинами до 2000 года, и в конце концов это не было никаких проблем.
Решение из Википедии:
Я использую Ubuntu 13.04 на 64-битной версии и, по любопытству, вручную изменил время на 2038-01-19 03:13:00. После 03:14:08 ничего не произошло
Так что не стоит беспокоиться об этой проблеме.
Больше о:
источник
Вы можете проверить, будет ли зависать время вашего компьютера, используя следующий скрипт Perl:
Если ваш компьютер будет в порядке, вы получите это:
Если ваш компьютер похож на мой, он будет выглядеть примерно так:
Это также может сделать это:
источник
ctime?Я написал и опубликовал небольшую статью по этому вопросу еще в 1996 году. Это включало короткую программу на Си, чтобы продемонстрировать это. У меня также были электронные письма с Дэвидом Миллсом о подобных проблемах с NTP-протоколом сетевого времени. На моем 64-битном ноутбуке Ubuntu 14.04 код perl не имел ограничений, поэтому базовые 64-битные библиотеки должны были быть изменены.
Тем не менее, выполнение моего давнего тестового кода показывает, что время возвращается к эпохе UNIX. Так что не все хорошо с 32-битным кодом из прошлого.
Моя статья 1996 года, время UNIX истечет в 2038 году! был на моем веб-сайте с 2000 года. Вариант под названием «Время UNIX» был опубликован в 1998 году в «Лучшем опыте 2000 года для компьютерных вычислений тысячелетия», ISBN 0136465064.
источник
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.
источник