-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> --------------------------------------------------------------------- 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 Thu May 24 2001 - 08:59:42 PDT
This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT