Re: Ada.Calendar.Time_Zones

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

"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. You've asked this question here before, and if you want 
a useful answer, you need to ask the ARG by sending a question to 
Ada-Comment. It's pointless to ask the question here more than once; if you 
don't care enough to ask the question on Ada-Comment, then you are just 
trolling. Please don't; we have enough of that here as it is.

...
> P.S. Why not to simply provide Ada.UTC_Time (with conversion to
> Ada.Calendar.Time) instead of this mess?

The short answer is that it wouldn't provide any support for time zones 
other than UTC and (unspecified) local time zone.

My original idea was that there would be a UTC_Clock function that returned 
the correct time. In particular, I viewed a value of Ada.Calendar.Time as an 
absolute time without any knowledge of a time zone. Specifically, value of 
Ada.Calendar.Time would represent a value like 09:53:00 August 31 2008 with 
no particular time zone implied. That means that all of the other operations 
make sense with no extra interpretation.

However, that model didn't fly with some members of the ARG: they view a 
value of Ada.Calendar.Time as a particular political time. In that view, a 
UTC_Clock and Ada.Calendar.Clock would always return the same (logical) 
value, and thus the split and formatting routines would always return the 
same answer (the political time). Thus some method is needed to tell the 
value what time zone the value is intrepreted to be in.

I think we screwed up by using a visible offset value, however; it should 
have been a private type that could work any way the implementation wanted. 
Particularly, there should have been constants for UTC and local time, and 
then an implementation could add more if they wanted.

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.

                                                 Randy.