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

Вы можете попробовать установить mdbtools и mdbtools-gmdb, чтобы получить mdb viewer для gnome.

Я не использовал его сам, поэтому я не знаю, сможет ли он отредактировать базу данных, но он дает вам возможность экспортировать его, поэтому, возможно, вы можете преобразовать его в о-базовую версию (odb).

Я не знаю, почему openoffice его не поддерживает. Я читал, что это вызвано MSDAO, которое невозможно установить в linux o / s, так что только оо-база в окнах может его поддерживать.

В любом случае, вы должны попробовать, я думаю. Надеюсь, это немного поможет.

1
задан 26 June 2013 в 04:16

3 ответа

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

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
6
ответ дан 24 May 2018 в 21:50
  • 1
    Я думаю, что вы тестируете Perl здесь, а не настоящую операционную систему в ядре. Или вы, используя ctime? – gertvdijk 26 June 2013 в 04:14
  • 2
    @gertvdijk Ну, он дает первый выход на исправленных компьютерах, а мой ноутбук Ubuntu дает второй, а третий - с моего сервера Debian. Я на самом деле не писал код, он по всему Интернету в той же точной форме. – SkylarMT 26 June 2013 в 04:17
  • 3
    подтверждено. если у вас 64-битная машина, то это будет нормально. Кроме того ... кто из нас будет иметь 32-битные машины, которые все еще работают в 2038 году? – jrg♦ 27 June 2013 в 05:57
  • 4
    Я пошел искать это, чтобы проиллюстрировать проблему 2038 сотруднику, и через 2 года после составления вышеуказанного комментария у меня есть очень мало сомнений в том, что в 2038 году у нас будут 32-битные машины, которые потерпят неудачу. Ах, юношеский оптимизм. – jrg♦ 5 August 2015 в 16:14
  • 5
    @James, может быть, некоторые невольно. Вероятно, в нем будут встроены 32-битные Linux-устройства на устройствах IoT, которые не будут переданы. Конец мира? Некоторые проблемы в некоторых местах? Определенно. – Prof. Falken 22 March 2017 в 16:42

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

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

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

3
ответ дан 24 May 2018 в 21:50

64-разрядная версия Linux готова, по крайней мере, если вы говорите об основных интерфейсах ОС (отдельные приложения могут, конечно, все-таки испортить ее). time_t традиционно определяется как псевдоним для «длинного» и «длинного» в 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), но afaict мы все еще далеки от полного решения. Неясно, будут ли когда-либо быть 32-разрядные дистрибутивы общего назначения, которые безопасны для Y2K38.

2
ответ дан 24 May 2018 в 21:50

Другие вопросы по тегам:

Похожие вопросы: