Ada.Calendar.Time_Zones

Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
says:

   "Returns, as a number of minutes, the difference between the
implementation-defined time zone of Calendar, and UTC time, at the time
Date."

This is ill-defined. Political time has overlapping intervals in presence
of daylight saving time, when the clock is adjusted backwards.

The overlapping time interval has two differences to the UTC time. So which
one is returned by UTC_Time_Offset?

Furthermore, some intervals are missing in political time. That is when the
clock is adjusted forward. What is the difference then? Unknown_Zone_Error?

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

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

Re: Ada.Calendar.Time_Zones

[google1]

On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
> says:
>
>    "Returns, as a number of minutes, the difference between the
> implementation-defined time zone of Calendar, and UTC time, at the time
> Date."
>
> This is ill-defined. Political time has overlapping intervals in presence
> of daylight saving time, when the clock is adjusted backwards.

That definition accounts for DST shifts. It says "at the time
Date," which means that if the date falls into a period where
the locale is in a DST shift, it will return the DST offset.
Otherwise, it will return the ST offset.

Unix systems keep information about historic and future (planned)
shifts in their locale's time offset in the tzdata database. I
suspect Windows and other systems have something similar, so by
using that database it is possible to find the time offset for
any point in the past, as well as predicted ones for points in
the future.

> The overlapping time interval has two differences to the UTC time. So which
> one is returned by UTC_Time_Offset?
>
> Furthermore, some intervals are missing in political time. That is when the
> clock is adjusted forward. What is the difference then? Unknown_Zone_Error?

I'm not aware of what is typically done in such areas. I would
suspect that each differing opinion has its own locale, and the
computer will be configured to use one locale or the other.

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

Well I don't think it's a mess. You can convert to UTC or any other
timezone very easily by changing the offset. Most internet
communication deals in dates via a UTC offset (typically
in the form +/-HHMM but it's easy to convert from that to
+/-minutes). I can say that dealing with date stamps in the
Basil project would have been *far* more difficult using Ada 95
dates, which are ignorant of differing timezones.

Re: Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

On Mon, 4 Aug 2008 06:56:56 -0700 (PDT), google1@hafdconsulting.com wrote:

> On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> Does anybody know the meaning of the result returned by UTC_Time_Offset? RM
>> says:
>>
>>    "Returns, as a number of minutes, the difference between the
>> implementation-defined time zone of Calendar, and UTC time, at the time
>> Date."
>>
>> This is ill-defined. Political time has overlapping intervals in presence
>> of daylight saving time, when the clock is adjusted backwards.
> 
> That definition accounts for DST shifts. It says "at the time
> Date," which means that if the date falls into a period where
> the locale is in a DST shift, it will return the DST offset.
> Otherwise, it will return the ST offset.

Consider 1 Oct, 00:30 on the clock. Is it 30 minutes *after* the shift
(already ST) or 30 minutes *before* the shift (still DST)?

> Well I don't think it's a mess. You can convert to UTC or any other
> timezone very easily by changing the offset.

So far, it is unclear how to do this. The same problem has
Ada.Calendar.Arithmetic. When Difference is calculated between two dates
within the overlapping hour there are two results.

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

Re: Ada.Calendar.Time_Zones

[Maciej Sobczak]

On 4 Sie, 16:57, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> When Difference is calculated between two dates
> within the overlapping hour there are two results.

As long as both are correct, what is the problem? ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Ada.Calendar.Time_Zones

[Randy Brukardt]

"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.

Re: Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

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.

> 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.

--------
* without additional parameters.

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

Re: Ada.Calendar.Time_Zones

[Randy Brukardt]

"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.

Re: Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

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

Re: Ada.Calendar.Time_Zones

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
...
> But all that stuff like Time_Of etc is not really needed with UTC_Time. 
> The
> package should provide Clock, +, -, <, <=, >, >=:

I don't see how that could work. How would you display or create a UTC time? 
I find that most of the time you either want to use one or the other (that 
is, either UTC time or local time) exclusively in a single program. 
Converting to local time wouldn't work since it would change the time zone.

Anyway, we should have this discussion on Ada-Comment, where it will get 
recorded and attached to the eventual AI on the topic.

                                    Randy.

Re: Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
> ...
>> But all that stuff like Time_Of etc is not really needed with UTC_Time. 
>> The package should provide Clock, +, -, <, <=, >, >=:
> 
> I don't see how that could work. How would you display or create a UTC time?

No problem:

   T : Ada.UTC_Time.Time := ...;
   P : Ada.Calendar.Time := To_Calendar_Time (T);

P is the political time corresponding to T, it is well-defined for each T.
P can be used in Ada.Calendar.Split to display T as:

   August 08, 2008 10:18 (Berlin time)

When used in Ada.Calendar.Formatting.Split with

   Time_Zone => UTC_Time_Offset (T)

the display could be:
   
   August 08, 2008 09:18 (UTC time)

Creating UTC time from UTC's Y/M/D/S should go as follows:

   To_UTC_Time  (Ada.Calendar.Formatting.Time_Of (Y/M/D/S, 0), 0);

> Anyway, we should have this discussion on Ada-Comment, where it will get 
> recorded and attached to the eventual AI on the topic.

Has the proposal any chance to made it?

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

Re: Ada.Calendar.Time_Zones

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>> ...
>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>> The package should provide Clock, +, -, <, <=, >, >=:
>>
>> I don't see how that could work. How would you display or create a UTC 
>> time?
>
> No problem:
>
>   T : Ada.UTC_Time.Time := ...;
>   P : Ada.Calendar.Time := To_Calendar_Time (T);
>
> P is the political time corresponding to T, it is well-defined for each T.
> P can be used in Ada.Calendar.Split to display T as:
>
>   August 08, 2008 10:18 (Berlin time)
>
> When used in Ada.Calendar.Formatting.Split with
>
>   Time_Zone => UTC_Time_Offset (T)
>
> the display could be:
>
>   August 08, 2008 09:18 (UTC time)

Sorry, this doesn't make any sense. Your original point, boiled down, is 
that it is never safe to convert from political time to UTC (because of the 
overlaps and holes). But then you go ahead and do exactly that.

You could probably make it work if you somehow required Ada.Calendar.Time to 
store UTC time + a time zone converter (that is, it isn't really political 
time). But that would force a change in representation for most compiler's 
Ada.Calendar.Time type, and most likely an increase in size as well. That 
would really mess up existing programs that store binary representations of 
Time (as Janus/Ada does internally).

In any case, if you were willing to require that, the current specification 
would work just fine for UTC time (because you could always get the UTC time 
directly from the record). In which case there is no problem, so we don't 
need an additional mechanism.

...
>> Anyway, we should have this discussion on Ada-Comment, where it will get
>> recorded and attached to the eventual AI on the topic.
>
> Has the proposal any chance to made it?

I have no idea. I intend to put the mail and question into an AI and thus it 
will be on the agenda in the future. Beyond that I cannot say.

I'm sure this exact proposal has no chance because it doesn't fix anything. 
But a proposal that does fix something may be a different animal.

                                                        Randy.

Re: Ada.Calendar.Time_Zones

[Dmitry A. Kazakov]

On Fri, 8 Aug 2008 21:09:42 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net...
>> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net...
>>> ...
>>>> But all that stuff like Time_Of etc is not really needed with UTC_Time.
>>>> The package should provide Clock, +, -, <, <=, >, >=:
>>>
>>> I don't see how that could work. How would you display or create a UTC 
>>> time?
>>
>> No problem:
>>
>>   T : Ada.UTC_Time.Time := ...;
>>   P : Ada.Calendar.Time := To_Calendar_Time (T);
>>
>> P is the political time corresponding to T, it is well-defined for each T.
>> P can be used in Ada.Calendar.Split to display T as:
>>
>>   August 08, 2008 10:18 (Berlin time)
>>
>> When used in Ada.Calendar.Formatting.Split with
>>
>>   Time_Zone => UTC_Time_Offset (T)
>>
>> the display could be:
>>
>>   August 08, 2008 09:18 (UTC time)
> 
> Sorry, this doesn't make any sense. Your original point, boiled down, is 
> that it is never safe to convert from political time to UTC (because of the 
> overlaps and holes). But then you go ahead and do exactly that.

It is safe in this case because it uses an external zone offset. The
conversion is unsafe when an attempt is made to determine the offset from
the political time itself. That is inconsistent. But when the offset is
determined by the UTC time, then everything is fine.

> In any case, if you were willing to require that, the current specification 
> would work just fine for UTC time (because you could always get the UTC time 
> directly from the record). In which case there is no problem, so we don't 
> need an additional mechanism.

Yes, this is what GNAT does, at least under Windows.

My proposal would allow to have Ada.Calendar.Time really skewed as
politicians always whished (:-)). E.g.

   T : Time := Time_Of (2008, 10, 28, 1.5*3600.0);  -- 1h before the skew

then

   T1 := T + 1.0*3600.0;   -- 28.10.2008 02:30 before skew
   T2 := T + 2.0*3600.0;   -- 28.10.2008 02:30 after skew

   T1 = T2  -- Political arithmetic!

A time defined this way will still be convertible forth and back to UTC
time, if you know the time offset. That is 1h for T1 and 2h for T2.

-----------
But in any case, RM should clarify what it means under political time. I.e.
whether T1 = T2 (= truly political time), or not (= hidden UTC time).

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

Re: Ada.Calendar.Time_Zones

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:18iqoye18iuzu$.jz3bz3dssmhe.dlg@40tude.net...
...
> But in any case, RM should clarify what it means under political time. 
> I.e.
> whether T1 = T2 (= truly political time), or not (= hidden UTC time).

We purposely did not answer that question, because compilers do not agree 
and the only way to get any agreement at all was to leave it unsatisfied. 
Most of the compilers do the former (Janus/Ada certainly does), but there 
was a vocal minority that wanted the latter be supported.

You should add this question to the Ada-Comment thread (with an appropriate 
example), so we can have that fight all over again. It's important that you 
have shown that it may have semantic effects (we were convinced it did not, 
so we decided not to answer the question).

                                     Randy.