[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <E1RoR4T-0001yE-4Y at grus.atnf.CSIRO.AU>, Mark Calabretta writes:


>>	#define timespecsub(vvp, uvp)                                   \

>>		do {                                                    \

>>			(vvp)->tv_sec -= (uvp)->tv_sec;                 \

>>			(vvp)->tv_nsec -= (uvp)->tv_nsec;               \

>>			if ((vvp)->tv_nsec < 0) {                       \

>>				(vvp)->tv_sec--;                        \

>>				(vvp)->tv_nsec += 1000000000;           \

>>			}                                               \

>>		} while (0)

>>

>>Lovely, isn't it ?

>

>Unlovely, but not the ugliest, especially considering that there may

>not have been a better way at the time.


That's simply not true, they could have chosen a binary fraction
rather than a decimal one.



>The 'do  { ... } while (0)' kludge is at least as ugly as its contents[...]


The do {...} while(0) is the least ugly way to make function-like CPP
macros safe for below average programmers IMO.


>parallels in FPU microcode.


Average programmers don't get near the FPU microcode, they do have
to handle timevals on a regular basis.


>It's more natural to represent a physical quantity with a floating-

>point number.  However, I would question the current availability of

>IEEE binary128 implementations.  Are you assuming that the lead time

>for this proposal would overlap its wider adoption?


To put it bluntly:  If people/OS's cannot get their shit together and
implement stuff like this, I don't care about them, because they will
be gone in less than five years anyway.

You can still use part of this API by defining an opaque type for
realtime_t, but you don't get the convenience of being able to
subtract them algebraicly, so there is a workaround until you get
your compiler people beaten up.


>... a local approximation of the TAI timescale ...


I assumed that people on this list knew if they were employed at BIPM
or not :-)

yes, just like the UTC is an estimate or approximation.  I don't think
the document becomes significantly clearer by stuffing this into the
text, but an editorial footnote to keep BIPM happy is clearly in order.


>>A IEEE binary128 number containing time on the TAI timescale

>>counted in SI seconds since 2012-01-20 00:00:00 UTC.

>

>Is that your birthday by any chance?!  I guess it's going to be

>a big one in 2026...  I recently turned 20,000 myself.


In fact it is, but it was also the day I wrote the proposal, so
I have credible deniability :-)


>>]] int tai_time(realtime_t *timestamp, double *error);

>

>I suggest calling it something other than tai_time() as it will

>probably upset some people.


Suggestions ?


>However, the Caveats

>at http://www.ucolick.org/~sla/leapsecs/right+gps.html indicate the

>types of problems likely to surface in introducing the scheme,


The major caveat will be to get this API beaten into all relevant
operating systems in a timely fashion, everything else is just minor
matters of decisions to be made.

And yes, there will be transition effects and troubles, but I am not
going to attempt a new API if it doesn't solve the _all_ of the problems
with the current state of affairs.


>The rest of the API looks fine.  I would also put in a request for a

>function that takes a realtime_t and returns the difference TAI-UTC,

>including the rubber-seconds era.


Ohh, absolutely, there needs to be a bunch of well thought out
convenience functions on top of this.

What I focused on here was solving the show-stopper problems:

1. Getting a sensible algebraic representation of time.

2. Getting the uncertainty of the estimate built in.

3. Get leapseconds moved to userland.

4. Getting an error rather than wrong time if leapsecond
   information is not up to date.

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