System.currentTimeMillis check in System class during startup.

[jon.vanalten at redhat.com]

----- "Martin Buchholz" <martinrb at google.com> wrote:

> On Thu, Jul 1, 2010 at 10:05,  <jon.vanalten at redhat.com> wrote:
> > Hi Martin,
> >
> > Thanks for your input.
> >
> > ----- "Martin Buchholz" <martinrb at google.com> wrote:
> >
> >> It's not at all clear that one cannot solve the y2038 problem on
> >> systems with a 32-bit time_t.
> >> That's what Michael Schwern is trying to do here:
> >> http://code.google.com/p/y2038/
> >> His code is available.
> >>
> >
> > Unfortunately unless I am missing something this example is not
> solving the y2038 problem for when a 32-bit system clock reaches
> overflow.  See:
> >
> > http://code.google.com/p/y2038/wiki/HowItWorks
> >
> > It is simply allowing for representations of future times beyond
> 2038.  Java already has this.
> 
> The JDK appears to implement currentTimeMillis by simply calling
> gettimeofday and using the time_t values in that directly, without
> any
> additional cleverness.  But I thought the whole point of the y2038
> project is to provide the additional cleverness that you can conjure
> up a 64-bit time_t on a system that only has a 32-bit time_t.
> 

Err, perhaps I have been clear like mud.  The functions targeted by y2038 are those that take a time value and break it down into a struct tm.  They do not provide any tricks for retrieving the current system time.  When I said that "Java already has this", I meant that within the Java libraries, the data types used already allow for representation of a wide range of dates.  For example, with currentTimeMillis() returns a long, which (if we ignore any underlying implementation or host system issues) allows dates nearly 300 million years into the past or future.  The Date/Calendar classes similarly can represent far past and far future dates.

Definitely, both for currentTimeMillis() and for other internal use of gettimeofday(), Java is currently vulnerable to 32-bit system clock overflow.  I've been looking at this and have some ideas for workarounds.  More to follow in future post(s).

cheers,

jon