[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <4F1ADE6D.8070707 at yahoo.com>, Michael Deckers writes:


>  For one thing, IEEE float values contain infinities and

>  NaNs, and since the POSIX interfaces accept time_t values

>  as inputs, ths system code would have to deal with them.


timeval contains bogus combinations of tv_sec and tv_usec and
a lot of code does not even notice...

I already specified that you get EINVAL if it is not a valid
floating point number.  I may have to be more specific than "valid"
but I really don't see this a problem, considering how trivial
and fast this is to check, compared to the math needed to get
to, for instance UTC.


>  Moreover, IEEE floating point operations depend on certain

>  environmental settings (eg, rounding modes and enabled

>  traps) and it is not clear whether a system call must or

>  can use those of the caller in every circumstance.


I'm not sure I can see how it can become relevant, given
a good quality library implementation.


>  The timestamps of computer operating systems are often

>  used in a way where mainly the sequence of increasing

>  values is important, not so much their absolute value.


That is why I added the "run_time()" version also.


>  Comparing IEEE floating point values holds its surprises

>  because values may be incomparable, 


In which case they are not valid timestamps, and you get
EINVAL if in a library or whatever you asked for in your
own code.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.