2

I use for example this code to check if the user can do some action. So the user can only do one action each 5 seconds.

if((System.currentTimeMillis() - lastTime) > 5000)
{
    // Message: Ok, you can do action now.
}else{
    // Message: Have to wait 5 seconds to do action.
    return;
}

lastTime = System.currentTimeMillis();

But as we all know, System.currentTimeMillis() returns a long, and that long can keep increasing until it turns negativ..

My code should run on a server that need to have more than 1 month of uptime. So I'm afraid at some point System.currentTimeMillis() will return a negativ value and my code will always tell the user that he need to wait 5 seconds or the opposite.

I'm having real hard time to concentrate on this piece of code and fix it, so I'm asking you guys if you have a tip on how to fix this problem and make my code 100% safe.

Reacen
  • 2,312
  • 5
  • 23
  • 33

6 Answers6

7

Don't worry about it.

You know whos problem it is?

The guy who will need to update it on Sun Aug 17 03:12:55 GMT-04:00 292278994.

Community
  • 1
  • 1
Andrew
  • 13,757
  • 13
  • 66
  • 84
  • Typical **lazy** mentality... leave the problem for our alien-hybrid super-sentient future generation to worry about. Y2G will be mass hyteria! – Java Drinker Sep 09 '11 at 15:59
  • +1: The dinosaurs collectively lasted 180 millions years. We will have evolved or died out by then. ;) – Peter Lawrey Sep 09 '11 at 16:02
  • I don't believe Java is going to die out any time soon, but I would hope humans last longer than Java does. – Peter Lawrey Sep 09 '11 at 16:03
  • Even after the year 292278994 it won't be a problem as long as the difference between times is less than 292278994 years (see my answer) – Peter Lawrey Sep 09 '11 at 16:19
1

A long in milliseconds can represent 292 277 266 years. I'm not sure this is the kind of thing you need to be worried about.

Java Drinker
  • 3,127
  • 1
  • 21
  • 19
1

According to this thread, it will overflow in year 292278994. I will say it is plenty of time:)

Community
  • 1
  • 1
Petar Minchev
  • 46,889
  • 11
  • 103
  • 119
0

System.currentTimeMillis() returns the time in milliseconds, between the current time and midnight, January 1, 1970 UTC. With the largest maximum value that can be represented as a long is 9,223,372,036,854,775,807, if my calculation is right (long max / (1000 * 3600 * 24 * 365)), that could go up to more than 292471208 years. If your program can survive that long, let someone who will be born that many years later worry about it like we did for Y2K.

Kevin Le - Khnle
  • 10,579
  • 11
  • 54
  • 80
0

As everyone has said don't worry about it but for future reference maybe you'd prefer to use Joda-Time to ask this kind of question.

import org.joda.time.DateTime;

if(lastTime.plusSeconds(5).isAfterNow()) {
    // Message: Ok, you can do action now.
}
else {
    // Message: Have to wait 5 seconds to do action.
    return;
}

lastTime = new DateTime();
andeyatz
  • 428
  • 3
  • 9
  • Thank's, but this is slower.. I think my way is faster when running on a 64bit machine – Reacen Sep 09 '11 at 16:08
  • In which case invert the operation & create the `lastTime` var plus 5 seconds. I can't see it slowing you down too much no matter what architecture of machine you are on – andeyatz Sep 12 '11 at 07:52
0

Even though the time it will overflow is far, far into the future as others have stated. It won't even be a problem then because you are taking the difference of two times. e.g. say you take the year 292,278,994 and the year 292,278,995 (which would appear to be negative), the difference is only 1 year (a positive number) e.g. if you take

long overflowYear = Long.MIN_VALUE; // overvflow of Long.MAX_VALUE + 1
long okayYear = Long.MAX_VALUE;
// time = 1 (positive due to an underflow!)
long time = overflowYear - okayYear; 

This sort of this could happen with System.nanoTime() as it doesn't have a defined starting time and ticks one million time faster. However as long as you take the time difference, it doesn't matter if one is negative or positive provided they are less than 292 years apart.

So in answer to your question, even after the year 292,278,994 you won't have a problem until the application have been running for more than 292,278,994 years between calls to System.currentTimeMillis() !

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130