RE: Ada, calendar, and daylight savings

["Steven Deller" <deller@smsail.com>]

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
>