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