TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Geoff Bull <[log in to unmask]>
Reply To:
Geoff Bull <[log in to unmask]>
Date:
Sun, 7 May 2000 09:28:36 +1000
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
AdaWorks wrote:
>
> I am wondering if this problem with ANSI C extends to C++,
> Java,
Date

public Date(long date)

     Allocates a Date object and initializes it to represent the
specified number of milliseconds since the standard base
     time known as "the epoch", namely January 1, 1970, 00:00:00 GMT.
     Parameters:
          date - the milliseconds since January 1, 1970, 00:00:00 GMT.

In Java, a long is guaranteed to be 64 bits so the Java date
will wrap ina few hundred million years. Of course, this doesn't
help if the OS is keeping a 32 bit count.


I have always thought this is a storm in a teacup about C.
Isn't it "merely" a matter of defining a long to be 64 bits
for a platform (is time_t always defined to be a long?),
recompiling OS and apps, fixing apps that assumed long was 32 bits.
Does Alpha C/Unix, or any othe platform that has 64 bit longs,
suffer from the 2038 problem?

Geoff

ATOM RSS1 RSS2