At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
>All functions that return time values (seconds since epoch) should use
>floating point numbers to return as much precision as the platform
>supports. All functions that take time values as arguments should
>work for fractional seconds if the platform supports it.
Floats have resolution issues that exacerbate sub-second resolution issues.
Could we consider:
1) Defining it to be a larger integer (64-bit, say)
2) Defining a smaller resolution (ns, 10ns, or 100ns resolution)
3) Changing the base date to something more meaningful? The smithsonian
base date, the astronomical base date, year 0 of the Chinese calendar, or
Larry's birthday, say? Heck, Even Jan 1, 1900 would be better. (Or Jan 1,
2000, I suppose)
4) Allowing negative times
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
- RFC: Higher resolution time values Gisle Aas
- Re: RFC: Higher resolution time values Sam Tregar
- Re: RFC: Higher resolution time values Graham Barr
- Re: RFC: Higher resolution time values Johan Vromans
- Re: RFC: Higher resolution time values Larry Wall
- Ops versus subs (Was: Re: RFC: Higher re... Johan Vromans
- Re: Ops versus subs (Was: Re: RFC: ... Dan Sugalski
- Re: Ops versus subs (Was: Re: R... Johan Vromans
- Re: Ops versus subs (Was: R... Dan Sugalski
- Re: RFC: Higher resolution time values Dan Sugalski
- Re: RFC: Higher resolution time values Nick Ing-Simmons
- Re: RFC: Higher resolution time values Dan Sugalski
- Re: RFC: Higher resolution time values Gisle Aas
- Re: RFC: Higher resolution time values Nick Ing-Simmons
- Re: RFC: Higher resolution time val... Dan Sugalski
- Re: RFC: Higher resolution time... Nick Ing-Simmons
- Re: RFC: Higher resolution ... Dan Sugalski
- Re: RFC: Higher resolution ... David L. Nicol
- Re: RFC: Higher resolution ... Nick Ing-Simmons
- Re: RFC: Higher resolution time values Gisle Aas
