[LEAPSECS] Future time

[Michael Spacefalcon]

John Hawkinson <jhawk at MIT.EDU> wrote:


> Suppose a user enters an event in my calendar for 3:00pm US/Eastern on

> August 1, 2014.

>

> Then a leap second happens.

>

> If my calendar software changes my event to start at 2:59:59pm 


Scenarios like the above are precisely the reason why I, Markus Kuhn
and Google Leap Smear users have been telling you all along that is
wrong to use Newtonian/Einsteinian time when the real need is for
*civil* time instead.

We need two entirely separate and mostly-disconnected (see below)
forms of time: N/E interval time on one hand, and "rubbery" civil time
on the other hand.

The problem is in the minds of people like PHK and Warner Losh.  Every
time we (me, Markus Kuhn and others of similar mind) advocate for a
"rubbery" civil time scale with "rubber seconds", we get shot down
with cries of how one can't use rubber time for air traffic control,
etc.  So what you, the "anti-rubber" crowd, are effectively saying is
that "rubbery" civil time is not an acceptable substitute for uniform
interval time.

But we assert the converse as well: uniform interval time is not an
acceptable substitute for rubbery civil time either, at least for
those of us who (for whatever legal, moral, philosophical, religious
or purely personal reasons) wish to retain Earth's rotation as the
fundamental basis of *our* civil time.

If inviduals like PHK and Warner Losh were stripped of their ill-gotten
power to dictate to the rest of the software world their edict of "thou
shalt use uniform interval time whether it's the appropriate timescale
for you or not", then all "leap second problems" would instantly go
away: *civil* time (as opposed to real time) applications would switch
to using something like UTC-SLS or UTR (the former is contingent of
UTC retaining its current leap seconds, but the latter is a variant
without such requirement), whose "second" counts are NOT SI seconds,
but merely measures of the angle by which the hands of an official
civil time clock are turning, and all simple date-time math will work
without burdening all of us with keeping track of leap seconds.

Back to my point about uniform interval time and "rubbery" civil time
being "mostly-disconnected": what I have in mind is a system like
house electrical wiring with separate "ground" and "neutral" wires.
At least here in USA, the electrical codes stipulate that the two be
connected at one common point, but are then wired separately from that
point onward.  "Rubbery" civil time would be algorithmically derived
from uniform interval time (atomic time), via a very simple linear
formula like Markus Kuhn's UTC-SLS (my proposed UTR is essentially the
same thing, but defined in a way that permits it to continue being
maintained independently if UTC-as-we-know-it goes away), and ideally
this algorithmic derivation of "rubbery civil time" from atomic time
would be done at an authoritative source such as a national time lab -
corresponding to the bonding point of "ground" and "neutral" wires in
my electrical analogy.

Continuing the electrical analogy, once a national time lab (it may
have to be the national time lab of a small micronation like Sealand
if no larger nation has the guts to step forward) has produced both
forms of time (pure atomic time and a rubberized civil time, related
by a known formula), both should be disseminated in parallel: for
example, on different UDP port numbers of an NTP-like Internet time
server.  All users would then have ready access to both forms of time,
but unlike in PHK-nian/Warner-Losh-ian world, no person, system or
application would be involuntarily forced to use or care about a form
of time they don't need.  An application that needs interval time only
(some "deeply embedded" technical system with no user interface at all
which doesn't need to know or care what day or time it is in the human
world) will be able to completely ignore the existence of the rubbery
civil time, whereas an application that needs civil time only, like
the OP's Excel example, would only look at the rubber second count and
ignore the SI second count.

Sure, there will be plenty of applications which need both, but once
again, no problem.  Air traffic control is a perfect example: use
interval time internally for everything, but when displaying flight
arrival and departure times for waiting passengers, convert them to
the "rubbery" civil time for display, using the known formula and the
widely-disseminated data table driving the rubberizations.

VLR,
SF