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 timestamps just count seconds from a given date (1970)?
-
http://stackoverflow.com/questions/5319710/accessing-dates-in-php-beyond-2038/5319769#5319769 – Prix May 04 '11 at 05:57
-
2http://en.wikipedia.org/wiki/Y2K38 – mu is too short May 04 '11 at 06:04
-
1@muistooshort Hahaha, that was my thought exactly, as soon as I read this. **"Uh oh. *We're all going to die.*"** – Andrew Jun 10 '20 at 21:57
4 Answers
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.

- 127,823
- 52
- 194
- 222
-
Why cannot they add another int and make the sum when the limit is reached? – Shoe May 04 '11 at 06:01
-
@Charliepiga check out my updated answer. It's a work in progress, but given that it won't be an issue for a while for most people, it's slow going. – Matthew Scharley May 04 '11 at 06:02
-
Yes, but why limit at all? Couldn't they just add something like if (timestamp > limit) { add another int and start a new count from there, adding int1 + int2 to get the total } ? That would let us other 68 years more... – Shoe May 04 '11 at 06:06
-
@Charliepiga PHP is in some ways limited by the C libraries it relies on. Time in particular is a very tricky topic when you start trying to convert a UNIX timestamp to an actual human readable date/time. Go have a look at the mailing list for any date/time library. I know I just gave up after listening in on the nodatime mailing list for a while. – Matthew Scharley May 04 '11 at 06:12
-
@Charliepiga also, all values have to have a limit somewhere. There's no way to store an infinite data in a finite space (sadly!). Using 64b integers for the time count you can represent huge timespans, but as I said, the support on the C side is lacking at the moment. If you're lucky enough to have a PHP compiled against one of these C standard libraries you shouldn't actually have this limit if I'm reading between the lines in the documentation correctly. – Matthew Scharley May 04 '11 at 06:14
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.

- 18,572
- 3
- 31
- 36

- 22,978
- 13
- 65
- 96
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()."

- 42,059
- 16
- 116
- 175
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.

- 8,427
- 9
- 41
- 57