System.currentTimeMillis check in System class during startup.
martinrb at google.com
Wed Jul 7 22:39:10 UTC 2010
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:
>> 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.
More information about the core-libs-dev