61

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!

phuclv
  • 37,963
  • 15
  • 156
  • 475
user246114
  • 50,223
  • 42
  • 112
  • 149

6 Answers6

138

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.

enter image description here

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
14

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.

krock
  • 28,904
  • 13
  • 79
  • 85
11

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).

emory
  • 10,725
  • 2
  • 30
  • 58
10

"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. :-)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
6

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).

David Z
  • 128,184
  • 27
  • 255
  • 279
4

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

Robin Coe
  • 750
  • 7
  • 28
  • 2
    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. – Suma Mar 27 '20 at 10:41
  • And what exactly do you think will happen in a 32-bit JRE? Legacy is a thing. – Robin Coe May 28 '20 at 16:40
  • 2
    Long is 64b even on 32-bit JRE. See https://stackoverflow.com/a/18017796/16673 – Suma May 30 '20 at 16:03
  • 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. – Robin Coe May 31 '20 at 18:28
  • 2
    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. – Suma May 31 '20 at 19:03
  • 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. – Robin Coe Jun 01 '20 at 14:19
  • 2
    You can check the implementations for various OSes e.g. in [JDK OS Linux](http://hg.openjdk.java.net/jdk7u/jdk7u60/hotspot/file/ba66650acf63/src/os/linux/vm/os_linux.cpp) and [JDK OS Windows](http://hg.openjdk.java.net/jdk7u/jdk7u60/hotspot/file/ba66650acf63/src/os/windows/vm/os_windows.cpp) (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. – Suma Jun 01 '20 at 15:02
  • 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? – Suma Jun 01 '20 at 15:22
  • 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. – Scrubbie Aug 12 '23 at 17:54