[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <20120121215737.GA17848 at lake.fysh.org>, Zefram writes:

>Poul-Henning Kamp wrote:



>struct timeval and struct timespec have an obvious benefit: durations that

>are short decimal fractions of the second can be represented exactly.


The reason for timeval using microseconds has nothing to do with
any kind of high-level thought about APIs etc.

It was quick hack that took a copy of the 1MHz counter on the
platform where the timeval was first introduced in a piece of phd-ware.

I'll leave as an exercise to the archaeologically minded readers to 
to deduce which phd-ware, platform and guilty party.

I think we have established that binary128 can also do that for
all relevant definitions of "exactly", and not only that, it can
be done in the purest terms imaginable in the source code:

	t1 = t0 + 1e-3;	// same place, one millisecond later...


>You want a fixed-point format. [...]


No I don't because there are no standardized fixedpoint formats
wider than 64 bit in existence.

What's worse: There are no fixed-point-with-fraction formats available
at all, so the conversion problems you worry about, would get much
worse, as the above statement becomes totaly unreadable in the
source code:

	t1 = t0 + 18446744073709552ULL;  	// 1 msec later

The aim here is to make it possible to get a correct answer to
the question "What time is it" and to make it as hard as possible
for clueless programmers to get timekeeping wrong.


>I think this API should be specified so that realtime_t can be an

>arithmetic type where the compiler supports it, and can be a struct (of

>two 64-bit ints) where necessary.


Then we might as well have two different and incompatible APIs, and
we all knows what kind of stuff that leads to:

https://www.varnish-cache.org/docs/2.1/phk/autocrap.html

No, I want _one_ API, and I want it to be done right so we don't
have to mess with it again in my lifetime.


>>If the error parameter is NULL, and the one sigma error estimate

>>is larger than 0.1 second, the call returns a negative number and

>>sets errno to EACCESS.

>

>I'm uncomfortable about the arbitrary number.  I think this semantic

>would be better as a separate function where one passes in a maximum

>acceptable error.


No, I want to have a well defined, bound of tolerance to make it
easy to do the right thing.  We can argue if the correct tolerance
is 0.1 or 1.0 second, but it isn't larger.


>>This call returns a monotonically increasing estimate of elapsed

>>time in SI seconds, since the program started.

>

>Elapsed in which reference frame?


In what ever reference frame the program is executed, for what
ever we mean by "executed".

The level of trouble you get into in relativistic situations
will require not a realtime_t but a realspace_t type, and I'm
not going to even attempt to define an API for that.

I do appreciate the fine points you are trying to drag out here,
but I think we are waaaaaay into discussing deck-chair arrangement
here, and I'd really prefer to focus on the iceberg.


>>The timestamp is outside the valid range of translation tables

>>available to the program (errno = E2BIG)

>

>Should be EDOM, for domain error.


Works for me.


>So be aware that the `timezone' mechanism will have to be a bit more

>sophisticated than the current Olson system.


That is outside the scope of this API:  What other "tz" values are
supported than "UTC" (and possibly "TAI") is an implmentation
issue. 

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