FILETIME <-> Ada.Real_Time.Time conversions 
Author Message
 FILETIME <-> Ada.Real_Time.Time conversions

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.



Sat, 05 Jun 2004 20:53:38 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
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  
   );  

Quote:

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



Sun, 06 Jun 2004 17:02:39 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
On Wed, 19 Dec 2001 10:02:39 +0100, Alfred Hilscher

Quote:

>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



Sun, 06 Jun 2004 21:37:28 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
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



[snip]

Quote:

> 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



Sun, 06 Jun 2004 23:06:18 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions

Quote:

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



Mon, 07 Jun 2004 19:27:33 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
On Wed, 19 Dec 2001 15:06:18 GMT, "Steve Doiel"

Quote:

>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



Mon, 07 Jun 2004 23:10:46 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions

Quote:
> >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



Tue, 08 Jun 2004 11:13:37 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
Quote:
> 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.


Tue, 08 Jun 2004 14:17:17 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions

Quote:

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



Tue, 08 Jun 2004 16:51:09 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
On Fri, 21 Dec 2001 03:13:37 GMT, "Steve Doiel"

Quote:

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

Quote:
>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?

Quote:
>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


Tue, 08 Jun 2004 18:26:02 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions

Quote:
> >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

Quote:
> >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



Wed, 09 Jun 2004 00:18:06 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
Quote:
> 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.

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


Wed, 09 Jun 2004 02:17:17 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions

Quote:

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

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

Quote:
>>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



Fri, 11 Jun 2004 23:59:00 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
On Fri, 21 Dec 2001 16:18:06 GMT, "Steve Doiel"

Quote:

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

Quote:
>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



Sat, 12 Jun 2004 02:02:07 GMT  
 FILETIME <-> Ada.Real_Time.Time conversions
Quote:
>>>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
Quote:
> 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
Quote:
>without knowing the computer location and local rules regarding time faking

Sounds impossible to me.


Sat, 12 Jun 2004 02:21:36 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ><><><><>Heeeeeeeeeeeeeeelp on INT 14!><><><><><>

2. <<<<<YOU MUST CHECK THIS OUT >>>>>>>>>> 2103

3. >>>>> ADA PROGRAMMERS NEEDED, GOOD PAY <<<<<

4. <><><> FLOODFILL <><><>

5. Handling Ada Task <<Help>>

6. >>>>> ADA PROGRAMMERS NEEDED <<<<

7. >>>>> ADA/COBOL PROGRAMMERS NEEDED <<<<

8. >>>HELP, DECOMPILER<<<

9. <<<XXX Password>>>

10. >>>>>>>>>>>>>>>>>>>HEY!<<<<<<<<<<<<<<<<<<<<<<<

11. <<<XXX Password>>>

12. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

 

 
Powered by phpBB® Forum Software