System.currentTimeMillis check in System class during startup.

jon.vanalten at jon.vanalten at
Thu Jul 8 13:16:25 UTC 2010

----- "Martin Buchholz" <martinrb at> wrote:

> On Thu, Jul 1, 2010 at 10:05,  <jon.vanalten at> wrote:
> > Hi Martin,
> >
> > Thanks for your input.
> >
> > ----- "Martin Buchholz" <martinrb at> 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:
> >>
> >> 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:
> >
> >
> >
> > 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).



More information about the core-libs-dev mailing list