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