Why do timestamps have a limit to 2038?

I just found out, running a calendar script, that timestamps in PHP has a limit to 2038. What does it really mean? Why is it 2038 instead of 2050 or 2039? Why a limit if tim开发者_如何学编程estamps just count seconds from a given date (1970)?

The limit is imposed by the 4 byte signed integers that most C libraries use for representing that count. Quick math (assumes 365 day years, not exactly correct):

2147483648 seconds ~ 68.1 years

This also implies a lower limit of ~1900. Some libraries have started to introduce 64 bit epoch counts, but they are few and far between for the moment.

The maximum value of a signed 32-bit integer is 2,147,483,647. If you add +1 to that, you get -2,147,483,647. 2,147,483,647 seconds from 01-01-1970 00:00:00 is January 19, 2038. If you add one more second, you get a date somewhere in 1902.

due to the limit of INT datatype on 32 bit machine

http://php.net/manual/en/function.mktime.php

From php.net : "The maximum possible date accepted by mktime() and gmmktime() is dependent on the current location time zone.

For example, the 32-bit timestamp overflow occurs at 2038-01-19T03:14:08+0000Z. But if you're in a UTC -0500 time zone (such as EST in North America), the maximum accepted time before overflow (for older PHP versions on Windows) is 2038-01-18T22:14:07-0500Z, regardless of whether you're passing it to mktime() or gmmktime()."

my guess is that it is stored in a fixed number of bits, which means a limit on how big the timestamp can get. We could do some math to figure it out exactly.