[LEAPSECS] Lets get REAL about time.

[Mark Calabretta]

On Fri 2012/01/20 11:29:18 -0000, "Poul-Henning Kamp" wrote
in a message to: Leap Second Discussion List <leapsecs at leapsecond.com>


>I would like your comments on this API proposal, if we can agree

>that it workable, I am willing to push it, hard, in the UNIX world.


This ticks all the right boxes for me.  Specific comments below.


>	#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.  The 'do  { ... } while (0)'
kludge is at least as ugly as its contents which I imagine would have
parallels in FPU microcode.


>We could invent a new data type, "int80_t" or something, but that

>would be a lot of work, so let us just bite the bullet and use one

>we already have:  IEEE binary128 floatingpoint, also known as

>quardruple-precision floating point.


The conclusion that 64 bits is not enough but 128 bits will be is
easy to accept, and I agree with avoiding anything in between.

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?
en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Implementations


>Next comes the question what we do about leap-seconds, and there

>is only one answer that works in practice:  We make them a

>representation issue.


Great!


>Our new timecale should run on the TAI timescale which does not

>have leap-seconds or any other artifacts, and library functions can

>convert that to UTC time, civil time etc, using a leap-second table

>which can be updated as and when leap-seconds gets announced.


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


>Here is my proposed api:

>

>]] typedef $compiler_magic realtime_t;

>

>A IEEE binary128 number containing time on the TAI timescale

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

>epoch is not imporant, but it is a good idea to make it different

>from all other currently used epochs, to make programmer mistakes

>clearly visible.


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.


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


I suggest calling it something other than tai_time() as it will
probably upset some people.


>]] double	tm_frac;	/* fractional second [0...1[ */

>

>We treat UTC as another case of the larger class of civil timezones.


This now starts to overlap with Steve's TZ proposal which, in some
sense, this proposal would serve to legitimize.  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,
particularly those associated with heterogeneous computing
environments - i.e. where you have a mix of machines on a network
sharing files, etc., some running time_t and some running realtime_t.
I think that aspect needs to be thought out.

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.

Regards, Mark