FILETIME <-> Ada.Real_Time.Time conversions

FILETIME <-> Ada.Real_Time.Time conversions

[Dmitry A. Kazakov]

Hi!

Is there a portable non-statistical way to implement FILETIME* (or any
other absolute time) <-> Ada.Real_Time.Time conversions?

Regards,
Dmitry Kazakov

* FILETIME (Win32) is 100-nanosecond count (64-bit) since January 1,
1601.

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

[Alfred Hilscher]

On WinXX I would first convert FileTime to SystemTime (which is more
appropriate).

BOOL FileTimeToSystemTime(

    CONST FILETIME *  lpFileTime,	// pointer to file time to convert 
    LPSYSTEMTIME  lpSystemTime 	// pointer to structure to receive
system time  
   );	


"Dmitry A. Kazakov" wrote:
> 
> Hi!
> 
> Is there a portable non-statistical way to implement FILETIME* (or any
> other absolute time) <-> Ada.Real_Time.Time conversions?
> 
> Regards,
> Dmitry Kazakov
> 
> * FILETIME (Win32) is 100-nanosecond count (64-bit) since January 1,
> 1601.

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

[Dmitry A. Kazakov]

On Wed, 19 Dec 2001 10:02:39 +0100, Alfred Hilscher
<Alfred.Hilscher@icn.siemens.de> wrote:

>On WinXX I would first convert FileTime to SystemTime (which is more
>appropriate).
>
>BOOL FileTimeToSystemTime(
>
>    CONST FILETIME *  lpFileTime,	// pointer to file time to convert 
>    LPSYSTEMTIME  lpSystemTime 	// pointer to structure to receive
>system time  
>   );	

Actually FILETIME [UTC] format is used in a communication protocol to
represent time-stamps. Win32 SYSTEMTIME is rougly same though with
great precision loss, because its resolution is 1ms.

It seems that under Win32 there is no way to convert FILETIME to the
high-resolution monotonic time (performance counters) . Therefore a
complicated statistical algorithm was implemented to convert FILETIME
to performance counters (in C++). This way is well possible, but time
consuming, unreliable and of course depends on Win32 API.

Presently parts of the system are under implementation in Ada 95 *not*
under Win32. There is no designated platform. It should be portable.
So the question reappears. It is relatively easy to convert FILETIME
to Ada.Calendar.Time provided that Ada.Calendar.Split and Time_Of are
dealing with UTC [??]. Yet there is a hint in Ada Rationale that
Ada.Calendar.Time might suffer jumps because of daylight savings
[shudder]. At the same time, it seems that Ada.Real_Time.Time was very
carefully designed to prevent any attempt to correlate it with any
external clock [??]. So the problem.

Regards,
Dmitry Kazakov

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

[Steve Doiel]

I chose the same format for sending our time stamps across a network to
various machines.  Currently these values are only decoded on Win32 PC's.

It may be useful for you to know that VAX ELN (maybe VMS as well?) uses a
similar time stamp.  The only difference is the time and date corresponding
to zero.

Also note: it may not be possible (read probably isn't) to represent all
values of FILETIME as a Ada.Real_Time.Time value since the size of the
values may differ.  As I recall the resolution of time in Ada.Real_Time is
not specified, but a minimum resolution and range is.

SteveD

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3c208dc5.16968437@News.CIS.DFN.DE...
[snip]
>
> Presently parts of the system are under implementation in Ada 95 *not*
> under Win32. There is no designated platform. It should be portable.
> So the question reappears. It is relatively easy to convert FILETIME
> to Ada.Calendar.Time provided that Ada.Calendar.Split and Time_Of are
> dealing with UTC [??]. Yet there is a hint in Ada Rationale that
> Ada.Calendar.Time might suffer jumps because of daylight savings
> [shudder]. At the same time, it seems that Ada.Real_Time.Time was very
> carefully designed to prevent any attempt to correlate it with any
> external clock [??]. So the problem.
>
> Regards,
> Dmitry Kazakov

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

[M. A. Alves]

On Wed, 19 Dec 2001, Steve Doiel wrote:
> . . . it may not be possible (read probably isn't) to represent all
> values of FILETIME as a Ada.Real_Time.Time . . .

Indeed:

         | Range                               | Delta              |
         |-------------------------------------|--------------------|
FILETIME | 1600-01-01 .. (very distant future) | 100 nanoseconds    |
Ada Time | 1901-01-01 .. 2100-12-2099          | 20 miliseconds (*) |

(*) "Shall" spec. "Should" is 100 microseconds.

It definitely not possible to timestamp medieval objects with Ada Time ;-)

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

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

[Dmitry A. Kazakov]

On Wed, 19 Dec 2001 15:06:18 GMT, "Steve Doiel"
<nospam_steved94@attbi.com> wrote:

>I chose the same format for sending our time stamps across a network to
>various machines.  Currently these values are only decoded on Win32 PC's.
>
>It may be useful for you to know that VAX ELN (maybe VMS as well?) uses a
>similar time stamp.  The only difference is the time and date corresponding
>to zero.
>
>Also note: it may not be possible (read probably isn't) to represent all
>values of FILETIME as a Ada.Real_Time.Time value since the size of the
>values may differ.  As I recall the resolution of time in Ada.Real_Time is
>not specified, but a minimum resolution and range is.

We can definitely live with smaller range and/or precision. The real
problem is that there is no correlation between epoch of
Ada.Real_Time.Split and UTC.

Regards,
Dmitry Kazakov

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

[Steve Doiel]

> >Also note: it may not be possible (read probably isn't) to represent all
> >values of FILETIME as a Ada.Real_Time.Time value since the size of the
> >values may differ.  As I recall the resolution of time in Ada.Real_Time
is
> >not specified, but a minimum resolution and range is.
>
> We can definitely live with smaller range and/or precision. The real
> problem is that there is no correlation between epoch of
> Ada.Real_Time.Split and UTC.
>
> Regards,
> Dmitry Kazakov

Have you considered defining your own epoch in terms of both times?

You can determine the FILETIME value for your epoch using
SystemTimeToFileTime.  I'll call this file_time_epoch.  You only have to do
this once, then you can define the value as a program constant.

You can determine the Real_Time.Time value for your epoch using
Ada.Calendar.Time_Of.  I'll call this real_time_epoch.

To obtain a Real_Time.Time value from a subsequent FILETIME values use:

  real_time_value := real_time_epoch
                              + Ada.Real_Time.Nanoseconds( Integer(
file_time_value - file_time_epoch ) );

I'm sure you'll have to mess with the types to get things working, but I
think this will get you there.

SteveD

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

[Dmitry A. Kazakov]

On Fri, 21 Dec 2001 03:13:37 GMT, "Steve Doiel"
<nospam_steved94@attbi.com> wrote:

>> >Also note: it may not be possible (read probably isn't) to represent all
>> >values of FILETIME as a Ada.Real_Time.Time value since the size of the
>> >values may differ.  As I recall the resolution of time in Ada.Real_Time
>is
>> >not specified, but a minimum resolution and range is.
>>
>> We can definitely live with smaller range and/or precision. The real
>> problem is that there is no correlation between epoch of
>> Ada.Real_Time.Split and UTC.
>>
>> Regards,
>> Dmitry Kazakov
>
>Have you considered defining your own epoch in terms of both times?
>
>You can determine the FILETIME value for your epoch using
>SystemTimeToFileTime.  I'll call this file_time_epoch.  You only have to do
>this once, then you can define the value as a program constant.

Yes, I already did it (:-)):

type FILETIME is new Interfaces.Unsigned_64;
Ticks_Of_1_Jan_2001 : constant FILETIME := 12622780800;

The rest is easy:

Ticks_Per_Second  : constant Float := 10_000_000.0;
Time_Of_1_Jan_2001 : constant Ada.Calendar.Time  :=
   Time_Of (2001, 1, 1);

function From_FILETIME (Time : FILETIME)
   return Ada.Calendar.Time
is
   Seconds : Float;
begin
   if Time > Ticks_Of_1_Jan_2001 then
      Seconds :=
         Float (Time - Ticks_Of_1_Jan_2001) / Ticks_Per_Second;
   else
      Seconds :=
        -Float (Ticks_Of_1_Jan_2001 - Time) / Ticks_Per_Second;
   end if;
   return Time_Of_1_Jan_2001 + Duration (Seconds);
exception
   when Constraint_Error =>
      raise Time_Error;
end From_FILETIME;

>You can determine the Real_Time.Time value for your epoch using
>Ada.Calendar.Time_Of.  I'll call this real_time_epoch.

How do I convert Ada.Calendar.Time to Ada.Real_Time.Time?

>To obtain a Real_Time.Time value from a subsequent FILETIME values use:
>
>  real_time_value := real_time_epoch
>                              + Ada.Real_Time.Nanoseconds( Integer(
>file_time_value - file_time_epoch ) );
>
>I'm sure you'll have to mess with the types to get things working, but I
>think this will get you there.

Regards,
Dmitry Kazakov

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

[Steve Doiel]

> >You can determine the Real_Time.Time value for your epoch using
> >Ada.Calendar.Time_Of.  I'll call this real_time_epoch.
>
> How do I convert Ada.Calendar.Time to Ada.Real_Time.Time?
>

In LRM D.8.18 (Ada.Real_Time) the definition of the type Time refers to 9.6
(Ada.Calendar).

I'm not sure whether this means that values of the two Time values
correlate, but the first time I read the clause I thought it did.  I know
you cannot directly convert from one to the other, but you may be able to
use Unchecked_Conversion.

Perhaps a language lawyer could provide a better answer here?

SteveD


> >To obtain a Real_Time.Time value from a subsequent FILETIME values use:
> >
> >  real_time_value := real_time_epoch
> >                              + Ada.Real_Time.Nanoseconds( Integer(
> >file_time_value - file_time_epoch ) );
> >
> >I'm sure you'll have to mess with the types to get things working, but I
> >think this will get you there.
>
> Regards,
> Dmitry Kazakov

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

[Dmitry A. Kazakov]

On Fri, 21 Dec 2001 16:18:06 GMT, "Steve Doiel"
<nospam_steved94@attbi.com> wrote:

>> >You can determine the Real_Time.Time value for your epoch using
>> >Ada.Calendar.Time_Of.  I'll call this real_time_epoch.
>>
>> How do I convert Ada.Calendar.Time to Ada.Real_Time.Time?
>
>In LRM D.8.18 (Ada.Real_Time) the definition of the type Time refers to 9.6
>(Ada.Calendar).
>
>I'm not sure whether this means that values of the two Time values
>correlate, but the first time I read the clause I thought it did.  I know
>you cannot directly convert from one to the other, but you may be able to
>use Unchecked_Conversion.

Wow! It really works at least with GNAT. What a wonderful idea. Many
thanks!

The last problem is that Ada.Calendar.Time is a political time, so I
must somehow get rid of time zone.

>Perhaps a language lawyer could provide a better answer here?

Actually the issue belongs rather to the Annex E than to D, but I
found no word there.

Regards,
Dmitry Kazakov

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

[tmoran]

> The real problem is that there is no correlation between epoch
> of Ada.Real_Time.Split and UTC.
  As I understand it, Ada.Real_Time basically tells you the
state of an increasing counter in your computer's hardware,
while UTC has to do with the position of the earth relative to
the sun.  A computer in a rocket passing Pluto cares about the
former, but not the latter, while a computer controlling
dropping the Times Square ball at New Year's Midnight cares
about UTC but not about its hardware counters.  Consider it
amazing that they correlate as highly as they do.

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

[Dmitry A. Kazakov]

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

>> The real problem is that there is no correlation between epoch
>> of Ada.Real_Time.Split and UTC.
>  As I understand it, Ada.Real_Time basically tells you the
>state of an increasing counter in your computer's hardware,
>while UTC has to do with the position of the earth relative to
>the sun.  A computer in a rocket passing Pluto cares about the
>former, but not the latter, while a computer controlling
>dropping the Times Square ball at New Year's Midnight cares
>about UTC but not about its hardware counters.  Consider it
>amazing that they correlate as highly as they do.

Well, provided that the rocket has not yet reached sublight speed
(:-)) both UTC and hardware counter ticks are well correlated.

The problem is that. There are many computers (on Earth, which
relative velocities are near to zero (:-)), exchanging time-stamped
data. Any computer may have its own time synchronization source
(atomic clock, GPS etc). It is clear that the time stamps shall be in
UTC. Which time type in Ada 95 should represent the time stamps?

Ada.Calendar.Time is of no use, because it might be a political time.
Ada.Real_Time.Time is well correlated with UTC, but there is no way to
convert one to other.

Regards,
Dmitry Kazakov

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

[tmoran]

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

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

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

[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

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

[tmoran]

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

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

[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