[LEAPSECS] Lets get REAL about time.
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
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