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

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

On Mon, 24 Dec 2001 18:21:36 GMT, tmoran@acm.org wrote:

>>>>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
>>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.
>  Ada.Calendar did some transformation on the Ada.Real_Time counter to
>get MM/DD...  and you want to invert that transformation, right?  But
>it sounds to me like you have a computer which has been blindfolded
>and taken to a secret location.  The only information it has is the
>clock on the wall in its cell, and it wants to know what time it is
>in Greenwich, England.  It either must communicate, but
>> cannot directly synchronize clocks because the connection is too bad
>or else it must somehow find out where (what time zone) it's in, but
>>without knowing the computer location and local rules regarding time faking
>Sounds impossible to me.

Imagine board computers of several cars, plus basis stations located
on Northern pole and Moon.

The point is that Ada.Calendar.Time has no sense without some
additional information, which might be (and is) unavailable. Are you
really sure that an implementation of Ada.Calendar can foresee all
bureaucratic fancies all over the world for a some valued period of
time? Consider a consistent implementation of it for the time period
1951..2051.

It is obvious that Ada.Calendar.Time is unusable for time stamps of
any sort. [Of course it does not mean that there should be no
Ada.Calendar.Time] Time stamps must be an absolute time [of the chosen
coordinate system]. Whether it is an astronomical, greenwich or
whatsoever time is no matter, as long the time base is specified.

Regards,
Dmitry Kazakov