INTERNET-DRAFT M. Kuhn draft-kuhn-leapsecond-00.txt University of Cambridge Expires: July 2006 January 2006 Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in July 2006. Comments are solicited and should be addressed to the author. Abstract Coordinated Universal Time (UTC) is the international standard timescale used in many Internet protocols. UTC features occasional single-second adjustments, known as "leap seconds". These happen at the end of announced UTC days, in the form of either an extra second 23:59:60 or a missing second 23:59:59. Both events need special consideration in UTC-synchronized systems that represent time as a scalar value. This specification defines UTC-SLS, a minor variation of UTC that lacks leap seconds. Instead, UTC-SLS performs an equivalent "smooth" adjustment, during which the rate of the clock temporarily changes by 0.1% for 1000 seconds. UTC-SLS is a drop-in replacement for UTC. UTC-SLS can be generated from the same information as UTC. It can be used with any specification that refers to UTC but lacks provisions for leap seconds. UTC-SLS provides a robust and interoperable way for networked UTC- Kuhn [Page 1] INTERNET-DRAFT UTC-SLS January 2006 synchronized clocks to handle leap seconds. By providing UTC-SLS instead of UTC to applications, operating systems can free most application and protocol designers from any need to even know about UTC leap seconds. 1 Introduction Coordinated Universal Time (UTC) is an internationally agreed precise definition of time. Like its predecessor Greenwich Mean Time (GMT), UTC approximates the local mean solar time on Earth's prime meridian, which passes through Greenwich in London, England. UTC is commonly available through radio time signals [ITU-768], global navigation satellite systems, and the Internet [RFC1305], with an accuracy ranging from a few milliseconds to a few nanoseconds. It is the basis of official time in many countries, where local time is legally defined to differ from UTC exactly by an integral number of half hours. UTC is commonly referred to in the specifications of computer applications, communication protocols [ISO8601, RFC3339] and application-program interfaces [C, POSIX]. UTC is defined and maintained by an internationally coordinated network of precision clocks ("atomic clocks"). The reference frequency they generate is far more stable than Earth's daily rotation, on which the traditional astronomical definitions of time are based. In the interest of backwards compatibility, UTC was defined such that an adjustment is made before UTC and a particular definition of astronomical time, known as UT1 [McC91], drift apart more than 0.9 seconds [ITU-460]. These adjustments have, in their current form, been applied since 1972 and are known as "leap seconds" [Nel01, IERS-C]. The definition of UTC [ITU-460] provides for two types of adjustment: - The "insertion of a second" or "positive leap second" is the addition of a 86401-st second denoted "23:59:60" at the end of a UTC day. - The "deletion of a second" or "negative leap second" is the skipping of the last, 86400-th second denoted "23:59:59" at the end of a UTC day. Time is traditionally represented as a vector of integer numbers, denoting year, month, day, hour, minute, second, and some fraction of a second, for example written as YYYY-MM-DD hh:mm:ss.sss [ISO8601, RFC3339]. A normal UTC day is a progression of 86400 seconds, which are numbered 00:00:00 to 23:59:59. Kuhn [Page 2] INTERNET-DRAFT UTC-SLS January 2006 When the rotation of Earth has fallen behind UTC, the insertion of a second into UTC (positive leap second) will be announced in [IERS-C]. On the announced date, the UTC day will be 86401 seconds long and a UTC clock will display at its end the sequence of seconds ..., 23:59:57, 23:59:58, 23:59:59, 23:59:60, 00:00:00, 00:00:01, ... Likewise, should the rotation of Earth rush ahead of UTC, the deletion of a leap second will be announced, and on that date, the UTC day will be only 86399 seconds long and will end with the sequence of seconds ..., 23:59:57, 23:59:58, 00:00:00, 00:00:01, ... Time distribution services, such as NTP [RFC1305], provide announcements of forthcoming leap seconds. These permit clocks synchronized to such a time service to display leap seconds exactly as defined in [ITU-460, IERS-C] and shown above. Leap seconds were introduced because they provide the most convenient way of adjusting UTC for some applications, in particular those that distribute time via pulse-per-second signals. By inserting or deleting an entire second, such signals are not disturbed, and neither are any of the precision frequencies that are generated from them by frequency multiplication, including carrier frequencies of radio transmitters, television signal timings, etc. In other applications, however, leap seconds are less convenient. Unlike humans, computers deal with time more easily as a single scalar value, rather than as a vector of integers. A typical and prominent example of a scalar encoding of time is the "seconds since the epoch" timescale. It is defined in [POSIX] as a scalar encoding of a YYYY-MM-DD hh:mm:ss.sss value shown on a clock that approximates UTC. If UTC had no leap seconds, this value would represent the number of seconds that have elapsed since the start of the UTC day 1970-01-01. If a clock is closely synchronized with UTC and receives leap-second announcements in advance, then [ITU-460] defines only what happens to an hh:mm:ss display near that leap second. However, if such a clock is required to output a scalar time, its implementor and users will face two problems. Firstly, typical scalar encodings of time have no unambiguous representation for points in time during a positive leap second. Secondly, both positive and negative leap seconds will cause a discontinuity in the scalar representation of time that may be disruptive for some applications. Kuhn [Page 3] INTERNET-DRAFT UTC-SLS January 2006 [ITU-460] provides no guidance for handling scalar representations of time across leap seconds. [POSIX] leaves the exact behavior of its "seconds since the epoch" timescale implementation-defined. Most other protocol and API specifications remain equally silent on the issue. This specification fills that gap by providing clock implementors with guidance on what a UTC-synchronized computer clock should output near a leap second. It specifies the exact behavior of a clock that displays a variant of UTC called UTC-SLS (UTC with Smoothed Leap Seconds). 2 Application of UTC-SLS UTC-SLS is intended as a drop-in replacement for UTC in any application protocol interface or communication protocol that does not explicitely specify any particular behavior near a leap second. UTC-SLS avoids the problems that arise when the UTC clock defined in [ITU-460] is converted into a scalar representation of time. It can be used by implementors of UTC-synchronized clocks with scalar output in order to achieve interoperable behavior with a low risk of disruption in the presence of leap seconds. UTC-SLS should be used in computer applications and protocols independent of whether they represent time as a scalar value or in hh:mm:ss notation. Even though the hh:mm:ss representation is, in principle, capable of encoding inserted UTC leap seconds unambiguously, using the 23:59:60 notation from [ITU-460], in practice this is not feasible, because hh:mm:ss and scalar representations have to be converted into each other frequently. If UTC-synchronized computer clocks provide their users routinely with an approximation of UTC-SLS instead of an approximation of UTC, then it can be hoped that far fewer specification authors and software developers will have to be aware of leap seconds. Leap seconds can remain a concern of the time-keeping specialists that implement the clock drivers in operating systems and the protocols used to synchronize these with external time signals. UTC-SLS is not intended to be used as a drop-in replacement in specifications that are themselves concerned with the accurate synchronization of clocks and that have already an exactly specified behavior near UTC leap seconds (e.g., NTP [RFC1305], PTP [IEC1588]). Some "real time" applications have very demanding clock-stability requirements, for which neither UTC nor UTC-SLS are suitable. Appendix B discusses application limits of UTC-SLS and alternatives. Kuhn [Page 4] INTERNET-DRAFT UTC-SLS January 2006 3 Properties of UTC-SLS On a UTC-SLS clock - the time of day always progresses through 86400 different hh:mm:ss values, and always ends with ..., 23:59:58, 23:59:59, followed by 00:00:00, 00:00:01, ...; - the time 23:59:60 never appears; - the time never differs from UTC by more than one second; - the time always equals UTC at full or half hours; - the rate can deviate by exactly +/- 0.1% (+/- 1000 ppm). 4 Definition of UTC-SLS A UTC-SLS clock shows the exact same time as a UTC clock, except during the last 1000 seconds of any UTC day that is extended or shortened through the insertion or deletion of one leap second at the end of that day. 4.1 Positive leap second Whenever a UTC day is extended by an inserted second, during this positive leap second, values of the form 23:59:60.xxxx are displayed on a UTC clock, but no such timestamps appear on a UTC-SLS clock. Instead, during the last 1000 seconds of that UTC day, starting at 23:43:21, the UTC-SLS clock slows down to 0.999 times its normal rate, which means that the UTC-SLS clock progresses during that time only through 999 "slow seconds", each of which lasts 1000/999 seconds. The following table shows the exact and simultaneous display of a UTC and UTC-SLS clock at various points in time near an inserted leap second: UTC UTC-SLS Remarks 23:43:20.0000 23:43:20.0000 23:43:21.0000 23:43:21.0000 UTC-SLS starts to diverge from UTC 23:43:22.0000 23:43:21.9990 UTC-SLS is now 1 ms behind UTC 23:43:23.0000 23:43:22.9980 UTC-SLS is now 2 ms behind UTC 23:43:24.0000 23:43:23.9970 UTC-SLS is now 3 ms behind UTC ... 995 seconds later ... 23:59:59.0000 23:59:58.0020 UTC-SLS is now 998 ms behind UTC 23:59:60.0000 23:59:59.0010 UTC leap second starts Kuhn [Page 5] INTERNET-DRAFT UTC-SLS January 2006 00:00:00.0000 00:00:00.0000 UTC leap second ends, UTC-SLS = UTC 00:00:01.0000 00:00:01.0000 Intermediate UTC-SLS values are defined through linear interpolation accordingly, for example: UTC UTC-SLS 23:43:21.1000 23:43:21.0999 23:43:21.2000 23:43:21.1998 ... 23:59:60.9000 23:59:59.9001 4.2 Negative leap second Whenever a UTC day is shortened by deleting a leap second, no values of the form 23:59:59.xxxx are displayed on a UTC clock, but all these timestamps nevertheless appear on a UTC-SLS clock. Instead, during the last 1000 seconds of that UTC day, starting at 23:43:19, the UTC- SLS clock accelerates to 1.001 times its normal rate, which means that the UTC-SLS clock progresses during that time through 1001 "fast seconds", each of which lasts 1000/1001 seconds. The following table shows the exact and simultaneous display of a UTC and UTC-SLS clock at various points in time near a deleted leap second: UTC UTC-SLS 23:43:18.0000 23:43:18.0000 23:43:19.0000 23:43:19.0000 UTC-SLS starts to diverge from UTC 23:43:20.0000 23:43:20.0010 UTC-SLS is now 1 ms ahead of UTC 23:43:21.0000 23:43:21.0020 UTC-SLS is now 2 ms ahead of UTC 23:43:22.0000 23:43:22.0030 UTC-SLS is now 3 ms ahead of UTC ... 995 seconds later ... 23:59:57.0000 23:59:57.9980 UTC-SLS is now 998 ms ahead of UTC 23:59:58.0000 23:59:58.9990 UTC-SLS is now 999 ms ahead of UTC 00:00:00.0000 00:00:00.0000 leap second skipped, UTC-SLS = UTC 00:00:01.0000 00:00:01.0000 Intermediate values are again defined through linear interpolation, for example: UTC UTC-SLS 23:43:19.1000 23:43:19.1001 23:43:19.2000 23:43:19.2002 ... Kuhn [Page 6] INTERNET-DRAFT UTC-SLS January 2006 23:59:58.9000 23:59:59.8999 5 Conversion between UTC and UTC-SLS UTC and UTC-SLS clock displays (of the form hh:mm:ss.sss...) can unambiguously be converted into each other, as long as one knows whether there will be a leap second within 1000 seconds after the time to be converted, and if so, what its sign is. For a given time of day written as hh:mm:ss (hh < 24 and mm < 60), let "since midnight" denote the value hh * 3600 s + mm * 60 s + ss * 1 s. Let U denote the "since midnight" value of a UTC clock display and let US denote the corresponding "since midnight" value of a UTC- SLS clock display. Let L = +1 s if the UTC day ends with an inserted leap second, L = -1 s if the UTC day ends with a deleted leap second, and L = 0 s otherwise. Further, let B = 86400 s + L - I where I = 1000 s is the length of the smoothing interval. If U < B, then U = US, otherwise US = U - L * (U - B) / I and U = B + (US - B) / (1 - L / I). 6 Security Considerations Leap seconds are only one of several likely reasons due to which an application may experience disruptions in the operation of a UTC- synchronized clock. An important other one is the temporary loss of synchronization with UTC, for example due to interrupted communication channels or an operator error, and the need for subsequent resynchronization with UTC. Most security-sensitive systems cannot afford to rely on an assumption that their clock is always synchronized to UTC with less than +/- 1000 ms error, or that the rate of their clock does not deviate by up to +/- 0.1% when measured over intervals less than 1000 seconds long. It is, therefore, unlikely that the use of UTC-SLS is going to introduce any new security hazards into an application that would not exist without UTC-SLS and that are not due to unrealistic expectations in the Kuhn [Page 7] INTERNET-DRAFT UTC-SLS January 2006 performance of any computer-implemented UTC-synchronized clock. APPENDIX A: Rationale This section lists some of the options considered during the development of this specification, and indicates the reasons for the particular design chosen for UTC-SLS. Functions that read a UTC-synchronized clock and return the current time as a scalar value could behave in a number of different ways near UTC leap seconds. If the scalar timescale allocates an interval of 86400 seconds for each UTC day and the goal is not to deviate in any way from UTC outside a leap second, possible behaviors during inserted UTC leap second include: 1a) The scalar value could jump backwards in time by one second at the start of an inserted leap second (so, for example, both 23:59:59.1 and 23:59:60.1 will have the same scalar representation, and the last second of the day repeats). 1b) The scalar value could jump backwards in time by one second at the end of an inserted leap second (so, for example, both 23:59:60.1 and 00:00:00.1 will have the same scalar representation, and the first second of the next day repeats). 1c) The function could return, in addition, a leap-second-in-progress bit, to disambiguate the scalar value. 1d) Where a separate second and subsecond value is returned, an unambiguous out-of-range subsecond component could be returned, until the inserted leap second is over (for example, a nanosecond count could overflow in the range 1000000000 to 1999999999). 1e) The function could delay its reading of the clock and not return until the inserted leap second is over. 1f) The clock could stop for 1 s right before reaching 00:00:00. 1g) The operating system could suspend all processes during an inserted leap second. 1h) The function could abort with an error code when called during an inserted leap second. Deleted leap seconds leave less room for variety and a requirement that the returned value must not deviate in any way from UTC outside a leap second could only be achieved in one way: Kuhn [Page 8] INTERNET-DRAFT UTC-SLS January 2006 1i) The scalar value jumps forward in time by one second when the deleted leap second 23:59:59 is reached, directly to 00:00:00. Other options include: 2a) The scalar timescale could be defined by allocating 86401 seconds for each UTC day. This would provide an unambiguous scalar representation of an inserted leap second 23:59:60 at the end of each day. 2b) The scalar timescale could be defined by allocating the actual number of seconds to each day, this way representing a count of real seconds, rather than being a fixed encoding of a YYYY-MM-DD hh:mm:ss UTC clock reading. The conversion between such a scalar time and a vector representation of UTC would then dependent on the availability of a table of all leap seconds since the origin of the scale ("epoch"). 2c) The clock could continue without any adjustment across a leap second, delaying the leap until the system is restarted. 2d) The scalar timescale could be defined by allocating 86400 seconds for each UTC day, but the rate at which the clock ticks through the seconds could be changed temporarily. Options 1a) to 1i) and also 2a) all lead to discontinuities in the time scale. If an application measures the time interval between two events by subtracting two of the returned values, then with any of these options, the relative error made has no upper bound. The problem with option 2b) is that the mapping between scalar time values and integer vectors representing the display of a UTC clock is no longer fixed. This mapping changes each time a new leap second is announced and is not predictable more than a few months into the future. So while option 2b) may be very attractive for applications with high accuracy requirements for time-interval measurements (e.g., navigating a spacecraft), it is not well suited for applications that rely on a stable future relationship with UTC (e.g., an office calendar). Option 2c) avoids clock discontinuities while processes are running on the local system. However, it may hinder interoperability with systems that restart at different times. While [C] permits all of the above approaches, [POSIX] explicitely forbids both 2a) and 2b) for its "seconds since the epoch" timescale. This leaves option 2d), the solution chosen in this specification, as Kuhn [Page 9] INTERNET-DRAFT UTC-SLS January 2006 the one that is easiest to manage and least likely to cause disruption for a large number of applications. The form of the required rate correction can be chosen in a number of ways, for example: 3a) The clock rate switches between three values: normal, slow, fast. 3b) The clock rate is ramped up linearly from its normal rate to a peak deviation, and then ramped back again to normal. 3c) The difference in offset of the timescale before and after the leap second is fed into the same control loop that keeps the offset and rate of the clock aligned with an external reference. The one-second step will be processed by the loop's low-pass filters, whose output gradually adjusts the rate and offset of the clock for a smooth transition. Option 3a) was chosen for UTC-SLS, because it is the easiest of these alternatives to describe, understand, implement and verify. With it, the mapping between a fixed-frequency counter value and a scalar representation of UTC-SLS is a continuous function that is piece-wise defined through affine functions (polynomials of degree one). With option 3b), that mapping would become a continuously differentiable function that is defined piece-wise through polynomials of degree two. This increase in conceptual and computational complexity would have the benefit of limiting the rate at which the rate of the clock changes. There may be some specialist applications that could benefit from such a limit, in particular those where a control loop is used to steer the motion of a large mass (e.g., a real or simulated "fly wheel") in relation to a UTC- synchronized clock. Besides the question whether UTC-based time scales are appropriate at all for such applications, given that each would have its own particular engineering constraints, it seems more appropriate to use a special-purpose timescale for each, rather than attempt to try and accommodate them all in a general-purpose solution like UTC-SLS. Option 3c) may seem easiest to implement with an already existing control loop. However, there are a large number of design choices and parameters with such control loops, which designers may want to optimize based on the properties of their particular clock hardware and communication channel. Therefore, standardizing any particular one control loop for the purpose of smoothing leap seconds would either place a severe restriction on the designer of a control loop that is primarily needed to track the reference clock, or it would lead to the implementation of separate control loops, defeating the only advantage of option 3c). Kuhn [Page 10] INTERNET-DRAFT UTC-SLS January 2006 Having decided to simply switch from the clock's normal rate to a single faster or slower smoothing rate near a leap second, two more choices need to be made. The time interval during which the clock runs at the smoothing rate could be placed 4a) entirely after the leap second; 4b) entirely before the leap second; 4c) centered around the leap second. Option 4c) would have the advantage that the maximum deviation between UTC and UTC-SLS is limited to only half a second. However, this maximum deviation would be reached at midnight, which is a time commonly used to schedule events and deadlines. Both options 4a) and 4b) lead to a maximum deviation between UTC and UTC-SLS of one second, but with them, UTC and UTC-SLS are identical at midnight. For this reason, option 4c) was not chosen. Many time-signal providers transmit a leap-second announcement during some time before the leap second, and stop doing so as soon as the leap second is over. With option 4a), a UTC time-signal receiver that is switched on directly after a leap second would not be able to learn about the leap second that has just happened, and would, therefore, not be able to apply the correction necessary to convert UTC into UTC-SLS. With option 4b), the time during which UTC and UTC-SLS differ and the time during which leap-second announcements are usually transmitted overlaps, ensuring that a newly activated UTC receiver can very quickly synchronize with UTC-SLS. The final parameter to be chosen is the length I of the smoothing interval, which also defines the factor 1 - L/I by which the clock rate changes. The chosen value I = 1000 s (or 16 minutes and 40 seconds) fulfills the following requirements: 5a) The resulting maximal rate error of L/I should be well below any human perception limit for changes in length, duration, rate, rhythm, or pitch, to make it unlikely that anyone will directly perceive the rate change with unaided senses. 5b) The length of I should be below half an hour (I < 1800 s), such that UTC and UTC-SLS are identical at every half and full hour in every time zone that differs from UTC by an integral number of full or half hours. This way, many exact deadlines remain unaffected by the difference between UTC and UTC-SLS. Kuhn [Page 11] INTERNET-DRAFT UTC-SLS January 2006 5c) The length I should be less than 59 minutes, which is the advance warning time given by some existing time services for an upcoming leap second (e.g., the German DCF77 transmitter). 5d) Choosing a power of 10 times one second for the value of I ensures that the conversion between UTC and UTC-SLS is easy to understand and perform when both times are displayed as decimal numbers. The choice of I = 1000 s is the largest value that fulfills all of the above criteria. APPENDIX B: Application Limits Where applications use a UTC-SLS clock to measure the time interval between two events, and do not correct for the variable rate, the maximum possible relative error due to leap seconds is 0.1%. This maximum error can only be reached for intervals of 1000 s or shorter, and decreases for longer intervals. The vast majority of computer applications have far less exacting requirements for time-interval measurements and can, therefore, use UTC-SLS without any concern for leap seconds. Some multimedia standards specify stricter clock-stability requirements, which cannot be met within the constraints listed in Appendix A. For example, [MPEG] defines a 27 MHz system clock frequency with a maximum permitted frequency error of 0.003% (30 ppm, parts per million) and a maximum permitted rate change with time of 75 millihertz per second or 0.002777 ppm/s. Whether UTC-SLS can still be used with such specifications depends on the requirements of a particular application. Strict clock-rate tolerances, like those given in [MPEG], can be critical in tightly synchronized television-studio networks. On the other hand, requirements may be far more relaxed if the same audio-visual data is streaming over the Internet. There, the receiver must buffer data anyway for several seconds to compensate network jitter, and a leap second smoothed over 1000 seconds becomes negligible compared to the normal variability in network delay. Examples for other applications with strict clock-stability requirements include spacecraft navigation systems, where the motion of bodies is measured and predicted far more accurately than with 0.1% error, or the control of distributed scientific instruments that operate in a global reference frame, such as telescopes and seismographs. Such time-critical applications are usually implemented on special real-time hardware and software that reduce Kuhn [Page 12] INTERNET-DRAFT UTC-SLS January 2006 the many scheduling and timing hazards of general-purpose platforms, such as operating systems with preemptive multitasking. Some real- time programming environments provide several clocks with different stability properties. For example, in [POSIX], the clock_gettime() function distinguishes between a "REALTIME" and a "MONOTONIC" clock. The former is meant to approximate UTC, and can do so in the form of UTC-SLS. The "MONOTONIC" clock, on the other hand, does not approximate any external clock, but aims to be as rate stable as possible. It may just count the seconds since the last system restart. It is, therefore, a more suitable choice for sensitive time-interval measurements. A number of standard time scales exist that are, in contrast to UTC and UTC-SLS, not synchronized with Earth's rotation. They are entirely defined by precision clocks and feature no leap seconds. UTC falls behind these timescales by one more second with each positive leap second. Some examples are: - International Atomic Time (TAI) is a leap-second free timescale defined by the same clock network that determines UTC. It was approximately identical to Universal Time on 1958-01-01 and was exactly 10 seconds ahead of UTC by 1972-01-01. - GPS Time is a timescale used within the U.S. Department of Defense Global Positioning System. It has its origin at 1980-01-06 00:00 UTC, when TAI was 19 s ahead of UTC. Therefore, GPS Time remains 19 s behind TAI. (Many GPS receivers can display both GPS Time and UTC.) - Terrestrial Time is an International Astronomical Union timescale used in astronomical tables. It is 32.184 s ahead of TAI. It can be expected that some future operating systems will maintain an additional clock that is synchronized with one of these timescales. Such clocks are well suited for highly accurate long- term time-interval measurements. However, they lack the close relationship to legal time that UTC-synchronized clocks offer. And because a clock synchronized to TAI or GPS Time may still need substantial readjustment after a temporary loss of synchronization, they may not guarantee the same short-term rate stability as a clock like "MONOTONIC" that is not externally synchronized. Normative References [ITU-460] "Standard-frequency and time-signal emissions", ITU-R Recommendation TF.460-6, International Telecommunication Union, Geneva, 2002. Kuhn [Page 13] INTERNET-DRAFT UTC-SLS January 2006 [IERS-C] Gambis, D., "Bulletin C", International Earth Rotation and Reference Systems Service (IERS), Paris, France. http://hpiers.obspm.fr/iers/bul/bulc/ Informal References [Nel01] Nelson, R., et al., "The leap second: its history and possible future", Metrologia, Vol. 38, 2001, pp. 509-529. [McC91] McCarthy, D.: "Astronomical Time", Proceedings of the IEEE, Vol. 79, No. 7, July 1991, pp. 915-920. [ITU-768] "Standard frequencies and time signals", ITU-R Recommendation TF.768-5, International Telecommunication Union, Geneva, 2002. [ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601, International Organization for Standardization, Geneva, 2004. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC1305] D. Mills, "Network Time Protocol (Version 3) : Specification, Implementation and Analysis", RFC 1305, March 1992. [IEC1588] "Precision clock synchronization protocol for networked measurement and control systems", IEC 61588, International Electrotechnical Commission, Geneva, 2004. [POSIX] The Open Group, "Single UNIX Specification", Version 3, Base Specifications Issue 6, IEEE Std 1003.1, 2004 edition. http://www.unix.org/ [C] "Programming languages -- C", ISO/IEC 9899, International Organization for Standardization, Geneva, 1999. [MPEG] "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", ISO/IEC 13818-1, 1997. Author's Address Markus G. Kuhn University of Cambridge Computer Laboratory Kuhn [Page 14] INTERNET-DRAFT UTC-SLS January 2006 15 JJ Thomson Avenue Cambridge CB3 0FD England Email: Markus.Kuhn@cl.cam.ac.uk Phone: +44 1223 334676 WWW: http://www.cl.cam.ac.uk/~mgk25/ Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kuhn [Page 15]