CODEWITHSUNDEEP
javatimeoverflowyear2038
user246114
user246114

Reputation: 51611

When will System.currentTimeMillis() overflow?

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!

Upvotes: 61

Views: 18358

Answers (6)

Robin Coe
Robin Coe

Reputation: 750

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

Upvotes: 4

BalusC
BalusC

Reputation: 1108712

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

Upvotes: 141

emory
emory

Reputation: 10891

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

Upvotes: 10

David Z
David Z

Reputation: 131570

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

Upvotes: 6

Stephen C
Stephen C

Reputation: 718788

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

Upvotes: 10

krock
krock

Reputation: 29619

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.

Upvotes: 14

Related Questions