what should a time standard encompass?

From: Ken Pizzini <ken_at_halcyon.com>
Date: Fri, 24 Jan 2003 03:00:25 -0800

On Sat, Jan 18, 2003 at 08:10:56AM -0700, Rob Seaman wrote:
> If there is a change to the civil time standard (currently UTC),
> a prudent suggestion might be that the legal and technical precision
> of the standard should be improved, not simply left for our
> grandchildren's grandchildren to figure out.

I've seen you make statements of this ilk, that we should be making
civil time definitions more precise rather than less, a few times.
However I continue to be in the dark as to how the issues of precision
timekeeping relate to the needs of a civil time standard. Civil time
should be precise relative to what metric?

The vastly overstretched time zone boundaries, the willy-nilly
political games of "Savings Time" plans, and (even for the few
parts of the world where the relation between UTC and LMT is almost
reasonable) the seasonal equation-of-time changes all make the concept
of "precision" civil time just about meaningless to my mind.


Remember, UTC is an approximation of UT1, and UT1 is based on the
fictitious "mean solar day" (note 1). It happens that there are
reasonable algorithms to translate between UT1 and either LMT or local
apparent sidereal time (which are examples of the varieties of times
which folk like the astronomical community _really_ care about), but
no ordinary civilian makes these transformations; the correspondence
between an "accurate-enough" clock and what a traditional (pre-1880's)
sundial would read is pretty damn fuzzy.

I'll grant that issues of secular drift can be a problem (though for
civil time the idea of "leap hours", implemented by a legal/political
redefinition of the offset from some variety of universal time,
seems likely to be adequate, in the unlikely event that a strong
enough argument were to be otherwise made in favor of having civil
time track a time standard which permitted such drift), but it seems
pointless to me to worry about trying to be precise about oscillating
drifts in the definition of civil time.

As far as I can make out, what is important to civil time is that:
  1) there is some official mechanism for the distribution of a time
     standard which is monotonically increasing and has basic units
     (e.g., hour, day) whose lengths do not vary substantially over
     the course of a year;
  2) that this distribution mechanism enables a good basis for
     time-referencing legal definitions to work from (e.g., the time
     component of "must be received at the Foo Corp.'s Chicago office
     no later than 5:00 pm Central Standard Time on 2003-04-01" should
     be at least as unambiguous as the rest of the statement); and
  3) political/legal selection of an offset from the standard can be
     used to place "noon, local standard-adjusted time" within two
     or three hours of "noon, LMT".


Now I'm not saying that having a precise time standard isn't valuable
for various technical fields, and a widely useful high-precision
technical standard would be a natural basis for a civil time standard.
But the direct value of precision time for ordinary civil uses seems
low --- it is just that a technically-valuable precision time standard
would meet and exceed the needs of civil time, not that civil time
has some metric by which sub-second precision is meaningful.

None of the above should be construed as an argument for or against the
merits of the current definition of UTC, for those applications where
UTC is "almost right" (note 2). I'm merely arguing that I am failing
to see any natural basis for which the concept of "precision civil
time" is meaningful. High precision dynamical or atomic time, sure,
just as other technical uses of time can have well-defined meanings
for the term "precise", but other than "precise alignment with the
technically defined XXX time system" (for any of various potential
choices of systems) I fail to see any inherently meaningful way of
specifying what it would mean for civil time's "technical precision
of the standard" to be improved.


(1) By "fictitious" I mean that it is defined by an abstract
    definition, not a direct observation. The realization of the
    definition is carried out by extended observations, but it is
    uncommon for any direct local-apparent-noon to local-apparent-noon
    observation of a day to match the duration of a "mean solar day"
    with millisecond precision. (By careful selection of observation
    point based on the precise time-of-equinox one can be sure to
    observe two such matches each year, but each equinox will require
    a different selection of observation location loci; for any fixed
    location the precise matchup is rather rare.)

(2) I know of no application where UTC is "exactly right"; as far as I
    have ever been able to make out, it is just a pragmatic compromise
    between applications for which the orientation of the earth's
    surface in space is important and applications in which a uniform
    time interval is important. I am not convinced that UTC, with its
    current system of leap seconds, is the best compromise possible
    (note 3), but the idea being floated in the URSI questionnaire,
    of just abandoning further leap seconds but otherwise leaving
    the definition of UTC intact, just seem ludicrous to me.

(3) Searching for a better way of addressing the two major categories
    of precision time needs that UTC attempts to reconcile, while
    also attempting to address some of the technical problems seen
    in other applications (such as problems with jump-discontinuities
    in the current leap-second definition), is what I had originally
    hoped LEAPSECS would be about. Alas, it appears to not be. :-(

    I agree with Markus Kuhn's observation that "UTC is already
    very close to the optimal compromise and that it needs no major
    tinkering"; but there are applications for which its precise
    details cause problems. His UTS design is one of the few
    suggestions I've seen which appear to address at least one of the
    "major" shortcomings of the existing UTC definition.

    What I had hoped to see in this forum was people from various
    specialties laying out exactly what problem they want solved by
    a Universal time standard ("can readily calculate where to point
    my telescope to see X" (e.g., tracks UT1 or dynamical time, or
    simplify calculations even further and track some form of sidereal
    time); "is directly usable as a basis for civil time" (i.e.,
    its day tracks an approximation of the motion of the apparent-sun
    instead of the "fixed" stars, or the moon, or a planet, or ...);
    "can readily determine the number of SI seconds between two events
    which were stamped with Standard time" (e.g., tracks TAI); "no
    discontinuous jumps in time" (e.g., UTS, which trades uniformity
    of the duration of a "clock second" over a defined interval in
    order to smooth out adjustments for secular drift with secondary
    standards (such as the UTC leap second mechanism used to keep drift
    from UT1 under control while using TAI-with-offset as the normal
    basis for tracking time)); and any other special precision-time
    or technical-implementation needs which exist out there.

    Then proposals could be floated which could be evaluated as to how
    well they met the various needs, using UTC as the reference
    benchmark. Some proposals, such as UTS, might just be "recommended
    practice" for applications which have narrowly defined problems with
    UTC and are able to make the requisite tradeoffs. But if a truly
    innovative proposal turned out to be better than UTC for a
    substantial majority of identified applications, then exploration of
    how a transition from UTC to the new proposal could be made,
    searching for a means with minimal disruption and cost. Perhaps
    there might be some design by which existing applications could be
    supported (without retooling) over their expected lifetime,
    transitional applications could (again, perhaps) be written to
    transparently adjust to both legacy and new-style infrastructure,
    and new-style infrastructure and UTC aware applications could both
    be phased in as the last of the legacy UTC applications end their
    lifetimes. (Yes, this could mean a time horizon of twenty to one
    hundred years. IMO, any proposal seeking to make "universal"
    changes to UTC with a time horizon of under ten years is bound to be
    grossly unrealistic.)

    [Alright, so perhaps the design of a new "Universal" time standard
    exceeds the original charter of LEAPSECS; but it seems to me
    that the issue of why leap seconds are a perceived as problem is
    intimately tied to how a "Universal" time standard is defined.
    Just deciding to stop having leap seconds ignores the problems
    that leap seconds were designed to fix, and keeping leap seconds
    as-is causes problems for applications which cannot naturally
    deal with jump discontinuities in timekeeping (and no doubt some
    other problems I'm not remembering right now). It seems to me
    that the right solution to the problem of what to do with leap
    seconds is to go back to the basics: what are the problems that a
    "Universal" time standard tries to solve, and is there a better
    way to solve those original problems _and_ problems which have
    come to light since 1972. I suspect that a usable new standard
    would bear a strong resemblance to UTC, with just some tweaking
    in how adjustments are made to keep it close to UT1, but perhaps
    a more clear and complete knowledge of exactly what problems are
    trying to be solved will suggest something surprisingly different.]

(Sorry for the long and rambling post; I had a lot of pent-up thoughts
that started leaking out of my fingers as I started writing what at
first was just going to be a small point-of-clarification question, and
I am not finding the will to cut any more of them out than I already
have.)

                --Ken Pizzini
Received on Fri Jan 24 2003 - 03:11:05 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT