# Why does Unix store timestamps in a signed integer?

Why is a signed integer used to represent timestamps? There is a clearly defined start at 1970 that's represented as 0, so why would we need numbers before that? Are negative timestamps used anywhere?

-
That's why Nostradamus couldn't use his computer to write his predictions for the years 3000+... it would cause an overflow and show his dates as negative. I think they called it the Y3K bug or something! –  Jeach Dec 1 '11 at 18:48
The ancient Romans had an even worse problem when year numbers switched from negative to positive. They would have called it the Y0K problem if they'd had a way to express the number zero. 8-)} –  Keith Thompson Jan 22 '12 at 23:06

Early versions of C didn't have unsigned integers. (Some programmers used pointers when they needed unsigned arithmetic.) I don't know which came first, the time() function or unsigned types, but I suspect the representation was established before unsigned types were universally available. And 2038 was far enough in the future that it probably wasn't worth worrying about. I doubt that many people thought Unix would still exist by then.

Another advantage of a signed time_t is that extending it to 64 bits (which is already happening on some systems) lets you represent times several hundred billion years into the future without losing the ability to represent times before 1970. (That's why I oppose switching to a 32-bit unsigned time_t; we have enough time to transition to 64 bits.)

-
The time function is older than the epoch: Unix v1 (in 1971) counted in units of 1/60th of a second, from midnight on 1971/01/01. It was already a known bug that “The chronological--minded user will note that 2**32 sixtieths of asecond is only about 2.5 years.” unsigned was introduced by K&R in 1978, well after the 1970 epoch was established. –  Gilles Nov 26 '11 at 0:37
I did a quick test and on my 64-bit linux box. gmtime and localtime max out in the year 2147483647 (with the next second after giving -2147483648 as the year). So to get much past 55 bits of time somebody will have to update the output routine to use a 64-bit int for the year instead of an unsigned 32-bit int. Hopefully somebody will take care of that bug sometime in the next couple billion years. –  freiheit Dec 2 '11 at 19:11
@freiheit: Interesting. The problem there is that the struct tm type has a member tm_year (representing years since 1900) which is of type int. 64-bit systems can easily have a 64-bit time_t, but they typically have a 32-bit int. (If char is 8 bits and int is 64 bits, then short can be either 16 or 32 bits, and there will be no predefined type for the other size.) But time() is probably the only function in <time.h> that really requires system-level support; you can write your own code to convert time_t values to human-readable strings. –  Keith Thompson Dec 2 '11 at 20:18

It's to support timestamps and dates before January 1st, 1970.

-
This makes only 68 years in the past - 1902. This seems quite a little. –  Bakudan Nov 25 '11 at 20:43
POSIX doesn't require time_t to be only 32 bits; it's already 64 bits on many systems. –  Keith Thompson Nov 25 '11 at 20:47