Хороший вопрос.
В документации говорится, что она должна быть позволена.
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).
Больше информации в:
Ваша система (или по крайней мере что версия даты), вероятно, использует 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.
uname
команда кроме того, что это говорит i686 машина, которую я принимаю, является машинами на 32 бита. Что касается проблемы 2038 года, да, та проблема, там заражают в удаленном сервере. Еще раз спасибо за Ваш вход! Очень ценивший!! – Jasdeep Singh 20.02.2011, 08:25