[Bug 394] Y2038 time overflow/pre Epoch bug : java.lang.ExceptionInInitializerError on systems with uninitialized clock

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394





------- Comment #9 from jon.vanalten at redhat.com  2010-06-22 20:32 -------
(In reply to comment #8)
> I suspect that when currentTimeMillis is negative it'll break elsewhere.
> So, I doubt that a fix in one place will help.
> 

Definitely, there are plenty of other potential 2038-affected bugs in
IcedTea/OpenJDK.  But, most of them are such that they expect time to move
forwards and then terrible things happen if the clock rolls over during
runtime, rather than this simple "time should not be negative" thing.

Any checks that are failing simply because currentTimeMillis() is negative are
bugs in themselves IMO (unless they really mean to check that the system clock
is later than 1970), and should be fixed separately if found.

The rolling over of the clock is entirely system dependent, we are not reaching
the limits of Long.<MAX|MIN>_VALUE here on the return values of
currentTimeMillis(), but rather the limits of how the epoch time is being
stored in the OS.  So, I still think that any bugs that are truly due to the
system clock overflowing cannot be resolved within the JDK.

In fact, when we start to approach the overflow value in around 292 million
years[1], and if openJDK still exists at that time, I will be proud to have the
notoriety of refusing to fix it here in 2010.  ;)

Thoughts?

[1]
http://www.wolframalpha.com/input/?i=2^63+milliseconds+after+January+1%2C+1970


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.