Re: [LEAPSECS] Risks of change to UTC

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sat, 21 Jan 2006 10:11:04 -0700 (MST)

In message: <43D1FB58.1000007_at_usa.net>
            James Maynard <james.h.maynard_at_usa.net> writes:
: M. Warner Losh wrote:
: > UTC works for navigation, but leap seconds pose problems for other
: > users of time. Stating absolutely that UTC is not broken ignores
: > these other users.
:
: Those "other uses," for whom leap seconds pose a problem, should be
: using a time scale that does not have leap seconds. They would be better
: served, for example, by TAI.

You really should read the archives of this list. We've been over
this in great detail. TAI is specifically contraindicated as a time
scale. This also ignores the issues surrounding the proper
computation of elapsed time using the UTC time scale when represnted
by a number. It ignores the fact that you must have a table of leap
seconds to do this effectively. It ignores that one must have a table
of leap seconds to get TAI time, because most providers of time
provide it in UTC.

: For civil use, a calendar that counts days reaonably accurately is
: appropriate. The Gregorian (New Style calendar) that the vast
: majority of the planetary population uses does this. UTC copes with
: the variable length of the mean solar day by inserting leap seconds
: as needed. The role of the IERS in decreeing when leap seconds are
: needed is similar to that of the Roman College of Pontifices who managed
: the old Roman Republican calendar (before Julius Caesar's reform) by
: decreeing, as needed, when to shorten the month of February and insert
: the intercalary month of Mercurius.

I maintain that for human activity, there's no need for leap seconds
at all. In each person's lifetime, the accumulated error is on the
order of a few minutes. Over generations, the problems with noon
drifting to 1pm can trivially be solved by moving the timezones that
civilian time uses.

Keeping universal time synchronized to an arbitrary meridian is
already arbitrary. Adding leap seconds is an arbitrary decision to
implement that arbitrary requirement. It is really only important for
those uses of time that care what the local solar time is to within a
second (as opposed to within an hour which everyone in civil society
is used to since the late 19th century and time zones).

: If your primary need is for a time scale ithat counts SI seconds, with
: no leap seconds to confuse the matter, then don't use UTC. Use a time
: scale that counts SI seconds, such as TAI or GPS time. There's no point
: to applying the mised radix Gregorian calendar system to such a time
: scale, although you can do so if you wish. Count days of 86 400 SI
: seconds each, or GPS weeks of 604 800 SI seconds, or just count SI seconds.
:
: If, on the other hand, you need to count solar days, or mean solar days,
: use a calendar and time scale that does so. In order to know which way
: the earth is pointing, use UT1, or a compromise scale such as UTC that
: is kept reasonably close to UT1. For the vast majority of the
: population of the planet, including celestial navigators, UTC is good
: enough. If you want to know the direction the earth is pointing with
: more precision, apply DUT1 corrections, or use other IERS products such
: as Bulletin A.

That is one solution to the problem, but it is not the only solution
to the problem. Quoting the old, tired saws about using TAI or GPS
time scales to count SI seconds doesn't promote good dialog. Instead,
it drags this discussion down to the level of Dogma.

There are many users that need to both count SI seconds, as well as
synchronize their operations to civilian time. Leap seconds cause
these users real difficulties. Implementing leap seconds in software
is hard to get pedantically right (I have a pile of bugs in code that
was written by smart people that get leap seconds wrong, and over 200
hours of time spent in the past few years on implement, testing and
debugging leap seconds). Even many ntp servers on the net got the
leap second wrong, as did many of the time stations. There's much
evidence that this "solution" to the problem has shifted the cost of
keeping astronomers, celestial navigators, and others with a real need
to the solar time happy to a large number of other users who have no
such real need. As such, it seems only fair in today's economy to
place the costs of the needs of a community on those communities that
have a real need for those goods or services.

: There is no need to "fix" the time scale, UTC, that is used by the vast
: majority of the planet's population to accommodate the very small
: minority of precision time users who desire a time scale that has no
: leap seconds. Let that minority use a time scale, such as TAI, that does
: not have those messy leap seconds.

TAI is not currently recommended by its creators as a viable time
scale.

In my day job, we do use TAI internally. That doesn't solve the
problems of leap seconds. It doesn't solve the problem of products
that need to participate in leap seconds (say irig generators or ntp
servers). They must know the current offset between UTC and TAI in
order for the program to operate correctly. There are very few
applications that can totally ignore leap seconds. Many studies have
been posted here that suggest that when people use an unorthodox time
scale like TAI that errors happen (phk posted one example where two
different subsystems used different time scales, so now there's an
error between them that has to be manually corrected to account for
the accumulated leap seconds).

I've fought to implement leap seconds correctly for the past 5 years
in numerous programs that have both the need to know the right elasped
amount of time, the need to deal with leap seconds specially in some
way (by adjusting time at the leap second, by flywheeling through the
leap second, etc). I've spent close to 200 hours now on leap second
bugs, testing and implementation.

From my perspective, the astronomers and celestial navigators are
being selfish by requiring my company to spend well over $200k to make
things easy on them. Shouldn't they be responsible for more of the
costs of a system that makes their life easy? Shouldn't they be
flexible as the real needs of users of time change over time?
Shouldn't other solutions that might be cheaper to implement be
considered?

Warner
Received on Sat Jan 21 2006 - 09:13:44 PST