Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have date (GNU coreutils) 7.1 installed on my system.

If I try to check dates prior to 14-Dec-1901, I get an "invalid date" error. For example,

  $ date -d 1901-12-13
  date: invalid date `1901-12-13'

  $ date -d 1901-12-14
  Sat Dec 14 00:00:00 EST 1901

What should I do to make the date utility to treat years prior to 1901 as valid?

I receive similar errors for dates after 19-Jan-2038

share|improve this question
I receive no error. I'm using coreutils 8.10, maybe an old bug? – xenoterracide Feb 20 '11 at 0:39
@xenoterracide are you an a 64-bit system? – Mikel Feb 20 '11 at 0:47
@Mikel yes, I am – xenoterracide Feb 20 '11 at 4:01
up vote 15 down vote accepted

Good question.

The documentation says it should be allowed.

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

For numeric months, the ISO 8601 format `YEAR-MONTH-DAY' is allowed, where YEAR is any positive number, ...

A leading zero must be present if a number is less than ten.

If YEAR is 68 or smaller, then 2000 is added to it; otherwise, if YEAR is less than 100, then 1900 is added to it.

Are you on a 32-bit system?

Do you get an error with dates after 2038-01-20 as well, e.g.

date -d '2038-01-20'

If so, it sounds like GNU date is using a 32-bit time value.

I'm not sure how you can fix this other than using a 64-bit system or using a different tool, for example DateTime in Perl or datetime in Python.

Some background:

Unix times count the number of seconds from January 1 1970 using an integer value. If the system uses 32-bit integers, it can only count 2.1 billion seconds forward (up to 2038-01-19 03:14:02 UTC) and 2.1 billion seconds backwards (back to 1901-12-13 20:45:52 UTC).

More information at:

share|improve this answer
Thanks Mikel, i believe so that i'm on a 32 bit machine. Actually, i'm working a remote server and the server wont reveal much information even with uname command except the fact that it says its an i686 machine, which i assume are 32 bit machines. As for the 2038 problem, yes, that problem is there infact in the remote server. Thanks again for your input! Much appreciated!! – Jasdeep Singh Feb 20 '11 at 6:25
Yes, i686 is 32-bit. Glad to help. If you need help dealing with dates older than that, try the Python and Perl modules I suggested, and post another question if you can't get it working. – Mikel Feb 20 '11 at 6:31

Your system (or at least that version of date) is probably using a 32-bit internal time value.

The Unix epoch (zero time value) is 1970-01-01 00:00:00 UTC. This starting point puts 1901-12-13 00:00 EST just outside the range of a signed 32-bit time value.

1901-12-14 00:00:00 EST is -2147454000
1901-12-13 15:45:52 EST is -2147483648 (aka INT_MIN in C, the minimum 32-bit signed integer)
1901-12-13 00:00:00 EST is -2147540400

You could try using 1901-12-13 15:45:52 EST. It should work, but one second earlier will probably fail in the same way as 1901-12-13 00:00.

share|improve this answer
Thanks Chris!! i guess the machine is 32 bit indeed. :) – Jasdeep Singh Feb 20 '11 at 6:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.