Proposal for a Smoothed Coordinated Universal Time (UTS)

From: Markus Kuhn <Markus.Kuhn_at_cl.cam.ac.uk>
Date: Wed, 25 Oct 2000 19:30:05 +0100

Proposal for a Smoothed Coordinated Universal Time (UTS)
--------------------------------------------------------

Markus Kuhn -- 2000-10-23

The latest version of this proposal is available from

  http://www.cl.cam.ac.uk/~mgk25/uts.txt


Considering

a) that the definition of Coordinated Universal Time (UTC) in
   ITU-R Recommendation TF.460-4 relies on the astronomical
   observation of the UT1 time scale in order to introduce
   leap seconds,

b) that UTC is today the basis for almost all official national
   time scales and therefore widely available to users,

c) that most broadcast time signals provide UTC and rarely provide the
   uniform time scale International Atomic Time (TAI) or the current
   TAI-UTC difference,

d) that leap seconds and therefore TAI-UTC changes are announced by
   the International Earth Rotation Service (IERS) only six months in
   advance and therefore accurate information about them cannot be
   embedded practically as stable look-up tables into products,

e) that a very large and steadily increasing number of information
   systems have access to broadcast UTC time signals and use these to
   synchronize their internal clocks,

f) that broadcast UTC time signals commonly announce leap seconds at
   least one hour in advance but usually provide no other information
   about past or future leap seconds,

g) that numerous information and communication systems use an internal
   time scale based on a fixed length of the day of 86400 seconds, in
   which there exists no unique representation for points in time
   during an inserted UTC leap second, including the widely used POSIX
   time scale defined by ISO/IEC 9945-1:1996 in section 2.2.2.113,

h) that short-term time interval measurements and event scheduling on
   such systems is severely affected if UTC leap seconds are handled
   by either halting during an inserted leap second or setting back by
   a one second step after an inserted leap second the internal clock
   and by advancing the internal clock by a one second step at a
   deleted leap second,

i) that a temporary circa 0.1% modification of the speed of the
   internal clock near a UTC leap second in order to provide a
   continuous mapping between the internal time representation and UTC
   is far less disruptive on such systems than halting or resetting
   the system clock,

j) that a standardized recommended way of performing such a temporary
   modification of the speed of the clock in the internal time
   representation of information and communication systems will
   significantly improve the interoperability of such systems,

k) that the availability of such a standard could significantly reduce
   the need to modify the definition of UTC, as it is currently under
   study by the International Union of Radio Science (URSI), the
   International Astronomical Union (IAU), the International
   Telecommunications Union (ITU-R) and the International Bureau for
   Weights and Measures (BIPM),

I suggest to standardize the UTS time scale defined in the following
as a recommended basis for defining the internal time scales used on
UTC-synchronized information and communication systems that do not
provide a unique representation for points in time during inserted UTC
leap seconds.

UTS shall be identical to UTC except during the last 1000 seconds of a
UTC day that is shortened or extended by one leap second as announced
by the International Earth Rotation Service in accordance with ITU-R
Recommendation TF.460-4.

Inserted leap second

Whenever a UTC day is extended by an inserted leap second that lasts
from 23:59:60 to 24:00:00, this leap second shall not appear on the
UTS time scale. The last 1000 seconds on the UTC time scale from
23:43:21 to 24:00:00 will be represented on the UTS time scale by 999
modified seconds 23:43:21 to 24:00:00, each of which lasts 1000/999
seconds. The following table shows the exact and simultaneous display
of a UTC and UTS clock at various points in time near an inserted
leap second:

       UTC UTS

   23:43:20.000 23:43:20.000
   23:43:21.000 23:43:21.000 <- UTS starts to diverge from UTC
   23:43:22.000 23:43:21.999
   23:43:23.000 23:43:22.998
   23:43:24.000 23:43:23.997
   ... 995 seconds later ...
   23:59:59.000 23:59:58.002
   23:59:60.000 23:59:59.001 <- leap second starts
   00:00:00.000 00:00:00.000 <- leap second ends and UTS=UTC
   00:00:01.000 00:00:01.000


Deleted leap second

Whenever a UTC day is shortened by deleting a leap second that would
otherwise last from 23:59:59 to 24:00:00, this leap second shall
nevertheless appear on the UTS time scale. The last 1000 seconds on
the UTC time scale from 23:43:19 to 24:00:00 will be represented on
the UTS time scale by 1001 modified seconds 23:43:19 to 24:00:00, each
of which lasts 1000/1001 seconds. The following table shows the exact
and simultaneous display of a UTC and UTS clock at various points in
time near a deleted leap second:

       UTC UTS

   23:43:18.000 23:43:18.000
   23:43:19.000 23:43:19.000 <- UTS starts to diverge from UTC
   23:43:20.000 23:43:20.001
   23:43:21.000 23:43:21.002
   23:43:22.000 23:43:22.003
   23:43:23.000 23:43:23.004
   ... 995 seconds later ...
   23:59:58.000 23:59:58.999
   00:00:00.000 00:00:00.000 <- leap second skipped and UTS=UTC
   00:00:01.000 00:00:01.000


Algorithmic representation

In the algorithmic description below, the following variables appear:

  UTC refers to the time given in the time signal received
                     from a Coordinated Universal Time reference clock

  UTS refers to the resulting calculated UTS time that
                     corresponds to UTC

  midnight(UTC) refers to the time of the start of the day identified
                     in UTC, that is the date of UTC with the time
                     set to 00:00:00

  leap_warning(UTC) = 1 if there is already the insertion of a
                            leap second announced for the end of
                            the day identified in UTC
                       -1 if there is already the deletion of a
                            leap second announced for the end of
                            the day identified in UTC
                        0 otherwise

Where a variable represents a time, this representation is in the form
of the time interval measured in seconds that has passed since some
unspecified epoch and the point in time referred to. Constants of the
form hh:mm:ss.sss refer to a time interval measured in hours, minutes
and seconds. Note that 23:59:60 = 24:00:00 = 86400 s and 00:16:40 =
1000 s.

On reception of a UTC time, the corresponding UTS time can be
determined by applying the following algorithm:

    if UTC - midnight(UTC) >= 23:59:60 then
      -- we are in the middle of an inserted leap second (i.e., the
      -- current UTC day is already longer than 86400 seconds)
      UTS := midnight(UTC) + 23:59:59.001 +
             (UTC - midnight(UTC) - 23:59:60) * 999/1000;
    else
      -- if not, calculate seconds remaining until the end of the day
      R := midnight(UTC) + 24:00:00 + leap_warning(UTC) * 00:00:01 - UTC;
      -- if less than 1000 seconds remain, start interpolation
      if R < 00:16:40 then
         UTS := UTC - (00:16:40 - R) * leap_warning(UTC) / 1000;
      else
         UTS := UTC;
      end if;
    end if;

This algorithm uses only information present in the currently
available UTC time signal, which has to include a leap second
announcement that starts to be available at least 1000 seconds before
the end of the UTC day.


Rationale for some of the design choices:

  - UTS uses linear interpolation because this avoids discontinuities
    and is simpler to describe, understand, and implement and also
    more efficient to compute than interpolation using for instance
    higher-degree polynomials. UTS is not primarily intended to be
    used for controlling large masses (e.g., the phase and frequency
    of generators in power plants), where a more complex interpolation
    technique (e.g., B-splines) that minimizes control forces might be
    preferable.

  - Stretching the linear correction over 1000 seconds leads to nice
    and intuitive decimal UTS display values at the start of UTC
    seconds. This would not be the case if this correction time
    interval were an integral number of minutes. Requiring only 1000
    seconds advance notice for an upcoming leap second leaves plenty
    of time for error checking and correction in a potentially noisy
    low-bandwidth time signal that starts to announce leap seconds 59
    minutes before the end of the day (e.g., DCF77). Stretching the
    linear correction over only 100, 10, or even 2 seconds would have
    increased the potential error in time interval measurements and
    with it the number of applications that cannot tolerate this
    error.

  - Keeping the time interval in which UTS differs from UTC entirely
    before the end of the day ensures that UTS can be accurately
    determined in real time using the type of leap-second announcement
    message that will disappear from the broadcast signal immediately
    after the end of the leap second. On the other hand, the
    disadvantage of this choice is that UTS diverges from UTC by up to
    1 second. In contrast, centering the correction time interval
    around the leap second would limit the maximum divergence between
    UTS and UTC to 0.5 seconds.


Additional remarks

UTS is primarily intended as the basis for defining the internal clock
representation used in information systems that have problems handling
UTC leap seconds. Time service broadcasts and definitions of national
and regional civilian reference times are not affected by this
proposal and should continue to be based on UTC. The conversion from
UTC to UTS is expected to happen only inside an end system, not in
reference clock hardware or at a time service broadcasting station.
Users of systems with an internal time representation based on UTS
will typically be shown UTS-based and not UTC-based times, which seems
tolerable in practice, especially if UTS becomes a formally widely
recognized standard for this purpose and the use of UTS instead of UTC
as a basis for the synchronized system time is properly documented. It
should be noted for comparison that a loss of connection with a UTC
reference clock for just a few days will lead to more than one second
divergence from UTC with typical commercial crystal oscillators
without temperature control.

If a system designer should nevertheless decides to broadcast a
UTS-based reference time signal, then this time signal (like most UTC
time signals) should include an announcement of forthcoming inserted
or deleted UTC leap seconds, starting at least 59 minutes in advance.
This information is essential to allow a receiver of a UTS time signal
to distinguish normal seconds from 0.1% modified seconds and to allow
it to convert a UTS time signal back into a UTC time signal.


Comments, endorsements, and suggestions on how to proceed with the
potential formal standardization of this proposal by a relevant
international body (ITU, IERS, IAU, BIPM, etc.) are welcome and
solicited.

Author's address:

Markus G. Kuhn
University of Cambridge
Computer Laboratory
New Museums Site, Pembroke Street
Cambridge CB2 3QG
United Kingdom

Phone: +44 1223 3-34676
Fax: +44 1223 3-34678
Email: Markus.Kuhn_at_cl.cam.ac.uk
URL: http://www.cl.cam.ac.uk/~mgk25/
Received on Wed Oct 25 2000 - 11:40:02 PDT

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