Is JavaScript's Date object susceptible to the Y2038 problem?

It shouldn't be - according to the ECMAScript specification seciont 15.9.1.1:

Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. 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,991 to 9,007,199,254,740,991; 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.

Only bitwise operators in JS are 32bit. There is no version that changes this, and there is no difference if your OS is 64bit. So if someone is using bitwise on timestamps, this could happen. For example, here I use bitwise or because I want the side-effect of all bitwise operators that they convert to int, just so I loose the milliseconds of the date.

new Date('2038-01-01T01:01:01.345') / 1000 | 0; // 2145913261.
new Date('2039-01-01T01:01:01.345') / 1000 | 0; // -2117518035. Wraps around...

I could be using anything else, such as Math.round, or parseInt and there will be no problem, but if I use bitwise, it's going to wrap around.