[LEAPSECS] Lets get REAL about time.

Poul-Henning Kamp phk at phk.freebsd.dk
Sat Jan 21 10:54:24 EST 2012

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.

More information about the LEAPSECS mailing list