Sam writes:
> > > could you please add internal_time_to_universal_time?
> > > or, more precisely, a new type universal_time (== FILETIME on win32),
> > > and universal_time_to_I().
>
> the precise definition of universal_time and universal_time_to_I can be
> platform-dependent. universal_time_to_I does not have to be 1-1.
> (and it should return a valid Lisp universal time).
It seems to me all you want is a function which converts a FILETIME to
a universal-time Lisp integer without going through
encode-universal-time (on platforms where possible). Such a function
now exists.
Bruno

> * In message <14886.23159.419407.965793@...>
> * On the subject of "Re: internal_time_to_I"
> * Sent on Thu, 30 Nov 2000 14:47:35 +0100 (CET)
> * Honorable Bruno Haible <haible@...> writes:
>
> Sam writes:
>
> > could you please add internal_time_to_universal_time?
> > or, more precisely, a new type universal_time (== FILETIME on win32),
> > and universal_time_to_I().
>
> What unit (resolution) shall it have? If it has 1 sec resolution, it
> is not FILETIME. If it has sub-second resolution, then 1. the
> universal_time_to_I() function would return bignums, which should be
> avoided, and 2. callers of the function would need to know the number
> of units per second. Same as 'internal-time-units-per-second'?
the precise definition of universal_time and universal_time_to_I can be
platform-dependent. universal_time_to_I does not have to be 1-1.
(and it should return a valid Lisp universal time).
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel&gt;
In every non-trivial program there is at least one bug.

Sam writes:
> could you please add internal_time_to_universal_time?
> or, more precisely, a new type universal_time (== FILETIME on win32),
> and universal_time_to_I().
What unit (resolution) shall it have? If it has 1 sec resolution, it
is not FILETIME. If it has sub-second resolution, then 1. the
universal_time_to_I() function would return bignums, which should be
avoided, and 2. callers of the function would need to know the number
of units per second. Same as 'internal-time-units-per-second'?
> > (In mathematical words that you understand: internal_time values are
> > living in a projective space, not in an affine space. :-) )
>
> you mean "in an affine space, not a vector space". :-)
Right :-) There were times when I was better at math than today.
Bruno

> * In message <14885.33979.48092.170472@...>
> * On the subject of "Re: internal_time_to_I"
> * Sent on Wed, 29 Nov 2000 23:35:39 +0100 (CET)
> * Honorable Bruno Haible <haible@...> writes:
>
> Sam writes:
>
> > on win32, `internal_time_to_I' returns the number of seconds since
> > 1600-01-01, not 1900-01-01, as it should.
>
> internal_time_to_I only converts. Also note that internal_time_to_I is
> in the section about "Measuring time consumption". You are always
> expected to subtract two internal_time values (or two
> internal_time_to_I results).
okay, so this is an "internal real time".
could you please add internal_time_to_universal_time?
or, more precisely, a new type universal_time (== FILETIME on win32),
and universal_time_to_I().
> (In mathematical words that you understand: internal_time values are
> living in a projective space, not in an affine space. :-) )
you mean "in an affine space, not a vector space". :-)
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel&gt;
When C++ is your hammer, everything looks like a thumb.

Sam writes:
> on win32, `internal_time_to_I' returns the number of seconds since
> 1600-01-01, not 1900-01-01, as it should.
internal_time_to_I only converts. Also note that internal_time_to_I is
in the section about "Measuring time consumption". You are always
expected to subtract two internal_time values (or two
internal_time_to_I results). (In mathematical words that you
understand: internal_time values are living in a projective space, not
in an affine space. :-) )
Bruno