[Bug 394] pre Epoch bug : java.lang.ExceptionInInitializerError on systems with time set before January 1, 1970

[bugzilla-daemon at icedtea.classpath.org]

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


jon.vanalten at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|pre Epoch bug :             |pre Epoch bug :
                   |java.lang.ExceptionInInitial|java.lang.ExceptionInInitial
                   |izerError on systems with   |izerError on systems with
                   |uninitialized               |time set before January 1,
                   |clock/triggered after Y2038 |1970
                   |time overflow on 32bit      |
                   |systems                     |




------- Comment #15 from jon.vanalten at redhat.com  2010-06-28 14:30 -------
I'm gonna have to agree with Xerces here.  More below.

> > 
> > This doesn't make any sense.  currentTimeMillis() returns the current
> > time in milliseconds.  The current time is not before 1970, and never
> > will be.
> > 

Current *real world* time will not be before 1970.  But, should Java users need
to guarantee that their system clock is accurately set to real world time?  If
there is some documented compatibility requirement please advise.

> 
> the sign bit can get in several ways.
> 

Another potentially obscure way: if someone wishes to run some sort of
simulation that begins before 1970.

> 
> All of these errors above can of course get corrected in software...
> but not in software written in Java due to this JVM bug!

Exactly.

> > > John wrote:
> > 
> > >> 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.
> > > 
> > > I cant agree more, and this bug are one of these cases when Java fails to
> > > launch because currentTimeMillis() returns a negative number.
> > 
> > If currentTimeMillis() returns a negative number (on a 64-bit system), the
> > system is not Java compatible.
> > 
> 
> Why are it not Java compatible if it returns a negative number?
> Java doc only states:
> "Returns:
>     the difference, measured in milliseconds, between the current time and
> midnight, January 1, 1970 UTC."
> http://java.sun.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis%28%29
> 

Yes.  The use of a signed long return value necessarily imposes a range of
values, but the API language does not further restrict that range.

Anyhow, I've posted upstream about this, hopefully some upstream devs will
weigh in on this.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-June/004526.html

Also I'm changing the Summary to reflect the actual issue in this bug.  This is
not about 2038 overflow at all.


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