january 19, 2038 end of the world
timestamp max value
2 31 seconds
gps rollover 2038
2038 01 19 03:14:07
<script> var d = new Date(); alert(d.getFullYear()+" "+d.getMonth()+" "+d.getDate()); </script>
It alerts 2039 10 14 successfully unlike PHP which prints "9 Oct, 1903 07:45:59"
How JS handles this? Explanation is appreciated as I am confused!
32bit PHP uses 32bit integers, whose max value puts the last UNIX timestamp that can be expressed by them in 2038. That's widely known as the Y2K38 problem and affects virtually all 32bit software using UNIX timestamps. Moving to 64bits or libraries which work with other timestamp representations (in the case of PHP the
DateTime class) solves this problem.
That means that you can represent some really large numbers, but at the cost of precision. A simple test is this:
i = 1384440291042 => 1384440291042 i = 13844402910429 => 13844402910429 i = 138444029104299 => 138444029104299 i = 1384440291042999 => 1384440291042999 i = 13844402910429999 => 13844402910430000 i = 138444029104299999 => 138444029104300000 i = 1384440291042999999 => 1384440291043000000 i = 13844402910429999999 => 13844402910430000000
The year 2038 problem applies to signed 32 bit timestamps only, which PHP and some other systems use. A signed 32-bit timestamp's range runs out with the number of seconds in 2038.
From the Wikipedia article (emphasis mine):
The year 2038 problem may cause some computer software to fail at some point near the year 2038. The problem affects all software and systems that both store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.1 The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. ... This is caused by integer overflow. The counter "runs out" of usable digits, "increments" the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero). This is likely to cause problems for users of these systems due to erroneous calculations.
Storing a timestamp in a variable with a greater range solves the problem.
'YouTube's Gangnam Style problem may prove that all computers , One billion seconds (approximately 32 years) after 01:27:28 UTC on 13 May 2006 is beyond the 2038 cutoff date. Thus, after this time, the time-out calculation On January 19, 2038 all signed 32-bit timestamps representing time and date relative to the "UNIX epoch" will roll over. Just 68 years later, in 2106, all unsigned 32-bit values will do so. But even before that, timestamps used by the Network Time Protocol will roll over in 2036. Since it's only 19 years to Armageddon, I'll lok at what this means for Linux, Windows and other systems and how
This implies that JS uses UNIX timestamp.
Just a sidenote: Unix timestamp are seconds since 1970. JS time is milliseconds since 1970. So JS timestamp does not fit in a 32 bit int much earlier (but JS does not use 32 bit int for this)
What is the Unix 32-bit time overflow?, It's more readable and not vulnerable to the Year 2038 problem . It's a good alternative, although a lot of the time UNIX timestamps are honestly not identifying the device beyond headers sent etc. and you can't just use an IP If only we didn't need to add so much to our payload just to handle dates. Since now thank to Task #1264 "Per thread time zone infrastructure" we mostly use our own functions for TIME to/from time_t conversion we can treat internal value of TIMESTAMP type as unsigned and so handle dates bigger than year 2038. (BTW we can't extend TIMESTAMP range downwards since time_t value 0 has special meaning for us so we can't handle datetime value equivalent to '1970-01-01 00:00
It can. Try out
Sat Sep 13 275760 03:00:00 GMT+0300 (Eastern European Summer Time)
Year 275760 is is a bit beyond 2038 :)
Read the spec section 126.96.36.199
A Date object contains a Number indicating a particular instant in time to within a millisecond. Such a Number is called a time value. A time value may also be NaN, indicating that the Date object does not represent a specific instant of time.
Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day. ECMAScript Number values can represent all integers from –9,007,199,254,740,992 to 9,007,199,254,740,992; this range suffices to measure times to millisecond precision for any instant that is within approximately 285,616 years, either forward or backward, from 01 January, 1970 UTC.
The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.
The exact moment of midnight at the beginning of 01 January, 1970 UTC is represented by the value +0.
Solving the Year 2038 problem in the Linux kernel, usr/bin/istat and /sbin/helpers/jfs2/istat currently cannot handle dates beyond Blockchain · Artificial Intelligence · Containers · Analytics · Node.js The code will be changed in a way to utilize 64 bit functions and data structures to accomodate for this. Note: Files in a JFS filesystem have a 32 bit timestamp design limitation. Q&A for Ubuntu users and developers. Stack Exchange Network. Stack Exchange network consists of 176 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
- I don't understand why PHP wouldn't just use unsigned integers. That would effectively double the date range, right?
- @Alex Because then you couldn't represent any dates before 1970, because PHP tries to keep types simple and doesn't want to bother programmers with the difference between signed and unsigned ints, because using only unsigned ints means you couldn't represent any negative numbers in PHP, because that would only extend the deadline by some ~70 years instead of solving it entirely.
- @AlexW it is in order to hold dates prior to 1970 which is considered as an epoch in UNIX timestamp,right?
- one more thing to ask @deceze, as a long int is 4 bytes and a float is also 4 bytes (although in C), what about JS while it uses float instead of int...?
- @rosemary What about it? Not sure what you're asking.
- fun fact,
9007199254740991now in chrome. so this issue seems to be resolved already.
- Worth noting that
new Date(Number.MAX_SAFE_INTEGER)yields "Invalid Date". But you can definitely use
- @mikermcneil True, but your answer is not accurate either, updated mine to represent the real limit :) Thanks for making me do it :D