[LEAPSECS] Lets get REAL about time.

[Michael Deckers]

   On 2012-01-21 12:31, Poul-Henning Kamp wrote in reply to
   comments on his proposal for time_t as 128 bit binary float:


> First of all, I'm not particular wild about floating point numbers,

> but the fact of the matter is that:

>

> A:  Time is measured in seconds, with a fractional part.

> B:  We want a datatype which supports normal sums and differences.

>

> Both of which point to a floating point format, where operations

> will naturally do what people expect from them.


  And there is prior art: in the Apple Mac OSX operating system,
  the system call
        CFAbsoluteTimeGetCurrent()
  returns time as seconds since 2001-01-01 as a double value.

  When timestamps of computer operating systems are used
  to represent the physical time (of the call), a floating
  point representation is a good choice, so I do not want
  to argue against it. I just think that the additive
  structure of IEEE float values is much more involved
  than the additive structure of timespec and timeval.

  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.
  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.
  A temporary switch in these settings may be needed.

  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.
  Comparing IEEE floating point values holds its surprises
  because values may be incomparable, or can compare equal
  and still be distinct, and the conversion to and from a
  decimal notation of a binary floating point value is no
  easy matter if it is supposed to strictly preserve order.

  Michael Deckers.