TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Transfer-Encoding: 7bit
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Geoff Bull <[log in to unmask]>
Date: Sun, 7 May 2000 09:28:36 +1000
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Reply-To: Geoff Bull <[log in to unmask]>
Parts/Attachments: text/plain (28 lines)
AdaWorks wrote:
> I am wondering if this problem with ANSI C extends to C++,
> Java,

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