[LEAPSECS] Lets get REAL about time.

[Michael Deckers]

   On 2012-01-21 15:54, Poul-Henning Kamp wrote:


> timeval contains bogus combinations of tv_sec and tv_usec and

> a lot of code does not even notice...


   Yes, in contrast to IEEE binary floating point values where
   each and every bit pattern belongs to one of the classes
   FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, or FP_ZERO.


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


   Yes, a specification had to clarify what the term "valid
   floating point number" means. More to the point: IEEE
   arithmetic adheres to a well-defined (and sophisticated)
   computational model, and I believe users would expect
   that model to be followed if time_t was an IEEE float.

   Case in point: difftime() should react in the standard
   way on arguments that are signalling or quiet NaNs --
   even if the programers don't care or don't know, their
   debuggers may rely on it.

   Of course, you are right that all this can be reasonably
   specified (with some effort). May be this is what BSD
   users REALly want to be in <time.h> (or in <math.h>).
   You probably know best how to find out.


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


   Example questions: does difftime() set the inexact flag?
   does it use the rounding mode in force at the call?
   (People do interval arithmetic by executing their
   algorithm twice with different rounding modes.)

   Michael Deckers.