Re: Ada.Calendar.Time_Zones

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 6 Aug 2008 21:52:53 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net...
>> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net...
>>>> Does anybody know the meaning of the result returned by UTC_Time_Offset?
>>>
>>> It's as the RM says.
>>
>> But how to translate what it says into concrete numbers:
>>
>>   UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =?
>>
>> OK, I am posting that to Ada comments as you suggested.
> 
> I don't think the RM answers your question, which technically means that it 
> is unspecified.

Which perplexes me much. How could it happen that an Ada library function
has undefined behavior.

> It is reasonable to ask if it *ought* to be unspecified, 
> which is why I asked you to ask the ARG.

Yes, I did.
 
>>> It's pretty obvious, though, that there is no way to do this correctly
>>> unless the time type is based on UTC (time-zone-less) time. And because 
>>> of
>>> compatibility concerns, the only way to do that is to completely junk
>>> Ada.Calendar and start over, duplicating essentially everything. You're
>>> probably right that we should have done that, but it would always be a 
>>> tough
>>> sell (lots of people would say that Ada.Calendar is "good enough") --  
>>> which
>>> is why you need to ask this question directly to the ARG. (And get as 
>>> many
>>> people as possible to support it, too.) I alone could never produce 
>>> critical
>>> mass on this topic.
>>
>> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic,
>> Ada.Calendar.Formatting are all new packages. All of them have an
>> inconsistent semantics, because Time_Of is necessarily inconsistent [*].
>> Zone offset is simply not a function of the local time. It is of the UTC
>> time.
> 
> You'd have to completely duplicate the contents of Ada.Calendar using a new, 
> very similar time type that is based on UTC.

Hmm, is Ada.Calendar big? Anyway one didn't hesitate to duplicate most of
it in Ada.Calendar.Arithmetic.

But all that stuff like Time_Of etc is not really needed with UTC_Time. The
package should provide Clock, +, -, <, <=, >, >=:

package Ada.UTC_Time is
   type UTC_Time is private;
   function Clock return UTC_Time;
   function "+" (Left : UTC_Time;   Right : Duration) return UTC_Time;
   function "+" (Left : Duration; Right : UTC_Time) return UTC_Time;
   function "-" (Left : UTC_Time;   Right : Duration) return UTC_Time;
   function "-" (Left : UTC_Time;   UTC_Time : Time) return Duration;
   function "<" (Left, Right : UTC_Time) return Boolean;
   function "<="(Left, Right : UTC_Time) return Boolean;
   function ">" (Left, Right : UTC_Time) return Boolean;
   function ">="(Left, Right : UTC_Time) return Boolean;
end Ada.UTC_Time;

That's it.

Then:

package Ada.UTC_Time.Time_Zones is
   type Time_Offset is range -28*60 .. 28*60;
       -- This is well-defined
   function UTC_Time_Offset (Date : UTC_Time := Clock) return Time_Offset;

   function To_Calendar_Time  (Time : UTC_Time; Time_Zone)  return Time;
   function To_Calendar_Time  (Time : UTC_Time; Time_Zone; Time_Offset)
      return Time;
      -- Time Zone is always required for the backward conversion
   function To_UTC_Time (Time : Time; Time_Zone; Time_Offset)
       return Time;
end Ada.UTC_Time.Time_Zones;

I would also like to see conversions between Ada.Real_Time.Time and
UTC_Time.

> The real question is whether the hole is important enough to try to fix 
> (given that the fix is going require adding a lot more mechanism). That's a 
> question I can't answer.

Our problem is that we need to exchange time-stamped data with the outside
world. So we have to convert UTC forth and back to Ada.Real_Time.Time. It
is to expect that the system might become out of service for when the clock
is adjusted. Considering similar cases, like air flight traffic control
systems dealing with GPS clock etc, I wonder how they would handle that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de