When will System.currentTimeMillis() overflow?

Question

I have a web app which orders stuff using a timestamp, which is just a long. My web app backend happens to be written in java, so I am using:

long timestamp = System.currentTimeMillis();

what year (approximately) will this fail? I mean at some point, the range of a long is going to overflow, right? We may all be long-dead, but I'm just curious. Will it be like y2k all over again? What can I do to prepare for this? Ridiculous, I know, just curious!

Quintillion

Answer 1

It will overflow at

System.out.println(new Date(Long.MAX_VALUE));

which prints

Sun Aug 17 03:12:55 GMT-04:00 292278994

That's thus after a bit more than 292 million years. I'd say, there's a plenty of time to invent a solution in the meanwhile. To be honest, I don't expect the humanhood to survive this. We exist only a few seconds as compared to the age of the world in hour scale and it won't take long.

Scolecite

Answer 2

Try running this code:

System.out.println(new Date(Long.MAX_VALUE));

Which prints something like this depending on your locale:

Sun Aug 17 17:12:55 EST 292278994

Very long in the future, so no need to worry about overflow.

Scorify

Answer 3

"What can I do to prepare for this?"

Well, you could have your coffin kitted out with the latest and greatest IT gear / geek toys. But somehow I think they will be a bit "outdated" in 292,278,994 AD. And you will be pretty bored with them by then.

Mind you, you will have enough time to rewrite the OS from scratch to use a 128 bit clock. That sounds like a fun project to wile away the time. :-)

Sambo

Answer 4

It seems unlikely that your web app will still be around on Sun Aug 17 17:12:55 EST 292278994 (as calculated by others). It seem even more unlikely that you will still be responsible for the web app then. (If you are still responsible for it, you will probably be paid at a higher rate in the future, so let it slide for now and collect the big bucks later:)

It is much, much more likely that the system clock is set incorrectly to some outlandish value. You can prepare for this relatively easily - pseudocode below

long reasonableDate ( )
{
     long timestamp = System.currentTimeMillis();
     assert timestamp after 2010AD : "We developed this web app in 2010.  Maybe the clock is off." ;
     assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD.  Maybe the clock is off." ;
     return ( timestamp ) ;
}

If you are alive when any one of those assertions is triggered, then you can probably charge your clients big bucks for either fixing the system clock or changing the assertion (as appropriate).

Altarpiece

Answer 5

The maximum value of a Java long is 2^63 - 1, and if you convert that many milliseconds into practical units of time, you find that the counter will overflow in approximately 290 million years. So don't worry about it ;-) If anyone's still around to run the computers, I'm sure they will have switched to 128-bit time counters by then (or picked a new epoch).

Melaniemelanin

Answer 6

The mistake in these answers is assuming that the system you're running is 64 bit and returns a 64 bit representation of millis since 1970. Linux uses a 32 bit representation and overflow is in 2038.

See Year 2038 problem for reference

Johppa

The questions seems to be about Java. The documentation specifies the result as a long value of milliseconds since midnight, January 1, 1970 UTC, no matter what the underlying system is. – Histidine

And what exactly do you think will happen in a 32-bit JRE? Legacy is a thing. – Johppa

Long is 64b even on 32-bit JRE. See https://mcmap.net/q/323901/-will-an-int-be-32bit-and-a-long-64bit-regardless-of-whether-the-system-is-32-or-64-bit – Histidine

System.currentTimeInMillis is a native call and relies on the underlying operating system. If the value from time_t is incorrect, then it doesn't matter how many bits are used. – Johppa

I am afraid you are wrong. It does not matter how is the System.currentTimeInMillis implemented, it has to follow the specification, which is a long value in milliseconds since midnight, January 1, 1970 UTC. What is left implementation specific is the granularity, which is often much coarser than a millisecond, but the range is given by the specification. – Histidine

If the underlying C implementation suffers from an overflow, which it will in a 32-bit OS, then the value it provides to Java's 64-bit long will be incorrect. Remember that a long is 64-bit precision, which is not 64-bit accuracy. Java is not the system of record for computing a timestamp, the OS is. – Johppa

You can check the implementations for various OSes e.g. in JDK OS Linux and JDK OS Windows (search for javaTimeMillis). You will see none of those overflows, they both use system calls which are not limited to 32b milliseconds. If you are aware of some particular platform where the overflow happens, please, show it. – Histidine

I think you are right and I misunderstood the problem. The 2038 overflow is not for 32b milliseconds, but for 32b seconds, which is used in the Linux implementation I have linked to. Perhaps the link (or source) could be included in the answer to make the explanation clearer? – Histidine

This answer knocks other answers but fails to address the question itself. The question asked is essentially, "When will the Java time call overflow?" And the fact is that, as defined by the Java API, a System.currentTimeMillis() method call will not overflow (i.e. return a negative number) for some 292 million years. Any deviation from that behavior would be a violation of the API and thus an indication of a bug in the JRE. – Own