----- "Martin Buchholz" <marti...@google.com> wrote: > On Thu, Jul 1, 2010 at 10:05, <jon.vanal...@redhat.com> wrote: > > Hi Martin, > > > > Thanks for your input. > > > > ----- "Martin Buchholz" <marti...@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
