From: Bob Leif
To: Geoff Bull et al.
I changed the name to reflect the subject under discussion.
I believe that it would be appropriate to create a tagged type, Time_Class.
This way, we can extend it. We now have 5 years of object oriented
programming with Ada 95 and we know it works. It should be possible but not
required to restrict this package to not perform run-time dispatching.
package Ada.Calendar_OO is
type Time_Class is tagged private;
From: Team Ada: Ada Advocacy Issues (83 & 95)
[mailto:[log in to unmask]]On Behalf Of Geoff Bull
Sent: Monday, May 08, 2000 10:03 PM
To: [log in to unmask]
Subject: Re: C date package
> Dale Stanbrough wrote:
> > i would disagree. In the same way that we use GMT as standard for time,
Isn't GMT defunct?
> > we should be able to come up with a time based system that underlies the
> > various views that are needed.
Sounds simple, just base time in the primary time standard: TAI
(International Atomic Time). Ada.Real_Time is already based on TAI.
And then you layer, Gregorian, Julian, Jewish or whatever calendar you want
on top of that ?
Trouble is people will start arguing about resolution and range.
Do we try to cover needs of astronomers, real time programmer's and
the rest of us with one time abstraction.
The current Ada.Calendar is pretty weak - just reports an implementation
defined time - local time on my system.
> > After all, a date that is 30,000 days ago -is- 30,000 days ago, no
> > what calendar is used.
In a sense this isn't true.
30,000 rotations of the earth is /= 30,000 * 24 * 60 * 60 seconds.
The problem with dealing with time and date is that you are mixing up
the lapse of a number of fixed size seconds (fixed by definition),
the lapse of number of varying size days (in terms of number of seconds).
> 1752's interpretation could then be viewed by using a gregorian calendar
> package, or a julian calendar package (i presume this is where the
> difference is...).
First you've to change the standard so you can even creat a date in the
here a useful calendar site: