AFAIK java stores dates in long variables as milliseconds. Consequently someday there will be no value (cause long has a maximum) which will correspond to the time of that i
It's easy enough to find out:
public class Test {
public static void main(String[] args) {
System.out.println(new java.util.Date(Long.MAX_VALUE));
}
}
Gives output (on my box):
Sun Aug 17 07:12:55 GMT 292278994
You may need to subtract a bit from Long.MAX_VALUE
to cope with your time zone overflowing the range of long, but it will give a reasonable ballpark :)
According to the current leap-year regulations the average number of days per year will be
365 + 1/4 − 1/100 + 1/400 = 365.2425 days per year
This means that we, in average, have 31556952000 milliseconds per year.
The long-value represents the number of milliseconds since the Epoch (1st of January, 1970) and the maximum number represented by a Java long is 263 − 1, so the following calculation
1970 + (263 − 1) / 31556952000
reveals that this representation will overflow year 292278994.
This can, as Jon Skeet points out, be confirmed by
-> System.out.println(new Date(Long.MAX_VALUE));
Sun Aug 17 08:12:55 CET 292278994