Re: Ada.Calendar and NTP (and Unix Epoch)

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

On Tue, 24 Jul 2012 12:07:52 -0700 (PDT), Adam Beneschan wrote:

> On Tuesday, July 24, 2012 11:28:27 AM UTC-7, Dmitry A. Kazakov wrote:
>> On Tue, 24 Jul 2012 09:26:46 -0700 (PDT), Adam Beneschan wrote:
>> 
>> > Now, use Ada.Calendar.Time_Of to create a Time T_Base representing 1/1/1901. 
>> > Or, better, if the NTP time is always UTC, then you should probably use
>> > Ada.Calendar.Formatting.Time_Of to create a time that represents midnight
>> > of 1/1/1901 in UTC time; I think you do this by passing Time_Zone =>
>> > Ada.Calendar.Time_Zones.UTC_Time_Offset.  (Somebody please correct me if
>> > I'm supposed to negate the value.)
>> 
>> There is no simple way of converting Ada.Calendar.Time to UTC. At least
>> there was none in Ada 2005. I think Randy Brukardt wanted to fix that, or
>> sort of.
> 
> The problem here, I think, is that the concept of "converting
> Ada.Calendar.Time to UTC" is a broad, general one, and probably somewhat
> vague.  I'm not trying to explain how to work with UTC time in general;
> I'm trying to solve a specific problem.
> 
> The specific problem (as I understood it) was this:  You have an integer
> value that represents a specific *point* *in* *time* T1 by specifying the
> number of seconds that have elapsed since midnight on New Years Day in
> Greenwich.

T1 [GMT]

> You have another value that was returned by Ada.Calendar.Clock at some
> other point in time T2.

T2 [nobody knows what]

>  My contention is that you can create an Ada.Calendar.Time value to
> represent T1 by using Ada.Calendar.Formatting.Time_Of with a suitable
> Time_Offset,

The problem is the Time_Offset, where do you get it? You need
GMT_Time_Offset, which firstly is not defined, and secondly if it were
there, it would be no more constant than the UTC_Time_Offset is.

Once you get T1 and T2 to the same time basis of more or less monotonic
time, e.g. GMT, UTC, whatever, but *not* a political time, there will be no
further problems.

> Furthermore, I don't see how Ada.Real_Time is a solution; that package's
> purpose is, I think, to provide a better way to measure time *intervals*
> with a higher resolution, but it doesn't do all that well with absolute
> time (the RM says that Real_Time is considered relative to an undefined
> "epoch" that could be the last system boot time).  So I don't see how it
> could be involved in a solution to this particular problem.

Ada.Real_Time.Time is not a full solution. It only provides sane time
arithmetic, e.g. "+", "-". A numeric type could do this as well.

Ada.Calendar.Time cannot give even that little. You could not define
arithmetical operations on it in any reasonable way. This is of course
because of time skews, which make some values non-existent and some values
repeating. I presume that any Ada implementation of it is broken in this or
other way, which is irrelevant here, because there is no way to have
arithmetic on something that is not additive anyway. I posted a couple
examples for CET on the topic to Ada Comments some time ago.

So the rule is: do not do any computations with Ada.Calendar.Time. Ada RM
simply does not define the outcome.

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