[LEAPSECS] Future time

[Michael Spacefalcon]

Warner Losh <imp at bsdimp.com> wrote:


> Second, you are breaking one of the aspects of time


Wrong - I simply assert other people's right to define the word "time"
in a different way than you do.  There exist perfectly valid definitions
of the word "time" which are distinct from "interval time", and which
are not broken in any slightest way by my approach.


> that is important for some application (you introduce a frequency error).


No, I do not introduce any "frequency error" - I can't, because the
term "frequency" has no defined meaning for the entity called "civil
time".  Instead, *you* introduce that error when and if you *misuse*
what I provide as "civil time" as if it were "interval time", ignoring
the product label that reads "don't do that".

You are seeking to suppress Earth-based civil time because some people
have misused and continue to misuse it in applications for which it is
not appropriate.  Are you also going to ban gasoline, because some
people misuse it for the purpose of committing arson, even though the
instructions on the gas pumps clearly say "for use as motor fuel only"?


> This is no different than repeating a second


There is one fundamental difference which you ignore: the mapping
between UTR (equivalent to UTC-SLS or Google's leap smear) and TAI
timestamps is 1-to-1, invertible, and precisely defined, when both are
treated as real numbers of conceptually infinite precision.

The reason why this bijective mapping is such a big deal is because
(if people on your side of the fence were willing to open their eyes a
little, that is) it would allow your precision real-time applications
to work properly.  Your whole beef with leap seconds seems to revolve
around the notion that you have applications for which uniform "atomic"
time is very important, which *also* need to interface with civil time
(otherwise you could just use something like GPS time and ignore UTC
altogether), and where no errors at all are tolerable, i.e., every
timestamp must be exactly precise, no fudge factor whatsoever.

Well, guess what, my system would allow you to have your cake and eat
it, if you would only look at it with an open mind instead of shooting
it down with prejudice!  The *only* work required on your part would
be to exercise a little care when defining your data structures: any
place where you have a timestamp of any kind, be clear on whether it
is a TAI-style one or a civil time one.  Different data types would
help: time_t is already well-established as the civil time data type,
so use/invent a new one for TAI-style timestamps, like that realtime_t
proposed by your buddy PHK on this list a couple of years ago.

Any time you need to convert from one to the other, call a library
function: the conversion is precisely defined and invertible.  Run
your internal clock on "atomic" time, and synthesize the "rubbery"
civil time inside your system per the standard defined formula and the
official Earth Corrections data table that goes with it.  Problem
solved!


> But multiple time scales generally ends badly,


Not necessarily - you still have not provided any valid objection to
my design in which the "rubbery" time scale is algorithmically derived
from the "atomic" one, and in which one can convert timestamps back
and forth in an invertible manner.


> or you eventually need to know the total number of leap seconds to translate

> from your special time scale to UTC.


Did you perhaps mean "to translate from UTR/UTC-SLS/LeapSmear to a
TAI-like timescale"?  Translating from a rubbery Earth-following
timescale to UTC as the latter is currently defined requires no
knowledge of the historical leap seconds.

But yes, of course a high-precision "both real-time and civil"
application of the kind you are presumably concerned with will need to
be fed with up-to-date information regarding upcoming Earth Corrections,
and to remember all historical ones.  But where is the problem with
that?  Just define a standard data format, a standard protocol for
transferring the updates, and a standard way of locating the authoritative
servers - yes, will take some work, but certainly very doable.  No more
difficult than DNS.


> So I'm happy that you found a solution for your problems,


No, neither I nor anyone else in my shoes has yet found any solution
to our biggest problem: namely, the threat that the familiar and
working Earth-following UTC which we currently rely on as an acceptable
realization of GMT will be forcibly taken away from us.

If your camp has your way in the ITU next year, who is going to pay
the cost of building a replacement for the lost UTC for those who
require a good faith realization of GMT?  What I need is an apparatus,
such as a special-purpose Stratum 1 NTP server that serves out UTR
instead of UTC, and which I can use to set the system time on all
computer systems under my care.  I will also need an easy way for my
family members and friends to switch all of their time-keeping devices
(computers, smartphones etc) from UTC to UTR, e.g., by pointing them
to my special NTP server and finding some way to ensure that they can
never use an "official UTC" server instead.  Oh, and add the cost of
going through the entire source for, say, a complex GNU/Linux
distribution like Ubuntu, finding all instances of "UTC" and changing
them to "GMT".  *Big* cost.  Who is going to pay for all of that?  Or
rather, whom should I sue to recover this cost I'm going to incur if
your camp has your way?

VLR,
SF