Re: millisecond time format

[<pl...@pi...>]

On Sat, 23 Feb 2008 00:04:17 +0100, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

>
>> Currently the internal representation of time is an integer number
>> of seconds.
> Not really.  time_t of the Standard C library is an integer, typically
> seconds since 1970-01-01 --- but our own time routines don't use that.
> Instead we use a double to hold seconds since 2000-01-01.


>> So the code can already handle decimal fractions of seconds,

> No.  Nothing in the code is actually prepared to work with fractions of  
> seconds.  Somebody just thought, a >*long* time ago, that the usable  
> range of 32-bit integers was a bit small (viz. the "Y2K37 problem"), and  
> >that most systems' "double" can hold a wider range of integers.


So in effect Ethan was correct. Although stored in a double the value is  
integer and all arithemtic on the value is done as interger and there is  
no support for sub-second resolution in the time formats.

The answer to my original enquiry is "no you can't" and it's all a long  
way off. Shame, you got my hopes up for a minute there. Thanks for  
explaining the state of play.


This does however raise another question in my mind. I am mainly using  
gnuplot in an embedded context using softfloat. If all x coords are  
treated as double (although not using the fractional part) this mean a lot  
of unnecessary float operations at every step of the plot process.

Mightn't it be worthwhile my changing this locally to use integer on an  
integer arch?

Thanks again.

Peter.