Re: Ada.Calendar.Time_Zones

["Randy Brukardt" <randy@rrsoftware.com>]

"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. It is reasonable to ask if it *ought* to be unspecified, 
which is why I asked you to ask the ARG.

>> 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. That would have been a hard 
sell (even if it would have made more sense, since Ada.Calendar.Arithmetic 
probably would have been included directly as part of it). Your examples 
make it clear that we should have done that, but we obviously failed to 
notice that what we did instead doesn't quite work.

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.

                             Randy.