Re: FILETIME <-> Ada.Real_Time.Time conversions

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On Fri, 21 Dec 2001 18:17:17 GMT, tmoran@acm.org wrote:

>> It is clear that the time stamps shall be in UTC.
>Hardly, because
>> Ada.Calendar.Time is of no use, because it might be a political time.
>  If the distributed machines want to know what their compatriots
>think the time is, they need to get synchronized (periodically) and
>then use their change in Ada.Real_Time.Clock to estimate the change
>in other machines' Ada.Real_Time.Clock  UTC time is irrelevant.

Our system allows many different scenarios. One of them is that both
participants have some sort of external clock available. It is also
well possible that they just cannot directly synchronize clocks
because the connection is too bad for this. In the cases like that
there must be an absolute time format for time stamps. UTC is a good
candidate for it. The result of Ada.Real_Time.Split could be also
acceptable *if* the epoch were fixed.

>  You and I could both note what our watches say when the ball
>drops in NY Times Square when they celebrate New Years.  We can
>both agree to do something when our watches say 180 days have passed.
>Neither of us need worry about what the UTC time is when the ball
>drops, or what it is 180 days later.

Yes, now let's imagine that the ball fell 1 Jan 1601 in Greenwich.
That would be UTC. The time base is irrelevant, but it must be one.

>>Ada.Real_Time.Time is well correlated with UTC, but there is no way to
>>convert one to other.
>  Package Ada.Calendar does that all the time.  Inside the computer is
>an electronic counter - an Ada.Real_Time kind of thing.  When you set
>the time on your system, you are telling it that a counter value of
>nnnn corresponds to a time of MM/DD/YY HH:MM:SS.ddd.  Given the
>difference between that and any other counter value, the frequency of
>the counter, and some political information about daylight savings
>time, Ada.Calendar.Split does some divisions and mods by 60, 24, and
>the number of days in various months in various years, and comes up
>with the MM/DD/YY HH:MM:SS.DD corresponding to the new counter value.

This is why Ada.Calendar.Time is of so little use. Its time base
depends on the place on Earth where the computer is currently located.
When Ada.Calendar.Split tells me MM/DD/YY HH:MM:SS.DD I still cannot
use this information without knowing the computer location and local
rules regarding time faking.

Regards,
Dmitry Kazakov