[LEAPSECS] Argument for rubber seconds (was Hetzner mail to customers)

[Michael Spacefalcon]

Warner Losh <imp at bsdimp.com> wrote:


> No, what ntp and posix try to do, but fail, is conform to the UTC standard,

> which says that the extra second exists and you have to cope with it.


In that case I am right in my assertion that UNIX and POSIX time are
*not* the same: whereas POSIX time is damaged by the spec's invokation
of the cursed letters "UTC", the original UNIX version is free from
that damage, as one can simply run on GMT (local best guess of) and
ignore UTC altogether.  No leap second issues then.


> Also, controlling skyward pointing things need to not be on a

> rubberized scale.


That makes no sense.  Mechanisms that control skyward pointing things
most certainly need their time input to be a real number or something
that is directly convertible to one.  A struct {int hh, mm, ss} set to
{23, 59, 60} would be useless to a system whose actual need is
something like UT1.  UT1 is a *real number* scale, it does *not* have
leap seconds, and it *is* rubbery with respect to TT.


> In some ways, the marketplace of ideas has spoke: we don't care about leap

> seconds, please don't inflict them on us.


YOU don't care about keeping your social time in tight sync with MST.
But I do, i.e., I insist on keeping *my* social time in such a tight
sync with MST.

Furthermore, it is not only my personal social time that is at stake
here, the other thing is the system time maintained by computer
systems under my care.  Because my version of UNIX rejects POSIX (uses
bcopy instead of memcpy, index instead of strchr, sgtty instead of
termios, sigvec instead of sigaction, etc), my time_t is defined to be
GMT, not UTC.  For now I can use UTC as a satisfactory realization of
GMT, but *only for as long as UTC continues to have leap seconds*.  If
UTC undergoes a deleterious redefinition, I'll have to scramble to
build my rubber duckie apparatus that would generate my proposed
alternate UTR time scale.

Gerard Ashton <ashtongj at comcast.net> wrote:


> Michael Spacefalcon gave an overview of how a high precision system (which

> he incorrectly supposed I possessed or ran)


If you run GNU/Linux or some flavor of "modern Unix" with standard
ntpd, your time precision is greater than mine.


> But if a rubber time scale ever became law, high precision

> systems might have to interface with each other indirectly through the

> rubber time scale because of legal requirements.


Yes, almost certainly.  However, if the rubberization is defined
properly and precisely as a trivially invertible linear function (such
as the UTC-SLS proposal), no fundamental problem will exist.  Suppose
high-precision system A desires to communicate a precise TAI-style
timestamp to high-precision system B, but is constrained by standards
to do so through a rubbery civil time interface.  No problem: A
converts its internal TAI-style timestamp T into its UTR/UTC-SLS
equivalent R (trivial linear function), then upon receiving that R,
system B applies the inverse linear function and gets the original T
back, *exactly*.  Problem solved.


> This would cause the

> interface systems to operate a little differently near leap seconds than

> they usually do,


A little differently, but still provably correctly.


> so there would be a potential for flaws to crop up.


You make a bug in your code, you fix it.


> History suggests these interfaces will not be tested frequently enough.


Clearly the proper solution is to *tighten* the DUT1 tolerance instead
of loosening it, so that the leaps or rubberizations will happen more
frequently and hence become accepted as the norm.

I've been toying with the idea of making my UTR time scale follow IERS
Bulletin D instead of C: it's just as well-defined in that the time
step is declared unambiguously and announced in advance, I could
easily update utrdef.txt on the master UTR server within a day or two
of Daniel Gambis emailing out Bulletin D, UTR would then stay within
0.1 s of UT1 rather than mere 1 s, and rubberizations would happen
every year, often 2-3 times per year, rather than once in a few years.

Clive D.W. Feather <clive at davros.org> wrote:


> So do civil speed limits change from 70 mph to 70.07 mph during that

> period?


The first countries to implement the kind of time standard that I
propose will most likely be ones that don't have any speed limits at
all, countries like the Principality of Sealand.

As to the nasty countries that do have speed limits, how did they
handle this issue prior to the invention of atomic clocks?  Going back
to that method would be one simple solution.


> Just how much of our infrastructure currently depends on the

> assumption that the civil second is the SI second?


Nothing that I care about - if it breaks, good riddance.


> Besides which, you still haven't solved the problem - distribution of the

> leap information is still a hassle


In my solution it wouldn't be a hassle at all.  My rubber duckie will
send out UTR information in the form of the following structure in UDP
packets:

struct utr_dissemination {
	uint64_t current_time;		/* seconds since some TBD epoch */
	uint32_t current_fraction;	/* fraction of current UTR second */
					/* in SI nanoseconds */
	uint64_t rubber_start;		/* starting time of the current or */
					/* upcoming rubberization */
	uint32_t rubber_numsecs;	/* length of the rubberization in */
					/* UTR seconds */
	uint16_t rubber_seclen;		/* length of the rubberized seconds */
					/* in SI milliseconds */
};

The rubberization described by the last 3 fields MUST be either
currently in progress or upcoming (relative to the current_time
field), but not in the past.  Hence 3 possibilities exist:

* current_time >= rubber_start: a rubberization is currently in
  progress.  (current_time - rubber_start) MUST be less than
  rubber_numsecs.  current_fraction (counting SI nanoseconds) is in
  the range [0, rubber_seclen * 1000000).

* current_time < rubber_start: the sender of the packet is warning the
  recipient about an upcoming rubberization.  However, that
  rubberization hasn't started yet, and current_fraction is in the
  range [0, 1000000000).

* If no rubberization is currently in the progress, and the next one
  hasn't been scheduled yet, all 3 rubber fields are set to 0.

This rubber time dissemination structure is a compromise between the
needs of low- and medium-precision timekeeping systems.  (Super-high-
precision timekeeping systems would be better off by running their
main clock on a TAI-style timescale, disseminated via a protocol
specifically designed with the magic letters "TAI" instead of "UT*",
such as djb's TAICLOCK protocol on UDP port 4014, and synthesizing
their own UTR locally as needed at the point of human time display.)

A low-precision timekeeping system that simply desires an
instantaneous reading of a GMT-like continuous, scalar and monotonic
timescale, but does not care about the rate at which this timescale
will evolve over the ensuing nanoseconds, can get a real number time
reading out of the above UTRDP packet as follows:

double current_gmt_instant(utr)
	struct utr_dissemination *utr;
{
	int ms_per_sec;

	if (utr->current_time >= utr->rubber_start)
		ms_per_sec = utr->rubber_seclen;
	else
		ms_per_sec = 1000;
	return (double)utr->current_time
		+ (double)utr->current_fraction / (ms_per_sec * 1000000L);
}

The trivial algorithm above is all that a low-precision system would
need to know about rubberizations.  A higher-precision system that
would like to know exactly how rubber time maps to SI interval time
can get all the necessary information by taking note of the upcoming
rubberizations: their start time, duration and temporary second
length.


> and handling of the event isn't properly

> tested.


It would get tested plenty enough if the DUT1 tolerance is set tight
enough to make the rubberizations happen frequently.

Tony Finch <dot at dotat.at> wrote:


> How about IERS Buletin A?


In my opinion, the Bulletin D version of [D]UT1 is much better suited
for use as a civil time scale than the Bulletin A/B version.

SF