TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text 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:
"Robert I. Eachus" <[log in to unmask]>
Reply To:
Robert I. Eachus
Date:
Mon, 8 Mar 1999 19:49:08 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
At 06:06 PM 3/8/99 -0800, Steven Deller wrote:
>For my part, I am already worried about Ada's built in Y21000 bug.  I won't
>be around to see it cause problems, but my bet is that it will. That is one
>reason why I believe Ada's package Calendar to be severely flawed. The other
>is a failure to distinguish "time" from "local representation of time", but
>that is yet another contentious issue.  All in all, the "engineer-designed"
>Ada date and time functions leave a lot to be desired, all without any "bad
>manager" direction -- we engineers can mess it up just fine without
>management.

   Actually, you are out of date.  The "fix" to the Ada Doom date problem,
if it can be called that requires a two step process, and the first step
was taken in Ada 95.  RM 9.6(26) relaxes the rules on when Time_Error must
be raised.  This allows values of type Time outside the range January 1,
1901..December 31, 2099.

   The next step, which can and should be taken in a later version of the
standard is to require that type Time represent a wider range, and change
the definition of Year_Number.  By splitting the change into two parts,
there is no sudden requirement to change data representations, etc.

   Of course, I imagine that the "fix" will probably support not that much
wider a range.  The problem is not with Ada but with the Gregorian
calendar.  There are several countries that adopted it in this century, so
in Russia and Greece for example, dates early in the century are currently
wrong.  If we extend calendar back to say 1600, do we allow localization
for the Julian to Gregorian shift?

   In the other direction there is a different problem.  By now everyone
should know that 2000 is a leap year and 2100 is not.  But at least one
further correction to the calendar is necessary.  By the year 4000, there
will be a need to eliminate a leap year.  (Actually, the calendar gets out
of synch about a millenium before then but 4000 is the furthest date I have
heard proposed for "not a leap year.")  So what rule will be chosen to
"fix" the calendar?  Every 4000 years?  Every 3600 years?  And, oh yes, the
length of the day and year keep changing, to cause other problems. (Does
anyone correct their Calendar package for leap seconds?)

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

ATOM RSS1 RSS2