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

[Adam Beneschan <adam@irvine.com>]

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.  You have another value that was returned by Ada.Calendar.Clock at some other point in time T2.  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, and using the "+" functions defined in Ada.Calendar and Ada.Calendar.Formatting, that produces an Ada.Calendar.Time value representing T1 that can correctly be compared with T2 (and subtracted to produce a Duration).

Do you believe my contention is incorrect?  If so, please demonstrate.

It's true, as you say, that UTC_Time_Offset's result isn't constant, and changes when the time zone goes in and out of Daylight Savings Time.  The point is, I was trying to use it in a way that would cancel out the effect of that, producing a result in which the "offsets" factored into the two Ada.Calendar.Time values being compared are the same, which means that you can compare or subtract them correctly, regardless of whether the offsets would be different if you ran the program six months from now.  I may have done it wrong, but I don't believe it is impossible.  If it is, please show why.

There are certainly a lot of things that are difficult to get right with Ada.Calendar for some of the reasons you state.  I don't think any of those are relevant to solving *this* particular problem.  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.

                            -- Adam