Ada, calendar, and daylight savings

Ada, calendar, and daylight savings

[Corey Minyard]

I've been looking at calendar issues in Ada, I'm trying to write a 
complete calendar package for Ada.  I'm trying to understand how 
daylight savings works in Ada.Calendar.

An average day has 86_400 seconds (24 * 3600).  However, the day where 
daylight savings time is activated would seem to have 82_800 seconds (23 
* 3600) and the day where daylight savings time is deactivated, as just 
happened in the US, would seem to have 90_000 seconds (25 * 3600).

I would seem to me that the seconds in the day would not be dependent on 
daylight savings, but would instead range 0 .. 90_000.  Otherwise, 
certain times cannot be represented properly in certain circumstances. 
For instance, if you do the following:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Calendar; use Ada.Calendar;

procedure T1 is
    Time1   : Time;
    Time2   : Time;
    Year1   : Year_Number;
    Month1  : Month_Number;
    Day1    : Day_Number;
    Seconds : Duration;
begin
    Time1 := Time_Of(2001, 10, 28, 3600.0 * 1.5) + 3600.0;
    Split(Time1, Year1, Month1, Day1, Seconds);
    Time2 := Time_Of(Year1, Month1, Day1, Seconds);
    if (Time1 = Time2) then
       Put_Line("Times are equal");
    else
       Put_Line("Times are unequal");
    end if;
end T1;

The times will not be equal (at least on GNAT-3.12p in a US timezone). 
Is this the intent?  If so, there is no easy way to tell the two 
"1:30AM" times apart from each other, because the calendar package gives 
no way to tell if DST is active.  I guess you could figure out of DST 
might active on that day and add an hour to see if you get the same 
"seconds" value back, but that's kind of a pain.  I guess I'm used to 
the Java calendar package, which is quite powerful and comples.  The 
whole date/time things is a big mess, anyway.

Thanks for any insight on this.

-Corey

Re: Ada, calendar, and daylight savings

[Larry Kilgallen]

In article <3BDC97CE.8070304@acm.org>, Corey Minyard <minyard@acm.org> writes:
> I've been looking at calendar issues in Ada, I'm trying to write a 
> complete calendar package for Ada.  I'm trying to understand how 
> daylight savings works in Ada.Calendar.
> 
> An average day has 86_400 seconds (24 * 3600).  However, the day where 
> daylight savings time is activated would seem to have 82_800 seconds (23 
> * 3600) and the day where daylight savings time is deactivated, as just 
> happened in the US, would seem to have 90_000 seconds (25 * 3600).

If you choose to reset your clock in response to legislative initiatives,
you should reset your Ada calendar as well.

Daylight savings time is just a manipulation of a time zone, and time
zones are outside the Ada Calendar package, aren't they ?

Re: Ada, calendar, and daylight savings

[Corey Minyard]

Larry Kilgallen wrote:

> In article <3BDC97CE.8070304@acm.org>, Corey Minyard <minyard@acm.org> writes:
> 
>>I've been looking at calendar issues in Ada, I'm trying to write a 
>>complete calendar package for Ada.  I'm trying to understand how 
>>daylight savings works in Ada.Calendar.
>>
>>An average day has 86_400 seconds (24 * 3600).  However, the day where 
>>daylight savings time is activated would seem to have 82_800 seconds (23 
>>* 3600) and the day where daylight savings time is deactivated, as just 
>>happened in the US, would seem to have 90_000 seconds (25 * 3600).
>>
> 
> If you choose to reset your clock in response to legislative initiatives,
> you should reset your Ada calendar as well.
> 
> Daylight savings time is just a manipulation of a time zone, and time
> zones are outside the Ada Calendar package, aren't they ?


If only life were so simple.  I'm actually fairly familiar with how time 
works, I was wondering if there was any standard besides the vague 
statements made in the RM, maybe something buried in the AARM that 
compiler vendors implemented.

All systems that do a decent job handling time store the time in GMT and 
convert based upon timezone, DST, etc.  This way, you can correctly 
determine everything about the time and handle it in a portable manner.

Two basic problems I see with the way Ada time works:

* DST will cause problems, because you cannot print the time and be 100%
   sure it is unambiguous.  This is more of a problem than you might
   think when you have automated systems that take information and
   process it.  Every once in a while you will get wierd glitches.

* You cannot communicate using time with other systems, because you
   don't know if your local time is DST, what your GMT offset is, and
   thus you cannot determine what your local time really is or how to
   relate that to the time at another location.

In other words, Ada.Calendar is not useful for operating in a 
geographically distributed heterogeneous system where you have to 
coordinate times.


-Corey

Re: Ada, calendar, and daylight savings

[Larry Kilgallen]

In article <3BDCD0A9.5010101@acm.org>, Corey Minyard <minyard@acm.org> writes:

> In other words, Ada.Calendar is not useful for operating in a 
> geographically distributed heterogeneous system where you have to 
> coordinate times.

Only in cases where you insist on providing "local time" representations.

Re: Ada, calendar, and daylight savings

[Corey Minyard]

Larry Kilgallen wrote:

> In article <3BDCD0A9.5010101@acm.org>, Corey Minyard <minyard@acm.org> writes:
> 
> 
>>In other words, Ada.Calendar is not useful for operating in a 
>>geographically distributed heterogeneous system where you have to 
>>coordinate times.
>>
> 
> Only in cases where you insist on providing "local time" representations.
> 

No, that's all the calendar is good for.  It's not good for comparing 
times at different locations, in different computers that are possibly
not even running Ada.

-Corey

Re: Ada, calendar, and daylight savings

[Marin David Condic]

Remember that Ada was at least in part designed for embedded systems as its
original target. Time on embedded hardware can have all sorts of ambiguous
meanings and had they specified time in a manner stringent enough to satisfy
the things you are describing, it might not have been possible to implement
it on some embedded platforms. Lots of embedded machines might count time as
a certain number of clock ticks from when they were turned on and might have
no particular need to actually be in synch with any other machines. Time
might be relative to some starting epoch rather than normal calendar time.
Or synchronization might be a matter of negotiation with a small network of
other similar systems. Hence, requirements for the package Calendar might be
a little loose for some applications.

If Ada.Calendar and Ada.Real_Time don't provide all of the features you
think that Ada might need, perhaps this could be a candidate package for an
Ada standard component library. You might consider writing a specification
as a proposal for what such a package should look like. Or propose some
existing package you know of that might fit the needs.

DMC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Corey Minyard" <minyard@acm.org> wrote in message
news:3BDCD0A9.5010101@acm.org...
>
> If only life were so simple.  I'm actually fairly familiar with how time
> works, I was wondering if there was any standard besides the vague
> statements made in the RM, maybe something buried in the AARM that
> compiler vendors implemented.
>
> All systems that do a decent job handling time store the time in GMT and
> convert based upon timezone, DST, etc.  This way, you can correctly
> determine everything about the time and handle it in a portable manner.
>
> Two basic problems I see with the way Ada time works:
>
> * DST will cause problems, because you cannot print the time and be 100%
>    sure it is unambiguous.  This is more of a problem than you might
>    think when you have automated systems that take information and
>    process it.  Every once in a while you will get wierd glitches.
>
> * You cannot communicate using time with other systems, because you
>    don't know if your local time is DST, what your GMT offset is, and
>    thus you cannot determine what your local time really is or how to
>    relate that to the time at another location.
>
> In other words, Ada.Calendar is not useful for operating in a
> geographically distributed heterogeneous system where you have to
> coordinate times.
>

RE: Ada, calendar, and daylight savings

[Steven Deller]

Corey,
Take a look at Posix_Calendar.  It *looks* like Ada's package Ada.Calendar,
with the following modification:
  4.4.1.1 Description
  The type POSIX_Time shall be used to obtain times and dates from the
system.  Values of this type shall be
  independent of the current time zone in effect for the system, so that an
arbitrary value of this type may
  be interpreted at a later date using information in the TZ environment
variable (see 2.5.1).

Essentially this means that Posix_Calendar is, like Ada.Real_Time.??,
monotonically increasing.  And unlike Ada's Calendar package, it does not
try to mix in timezone information with "Time". Typically "Time" is UTC, but
the option is left to a Posix compliant system to choose something else.

When a timezone is layered over UTC, there is no difficulty with
interpretation, EXCEPT when trying to specify a year/month/day/time that
happens to be during the one period of the year when the same time occurs
twice, i.e. in the fall when the clocks are turned back, the same
year/month/day/time occurs twice so how can one specify unequivocally, which
UTC is intended?  So, is 28 Oct 2001 1:30am with EDT supposed to have a +4
or +5 offset added when converting to UTC?

The simple answer is that it is always the first time, i.e. the +4 offset
for EDT, that is added.  One then has to add one hour to the time out from
Time_Of if the input was intended to be the hour following the switch.

That does mean that after
   S : Time := Clock ;
   T : Time ;
   Split (S, Year, Month, Day, Seconds ) ;
   T := Time_Of ( Year, Month, Day, Seconds) ;
The values in T and S will not always be equal.  Of course, since Time can
have greater accuracy than Duration, it is always the case that T may not
equal S.

The answer to this is "Don't expect that identity from Calendar".  Typically
one works only in the underlying Time (which is unequivocal) and only uses a
timezone for during output.  Or possibly one uses timezone for input from
the user, and then must ask the user to differentiate the time if it happens
to be one with multiple interpretations in the timezone that is in effect.
Better just to ask the user to input UTC and convert according to that
timezone.

Because Ada mixed in timezone information with Calendar (and hid the
timezone), it is impossible to tell what is the real meaning of time, and
how to convert it reasonably.  The "Time" type in Ada.Calendar is
fundamentally a poor design.  The only reasonable use of Calendar in Ada is
for inexact, convenient "match the wall clock" use.  And even there it has
some problems.

For reasoning about time, one should use Ada.Real_Time.  For timestamping,
either create your own using a combination of Ada.Calendar and
Ada.Real_Time, or use Posix_Calendar.  Of course, using Ada.Real_Time is
awkward at best, since it is very difficult to actually find out what a time
span is (in printable units) without converting to Duration, and Duration
typically loses the very accuracy one wanted from Ada.Real_Time in the first
place.   Sigh...

Regards,
Steve
"Then, after a second or so, nothing continued to happen."
Steven Deller        Smooth Sailing LLC
410 757 6924         deller@smsail.com


> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Corey Minyard
> Sent: Sunday, October 28, 2001 6:41 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Ada, calendar, and daylight savings
>
>
> I've been looking at calendar issues in Ada, I'm trying to write a
> complete calendar package for Ada.  I'm trying to understand how
> daylight savings works in Ada.Calendar.
>
> An average day has 86_400 seconds (24 * 3600).  However, the
> day where
> daylight savings time is activated would seem to have 82_800
> seconds (23
> * 3600) and the day where daylight savings time is
> deactivated, as just
> happened in the US, would seem to have 90_000 seconds (25 * 3600).
>
> I would seem to me that the seconds in the day would not be
> dependent on
> daylight savings, but would instead range 0 .. 90_000.  Otherwise,
> certain times cannot be represented properly in certain
> circumstances.
> For instance, if you do the following:
>
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Calendar; use Ada.Calendar;
>
> procedure T1 is
>     Time1   : Time;
>     Time2   : Time;
>     Year1   : Year_Number;
>     Month1  : Month_Number;
>     Day1    : Day_Number;
>     Seconds : Duration;
> begin
>     Time1 := Time_Of(2001, 10, 28, 3600.0 * 1.5) + 3600.0;
>     Split(Time1, Year1, Month1, Day1, Seconds);
>     Time2 := Time_Of(Year1, Month1, Day1, Seconds);
>     if (Time1 = Time2) then
>        Put_Line("Times are equal");
>     else
>        Put_Line("Times are unequal");
>     end if;
> end T1;
>
> The times will not be equal (at least on GNAT-3.12p in a US
> timezone).
> Is this the intent?  If so, there is no easy way to tell the two
> "1:30AM" times apart from each other, because the calendar
> package gives
> no way to tell if DST is active.  I guess you could figure out of DST
> might active on that day and add an hour to see if you get the same
> "seconds" value back, but that's kind of a pain.  I guess I'm used to
> the Java calendar package, which is quite powerful and comples.  The
> whole date/time things is a big mess, anyway.
>
> Thanks for any insight on this.
>
> -Corey
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

RE: Ada, calendar, and daylight savings

[tmoran]

>The "Time" type in Ada.Calendar is fundamentally a poor design.  The
>only reasonable use of Calendar in Ada is for inexact, convenient
>"match the wall clock" use.
  The only reason Ada.Calendar.Clock would not normally be monotonic
is if some human decides so.  A missile during flight does not
normally worry about time zones.  If someone creates a file, then
sets back the clock and creates another file (or programs his
computer to set back the clock), that's hardly a design error
in Ada.  It would make more sense to call it a design error that
wall clocks don't read in UTC, but need to be adjusted when you
move, or twice a year even if you don't move.  Now *that's* goofy.

Re: Ada, calendar, and daylight savings

[Corey Minyard]

I won't argue about the goofiness of our time system, since I can't do 
anything about that :-).

Hopefully, missiles in flight are using UTC.  It makes no sense to use 
anything else.  However, you have no portable way of finding UTC in Ada. 
If not a design error, I would consider that a good candidate for future 
enhancement.

-Corey

tmoran@acm.org wrote:

>>The "Time" type in Ada.Calendar is fundamentally a poor design.  The
>>only reasonable use of Calendar in Ada is for inexact, convenient
>>"match the wall clock" use.
>>
>   The only reason Ada.Calendar.Clock would not normally be monotonic
> is if some human decides so.  A missile during flight does not
> normally worry about time zones.  If someone creates a file, then
> sets back the clock and creates another file (or programs his
> computer to set back the clock), that's hardly a design error
> in Ada.  It would make more sense to call it a design error that
> wall clocks don't read in UTC, but need to be adjusted when you
> move, or twice a year even if you don't move.  Now *that's* goofy.
> 

Re: Ada, calendar, and daylight savings

[tmoran]

> However, you have no portable way of finding UTC in Ada.  If not a design
> error, I would consider that a good candidate for future enhancement.
  Agreed, but for most programming it probably comes behind a portable way
to delete or rename files or scan a directory, for instance.  Certainly
    function To_UTC_Time (Local_Time : in Ada.Calendar.Time)
        return Ada.Calendar.Time;
would make sense in an Annex, so at least all implementations would look
the same.  But surely you then want to include function Day_Of_Week, leap
years, "+" and "-" with bigger than -86400.0 ..  86400.0 Duration and
adjusting for leap years and daylight savings, splitting into hours,
minutes, seconds, printing in various more or less standard forms, etc.

Re: Ada, calendar, and daylight savings

[Larry Kilgallen]

In article <3BDCEEFF.10409@acm.org>, Corey Minyard <minyard@acm.org> writes:
> I won't argue about the goofiness of our time system, since I can't do 
> anything about that :-).
> 
> Hopefully, missiles in flight are using UTC.  It makes no sense to use 
> anything else.  However, you have no portable way of finding UTC in Ada. 

Just ask for the time to be returned.

If your computer happens to be set to some unreliable source,
such as my watch, then you are at _least_ 5 minutes off from
_anybody's_ notion of time.  That is no longer a programming problem.

Please don't burden Ada.Calendar with illogical constructs.

Re: Ada, calendar, and daylight savings

[Corey Minyard]

Larry Kilgallen wrote:

> In article <3BDCEEFF.10409@acm.org>, Corey Minyard <minyard@acm.org> writes:
> 
>>I won't argue about the goofiness of our time system, since I can't do 
>>anything about that :-).
>>
>>Hopefully, missiles in flight are using UTC.  It makes no sense to use 
>>anything else.  However, you have no portable way of finding UTC in Ada. 
>>
> 
> Just ask for the time to be returned.
> 
> If your computer happens to be set to some unreliable source,
> such as my watch, then you are at _least_ 5 minutes off from
> _anybody's_ notion of time.  That is no longer a programming problem.
> 

You are correct, this is a system-level problem, not a programming 
language problem.  But it's relatively easy to solve to a pretty 
accurate level.

 >
 > Please don't burden Ada.Calendar with illogical constructs.

I don't agree with this.  Suppose I can build a system that has time 
reasonably coordinated between various parts of the system. 
"Reasonable" means "It's good enough for the application". It's not 
unreasonable to do this, I have done it many times, and I still can't 
use standard Ada to take advantage of this.  I could give thousands of 
examples, but I'll just give one.

I used to work on telephony systems, and for billing purposes, you 
should report UTC time, or some standard time, because the subscriber 
may not even be in the same timezone as the switch, and switches are
generally in different timezones and need to have their records 
coordinated.  Yet you generally want to report logs in local time and 
UTC time so the operators in the office can make sense of the logs and
machines can coordinate logs easily.  How are you going to do this in 
Ada?  You can't without using non-standard constructs.

Ok, I'll give another.  In the previous missile example, suppose the 
missile is communicating with satellites to maintain it's position.  It 
better be able to tell what time the satellites and ground stations are 
using and coordinate this with its time.  In distributed real-time 
systems, it's generally important to have some level of time 
coordination between system elements.

-Corey

Re: Ada, calendar, and daylight savings

[tmoran]

> How are you going to do this in Ada?  You can't without using
> non-standard constructs.
  It seems to me your problem is with your compiler vendor's
implementation, not with the language.  The ARM 9.6(24) says
"... as appropriate to an implementation defined timezone; ..."
You want that timezone to be UTC.  Why not just replace the
package body Ada.Calendar that your compiler supplies, with a
different one that returns UTC for Clock?  (A long time ago
my compiler vendor's Clock used the MSDOS 55 ms tick, which
was much to gross for my problem.  So I replaced his Ada.Calendar
body with one that used the PC's 8253 timer chip.  Not only was
it much finer, but it was much faster than a system call, so
profiling speeded up substantially. :)

Re: Ada, calendar, and daylight savings

[Corey Minyard]

tmoran@acm.org wrote:

>>How are you going to do this in Ada?  You can't without using
>>non-standard constructs.
>>
>   It seems to me your problem is with your compiler vendor's
> implementation, not with the language.  The ARM 9.6(24) says
> "... as appropriate to an implementation defined timezone; ..."
> You want that timezone to be UTC.  Why not just replace the
> package body Ada.Calendar that your compiler supplies, with a
> different one that returns UTC for Clock?  (A long time ago
> my compiler vendor's Clock used the MSDOS 55 ms tick, which
> was much to gross for my problem.  So I replaced his Ada.Calendar
> body with one that used the PC's 8253 timer chip.  Not only was
> it much finer, but it was much faster than a system call, so
> profiling speeded up substantially. :)
> 

But what if I want a portable package that does this, one that works 
with multiple compilers?  Surely portability should be one of Ada's 
strengths.  Sure, everyone can write their own code to do this, but then 
everyone has to write their own code.  In the world I work in (telephony 
and geographically distributed systems), dealing with time is very 
common, and I want my system to be portable between vendors and I want 
to be able to interact with non-Ada systems.

-Corey

Re: Ada, calendar, and daylight savings

[tmoran]

> > You want that timezone to be UTC.  Why not just replace the
> > package body Ada.Calendar that your compiler supplies, with a
> > different one that returns UTC for Clock?
> But what if I want a portable package that does this, one that works
> with multiple compilers?  Surely portability should be one of Ada's
  How to get what you want:
1) Wait for Ada 0Y
2) Design a commonly accepted approach, then get all the relevant
   compiler vendors to implement for each platform.
3) Design your own portable package specs, and implement on each
   platform you need.
4) Use the existing Ada.Calendar for a spec, and implement a UTC body
   for each compiler/platform your need.
You do of course have synchronized clocks in all your distributed
heterogenous systems.  Or your new package gets its clock from a central
source, regardless of where the program is running, and you don't allow
anyone to use (unsynchronized) Ada.Calendar
  Other solutions?

Re: Ada, calendar, and daylight savings

[Al Christians]

tmoran@acm.org wrote:
> 
>   Other solutions?

http://www.sonic.net/~ric/go/retime.htm


Al

Re: Ada, calendar, and daylight savings

[Larry Kilgallen]

In article <3BDE0B8D.6040409@acm.org>, Corey Minyard <minyard@acm.org> writes:

> But what if I want a portable package that does this, one that works 
> with multiple compilers?  Surely portability should be one of Ada's 
> strengths.

I am not sure what you are expecting when the underlying operating
system has no notion of the difference between Time and UTC.

If you want a constant offset, your portable could supply that
constant.

Re: Ada, calendar, and daylight savings

[Marin David Condic]

Not necessarily. They might be using a time base with launch time being the
start of the epoc. It depends on what the on-board computer has to do. If
all it needs to know is that after N seconds of burn it should shut off the
engines and coast, it really doesn't care if that is 10:30am EST or 23:40
GMT. An Ada.Calendar package that required UTC for its implementation might
just be the proverbial Brick S*** House in this application, which if this
application required a validated compiler might preclude Ada from playing in
that game.

Better that a more sophisticated time package be included as some kind of
annex or optional package. That's why I suggested that it might make a good
candidate for a standard component library.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Corey Minyard" <minyard@acm.org> wrote in message
news:3BDCEEFF.10409@acm.org...
>
> Hopefully, missiles in flight are using UTC.  It makes no sense to use
> anything else.  However, you have no portable way of finding UTC in Ada.
> If not a design error, I would consider that a good candidate for future
> enhancement.
>

Re: Ada, calendar, and daylight savings

[Corey Minyard]

Marin David Condic wrote:

> Not necessarily. They might be using a time base with launch time being the
> start of the epoc. It depends on what the on-board computer has to do. If
> all it needs to know is that after N seconds of burn it should shut off the
> engines and coast, it really doesn't care if that is 10:30am EST or 23:40
> GMT. An Ada.Calendar package that required UTC for its implementation might
> just be the proverbial Brick S*** House in this application, which if this
> application required a validated compiler might preclude Ada from playing in
> that game.


Sorry, I meant a UTC-like time, which Ada.Real_Time sort of provides as 
long as you don't try to print it out.  But if you are guiding the 
missile with GPS, for instance, then you need to coordinate with GPS 
time from the satellites, at least for positional measurement.

I'm not saying that it needs to use UTC for implementation, but I think 
it at least needs an annex to be able to coordinate time in some way. 
And if it uses daylight savings and timezones, the program needs some 
way to get that information and do translations into different timezones.


> 
> Better that a more sophisticated time package be included as some kind of
> annex or optional package. That's why I suggested that it might make a good
> candidate for a standard component library.


I'm already working on it.  I was just wondering how it should interact 
with Ada.Calendar, and I think I know now.


-Corey

Re: Ada, calendar, and daylight savings

[Nick Roberts]

My suggestion is as follows:

package Ada.Calendar.Worldwide is

   type Zoned_Time is private;
   -- This type includes the offset from UTC with the actual time.

   type Time_Zone_Offset is delta 30*60.0 range -12*60*60.0 .. +12*60*60.0;
   -- An offset from UTC, in seconds, as half-hour intervals from -12 to
   -- +12 hours. Localtime = TimeUTC + offset.

   function Clock return Zoned_Time;
   -- Also concurrently ascertains the local offset from UTC.

   function Local_Time (Zoned: Zoned_Time) return Time;
   -- Returns the local time from a Zoned_Time.

   function Time_UTC (Zoned: Zoned_Time) return Time;
   -- Returns the time UTC from a Zoned_Time.

   function Difference_from_UTC (Zoned: Zoned_Time) return Time_Zone_Offset;
   -- Returns the offset from UTC for a Zoned_Time.

   function Current_Difference_from_UTC return Time_Zone_Offset;
   -- Returns the offset from UTC currently set. Could change at any time.

   function To_Zoned (Date:       Time;
                      Difference: Time_Zone_Offset := 0.0)
      return Zoned_Time;

private
   ... -- implementation defined
end Ada.Calendar.Worldwide;

I think this should go into an optional Annex.

I'd like to see the range of Day_Duration extended:

   subtype Day_Duration  is Duration range 0.0 .. 86_405.0;

in Ada.Calendar in the next revision, to allow for added leap seconds.

--
Nick Roberts


"Corey Minyard" <minyard@acm.org> wrote in message
news:3BDD94E6.2030804@acm.org...
> Marin David Condic wrote:
> ...
> I'm not saying that it needs to use UTC for implementation, but I think
> it at least needs an annex to be able to coordinate time in some way.
> And if it uses daylight savings and timezones, the program needs some
> way to get that information and do translations into different timezones.
>
> > Better that a more sophisticated time package be included as some kind
of
> > annex or optional package. That's why I suggested that it might make a
good
> > candidate for a standard component library.
>
> I'm already working on it.  I was just wondering how it should interact
> with Ada.Calendar, and I think I know now.

Re: Ada, calendar, and daylight savings

[Al Christians]

Nick Roberts wrote:
> 
> My suggestion is as follows:
> 
> package Ada.Calendar.Worldwide is
> 
>    type Zoned_Time is private;
>    -- This type includes the offset from UTC with the actual time.
> 
>    type Time_Zone_Offset is delta 30*60.0 range -12*60*60.0 .. +12*60*60.0;
>    -- An offset from UTC, in seconds, as half-hour intervals from -12 to
>    -- +12 hours. Localtime = TimeUTC + offset.
> 

IIRC, and if this is one thing that they haven't changed since I was
a kid, there are some places that have more than 12 hours difference
from UTC.  That's local standard time.  Maybe more if you allow 
that daylight or double daylight time might apply in such places.


Al