Fri, 5 May 2000 06:11:13 -0500
----- Original Message -----
From: Jacob Sparre Andersen <[log in to unmask]>
To: <[log in to unmask]>
Sent: May 05, 2000 5:17 AM
Subject: Re: C date package
> > I have heard that the programming language "C" will out
> > grow its date package in I think 2030.
> > I was wondering if there is any fact to this?
> Sort of.
> The year is 2038 iirc, and it is not as much a problem with
> C as with the date handling functions in many Unixes.
> Switching from a "32 bit compiler" to a "64 bit compiler"
> shold delay this problem a few million years.
The problem is not so much with "handling procedures," as it is
wuith the C time structure which uses a 32-bit signed integer
for the number of seconds past 00:00:00 UTC, January 1, 1970.
This limits the range to al little more than 68 years either
side of the so-called UNIX epoch. Switching to another
compiler will not sove anything -- it's the structure definition
that needs to be changed -- and 32-bit compilers could handle
thaty just fine.
> > and if Ada has any similar problems?
> The standard package Ada.Calendar defines a type Time whose
> internal implementation isn't specified by the language, but
> currently (1995 edition of Ada) you can only access years in
> the range 1901 .. 2099 for this type.
> I haven't read any articles on which problems we can expect,
> when the range of years is changed.
Since the gnat implementation of time is a 64-bit integer,
containing the number of nanoseconds after the UNIX epoch,
there's no problem.
By limiting the year range to 1901 .. 2099, Ada sidestepped
the issue of years evenly divisible by 4 that are not leap
years. 1900, and 2100 are both evenly divisible by 4, but not
> "Any, sufficiently complicated, experiment is indistinguishable from magic."