дата - годы до 1901 рассматривают как недопустимые

  • Linux имеет широкую поддержку большого количества различных аппаратных архитектур и платформ от крошечных встроенных плат до значительных вычислительных массивов. В то время как другие хорошие ядра доступны, покрытие и качество драйверов оборудования, доступных для Linux далеко, превосходят любую другую платформу.
  • Источник ядра Linux открыт и может легко быть изменен для работы различных пользовательских платформ. Для любого поставщика, создающего новую часть аппаратных средств, обеспечение драйверов Linux является одним из самых легких способов сделать это доступным. Они не должны работать с нуля, потому что они могут изменить существующие драйверы для подобных частей аппаратных средств и основываться на их успехе.
  • Некоторые из других кандидатов ОС мучают лицензионные сборы на ЦП. Они становятся препятствующими на суперкомпьютерном уровне.
  • Так как Linux использовался всеми в этом пространстве прежде, это имеет лучшую поддержку и самый широкий выбор доступных пакетов программного обеспечения и библиотек.
11
26.04.2011, 01:46
2 ответа

Хороший вопрос.

В документации говорится, что она должна быть позволена.

 info date 'Date input formats' 'Calendar date items'

В течение числовых месяцев позволяется формат ISO 8601 'ДЕНЬ МЕСЯЦА ГОДА', где ГОД является любым положительным числом...

Начальный нуль должен присутствовать, если число - меньше чем десять.

Если ГОД равняется 68 или меньший, то 2000 добавляется к нему; иначе, если ГОД - меньше чем 100, то 1900 добавляется к нему.

Вы находитесь в 32-разрядной системе?

Вы получаете ошибку с датами после 20.01.2038 также, например.

date -d '2038-01-20'

Если так, это кажется, что дата GNU использует 32-разрядную временную стоимость.

Я не уверен, как можно зафиксировать это кроме использования 64-разрядной системы или использования другого инструмента, например, DateTime в Perl или дата и время в Python.

Некоторый фон:

Времена Unix считают число секунд с 1 января 1970 с помощью целочисленного значения. Если система использует 32-разрядные целые числа, она может только считать 2,1 миллиарда секунд вперед (до 19.01.2038 3:14:02 UTC) и 2,1 миллиарда секунд назад (назад к 13.12.1901 20:45:52 UTC).

Больше информации в:

15
27.01.2020, 19:57
  • 1
    Спасибо Mikel, я верю так, чтобы я был на машине на 32 бита. На самом деле я работаю, удаленный сервер и привычка сервера показывают много информации даже с uname команда кроме того, что это говорит i686 машина, которую я принимаю, является машинами на 32 бита. Что касается проблемы 2038 года, да, та проблема, там заражают в удаленном сервере. Еще раз спасибо за Ваш вход! Очень ценивший!! –  Jasdeep Singh 20.02.2011, 08:25
  • 2
    Да, i686 является 32-разрядным. Довольный помочь. Если Вы нуждаетесь в помощи, имея дело с датами, более старыми, чем это, попробуйте Python и модули Perl, которые я предложил, и отправьте другой вопрос, если Вы не можете получить его работа. –  Mikel 20.02.2011, 08:31

Ваша система (или по крайней мере что версия даты), вероятно, использует 32-разрядную внутреннюю временную стоимость.

Эпоха Unix (нулевая временная стоимость) 01.01.1970 0:00:00 UTC. Эта начальная точка помещает 13.12.1901 0:00 EST недалеко от диапазона 32-разрядной временной стоимости со знаком.

14.12.1901 0:00:00 EST-2147454000
13.12.1901 15:45:52 EST-2147483648 (иначе INT_MIN в C, минимальном 32-разрядном целом числе со знаком)
13.12.1901 0:00:00 EST-2147540400

Вы могли попытаться использовать 13.12.1901 15:45:52 EST. Это должно работать, но одной секундой ранее, вероятно, перестанет работать таким же образом как 13.12.1901 0:00.

7
27.01.2020, 19:57

Теги

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