idnits 2.17.1 draft-kuhn-leapsecond-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 723. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-460' -- Possible downref: Non-RFC (?) normative reference: ref. 'IERS-C' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nel01' -- Possible downref: Non-RFC (?) normative reference: ref. 'McC91' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-768' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC1588' -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'C' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEG' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Kuhn 3 draft-kuhn-leapsecond-00.txt University of Cambridge 4 Expires: July 2006 January 2006 6 Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire in July 2006. Comments are solicited 32 and should be addressed to the author. 34 Abstract 36 Coordinated Universal Time (UTC) is the international standard 37 timescale used in many Internet protocols. UTC features occasional 38 single-second adjustments, known as "leap seconds". These happen at 39 the end of announced UTC days, in the form of either an extra second 40 23:59:60 or a missing second 23:59:59. Both events need special 41 consideration in UTC-synchronized systems that represent time as a 42 scalar value. This specification defines UTC-SLS, a minor variation 43 of UTC that lacks leap seconds. Instead, UTC-SLS performs an 44 equivalent "smooth" adjustment, during which the rate of the clock 45 temporarily changes by 0.1% for 1000 seconds. UTC-SLS is a drop-in 46 replacement for UTC. UTC-SLS can be generated from the same 47 information as UTC. It can be used with any specification that 48 refers to UTC but lacks provisions for leap seconds. UTC-SLS 49 provides a robust and interoperable way for networked UTC- 50 synchronized clocks to handle leap seconds. By providing UTC-SLS 51 instead of UTC to applications, operating systems can free most 52 application and protocol designers from any need to even know about 53 UTC leap seconds. 55 1 Introduction 57 Coordinated Universal Time (UTC) is an internationally agreed precise 58 definition of time. Like its predecessor Greenwich Mean Time (GMT), 59 UTC approximates the local mean solar time on Earth's prime meridian, 60 which passes through Greenwich in London, England. 62 UTC is commonly available through radio time signals [ITU-768], 63 global navigation satellite systems, and the Internet [RFC1305], with 64 an accuracy ranging from a few milliseconds to a few nanoseconds. It 65 is the basis of official time in many countries, where local time is 66 legally defined to differ from UTC exactly by an integral number of 67 half hours. UTC is commonly referred to in the specifications of 68 computer applications, communication protocols [ISO8601, RFC3339] and 69 application-program interfaces [C, POSIX]. 71 UTC is defined and maintained by an internationally coordinated 72 network of precision clocks ("atomic clocks"). The reference 73 frequency they generate is far more stable than Earth's daily 74 rotation, on which the traditional astronomical definitions of time 75 are based. In the interest of backwards compatibility, UTC was 76 defined such that an adjustment is made before UTC and a particular 77 definition of astronomical time, known as UT1 [McC91], drift apart 78 more than 0.9 seconds [ITU-460]. These adjustments have, in their 79 current form, been applied since 1972 and are known as "leap seconds" 80 [Nel01, IERS-C]. 82 The definition of UTC [ITU-460] provides for two types of adjustment: 84 - The "insertion of a second" or "positive leap second" is the 85 addition of a 86401-st second denoted "23:59:60" at the end of a 86 UTC day. 88 - The "deletion of a second" or "negative leap second" is the 89 skipping of the last, 86400-th second denoted "23:59:59" at the 90 end of a UTC day. 92 Time is traditionally represented as a vector of integer numbers, 93 denoting year, month, day, hour, minute, second, and some fraction of 94 a second, for example written as YYYY-MM-DD hh:mm:ss.sss [ISO8601, 95 RFC3339]. A normal UTC day is a progression of 86400 seconds, which 96 are numbered 00:00:00 to 23:59:59. 98 When the rotation of Earth has fallen behind UTC, the insertion of a 99 second into UTC (positive leap second) will be announced in [IERS-C]. 100 On the announced date, the UTC day will be 86401 seconds long and a 101 UTC clock will display at its end the sequence of seconds 103 ..., 23:59:57, 23:59:58, 23:59:59, 23:59:60, 00:00:00, 00:00:01, ... 105 Likewise, should the rotation of Earth rush ahead of UTC, the 106 deletion of a leap second will be announced, and on that date, the 107 UTC day will be only 86399 seconds long and will end with the 108 sequence of seconds 110 ..., 23:59:57, 23:59:58, 00:00:00, 00:00:01, ... 112 Time distribution services, such as NTP [RFC1305], provide 113 announcements of forthcoming leap seconds. These permit clocks 114 synchronized to such a time service to display leap seconds exactly 115 as defined in [ITU-460, IERS-C] and shown above. 117 Leap seconds were introduced because they provide the most convenient 118 way of adjusting UTC for some applications, in particular those that 119 distribute time via pulse-per-second signals. By inserting or 120 deleting an entire second, such signals are not disturbed, and 121 neither are any of the precision frequencies that are generated from 122 them by frequency multiplication, including carrier frequencies of 123 radio transmitters, television signal timings, etc. 125 In other applications, however, leap seconds are less convenient. 126 Unlike humans, computers deal with time more easily as a single 127 scalar value, rather than as a vector of integers. 129 A typical and prominent example of a scalar encoding of time is the 130 "seconds since the epoch" timescale. It is defined in [POSIX] as a 131 scalar encoding of a YYYY-MM-DD hh:mm:ss.sss value shown on a clock 132 that approximates UTC. If UTC had no leap seconds, this value would 133 represent the number of seconds that have elapsed since the start of 134 the UTC day 1970-01-01. 136 If a clock is closely synchronized with UTC and receives leap-second 137 announcements in advance, then [ITU-460] defines only what happens to 138 an hh:mm:ss display near that leap second. However, if such a clock 139 is required to output a scalar time, its implementor and users will 140 face two problems. Firstly, typical scalar encodings of time have no 141 unambiguous representation for points in time during a positive leap 142 second. Secondly, both positive and negative leap seconds will cause 143 a discontinuity in the scalar representation of time that may be 144 disruptive for some applications. 146 [ITU-460] provides no guidance for handling scalar representations of 147 time across leap seconds. [POSIX] leaves the exact behavior of its 148 "seconds since the epoch" timescale implementation-defined. Most 149 other protocol and API specifications remain equally silent on the 150 issue. 152 This specification fills that gap by providing clock implementors 153 with guidance on what a UTC-synchronized computer clock should output 154 near a leap second. It specifies the exact behavior of a clock that 155 displays a variant of UTC called UTC-SLS (UTC with Smoothed Leap 156 Seconds). 158 2 Application of UTC-SLS 160 UTC-SLS is intended as a drop-in replacement for UTC in any 161 application protocol interface or communication protocol that does 162 not explicitely specify any particular behavior near a leap second. 164 UTC-SLS avoids the problems that arise when the UTC clock defined in 165 [ITU-460] is converted into a scalar representation of time. It can 166 be used by implementors of UTC-synchronized clocks with scalar output 167 in order to achieve interoperable behavior with a low risk of 168 disruption in the presence of leap seconds. 170 UTC-SLS should be used in computer applications and protocols 171 independent of whether they represent time as a scalar value or in 172 hh:mm:ss notation. Even though the hh:mm:ss representation is, in 173 principle, capable of encoding inserted UTC leap seconds 174 unambiguously, using the 23:59:60 notation from [ITU-460], in 175 practice this is not feasible, because hh:mm:ss and scalar 176 representations have to be converted into each other frequently. 178 If UTC-synchronized computer clocks provide their users routinely 179 with an approximation of UTC-SLS instead of an approximation of UTC, 180 then it can be hoped that far fewer specification authors and 181 software developers will have to be aware of leap seconds. Leap 182 seconds can remain a concern of the time-keeping specialists that 183 implement the clock drivers in operating systems and the protocols 184 used to synchronize these with external time signals. 186 UTC-SLS is not intended to be used as a drop-in replacement in 187 specifications that are themselves concerned with the accurate 188 synchronization of clocks and that have already an exactly specified 189 behavior near UTC leap seconds (e.g., NTP [RFC1305], PTP [IEC1588]). 191 Some "real time" applications have very demanding clock-stability 192 requirements, for which neither UTC nor UTC-SLS are suitable. 193 Appendix B discusses application limits of UTC-SLS and alternatives. 195 3 Properties of UTC-SLS 197 On a UTC-SLS clock 199 - the time of day always progresses through 86400 different 200 hh:mm:ss values, and always ends with ..., 23:59:58, 23:59:59, 201 followed by 00:00:00, 00:00:01, ...; 203 - the time 23:59:60 never appears; 205 - the time never differs from UTC by more than one second; 207 - the time always equals UTC at full or half hours; 209 - the rate can deviate by exactly +/- 0.1% (+/- 1000 ppm). 211 4 Definition of UTC-SLS 213 A UTC-SLS clock shows the exact same time as a UTC clock, except 214 during the last 1000 seconds of any UTC day that is extended or 215 shortened through the insertion or deletion of one leap second at the 216 end of that day. 218 4.1 Positive leap second 220 Whenever a UTC day is extended by an inserted second, during this 221 positive leap second, values of the form 23:59:60.xxxx are displayed 222 on a UTC clock, but no such timestamps appear on a UTC-SLS clock. 223 Instead, during the last 1000 seconds of that UTC day, starting at 224 23:43:21, the UTC-SLS clock slows down to 0.999 times its normal 225 rate, which means that the UTC-SLS clock progresses during that time 226 only through 999 "slow seconds", each of which lasts 1000/999 227 seconds. 229 The following table shows the exact and simultaneous display of a UTC 230 and UTC-SLS clock at various points in time near an inserted leap 231 second: 233 UTC UTC-SLS Remarks 235 23:43:20.0000 23:43:20.0000 236 23:43:21.0000 23:43:21.0000 UTC-SLS starts to diverge from UTC 237 23:43:22.0000 23:43:21.9990 UTC-SLS is now 1 ms behind UTC 238 23:43:23.0000 23:43:22.9980 UTC-SLS is now 2 ms behind UTC 239 23:43:24.0000 23:43:23.9970 UTC-SLS is now 3 ms behind UTC 240 ... 995 seconds later ... 241 23:59:59.0000 23:59:58.0020 UTC-SLS is now 998 ms behind UTC 242 23:59:60.0000 23:59:59.0010 UTC leap second starts 243 00:00:00.0000 00:00:00.0000 UTC leap second ends, UTC-SLS = UTC 244 00:00:01.0000 00:00:01.0000 246 Intermediate UTC-SLS values are defined through linear interpolation 247 accordingly, for example: 249 UTC UTC-SLS 251 23:43:21.1000 23:43:21.0999 252 23:43:21.2000 23:43:21.1998 253 ... 254 23:59:60.9000 23:59:59.9001 256 4.2 Negative leap second 258 Whenever a UTC day is shortened by deleting a leap second, no values 259 of the form 23:59:59.xxxx are displayed on a UTC clock, but all these 260 timestamps nevertheless appear on a UTC-SLS clock. Instead, during 261 the last 1000 seconds of that UTC day, starting at 23:43:19, the UTC- 262 SLS clock accelerates to 1.001 times its normal rate, which means 263 that the UTC-SLS clock progresses during that time through 1001 "fast 264 seconds", each of which lasts 1000/1001 seconds. 266 The following table shows the exact and simultaneous display of a UTC 267 and UTC-SLS clock at various points in time near a deleted leap 268 second: 270 UTC UTC-SLS 272 23:43:18.0000 23:43:18.0000 273 23:43:19.0000 23:43:19.0000 UTC-SLS starts to diverge from UTC 274 23:43:20.0000 23:43:20.0010 UTC-SLS is now 1 ms ahead of UTC 275 23:43:21.0000 23:43:21.0020 UTC-SLS is now 2 ms ahead of UTC 276 23:43:22.0000 23:43:22.0030 UTC-SLS is now 3 ms ahead of UTC 277 ... 995 seconds later ... 278 23:59:57.0000 23:59:57.9980 UTC-SLS is now 998 ms ahead of UTC 279 23:59:58.0000 23:59:58.9990 UTC-SLS is now 999 ms ahead of UTC 280 00:00:00.0000 00:00:00.0000 leap second skipped, UTC-SLS = UTC 281 00:00:01.0000 00:00:01.0000 283 Intermediate values are again defined through linear interpolation, 284 for example: 286 UTC UTC-SLS 288 23:43:19.1000 23:43:19.1001 289 23:43:19.2000 23:43:19.2002 290 ... 292 23:59:58.9000 23:59:59.8999 294 5 Conversion between UTC and UTC-SLS 296 UTC and UTC-SLS clock displays (of the form hh:mm:ss.sss...) can 297 unambiguously be converted into each other, as long as one knows 298 whether there will be a leap second within 1000 seconds after the 299 time to be converted, and if so, what its sign is. 301 For a given time of day written as hh:mm:ss (hh < 24 and mm < 60), 302 let "since midnight" denote the value hh * 3600 s + mm * 60 s + ss * 303 1 s. Let U denote the "since midnight" value of a UTC clock display 304 and let US denote the corresponding "since midnight" value of a UTC- 305 SLS clock display. Let 307 L = +1 s if the UTC day ends with an inserted leap second, 308 L = -1 s if the UTC day ends with a deleted leap second, and 309 L = 0 s otherwise. 311 Further, let 313 B = 86400 s + L - I 315 where I = 1000 s is the length of the smoothing interval. 317 If U < B, then U = US, otherwise 319 US = U - L * (U - B) / I 321 and 323 U = B + (US - B) / (1 - L / I). 325 6 Security Considerations 327 Leap seconds are only one of several likely reasons due to which an 328 application may experience disruptions in the operation of a UTC- 329 synchronized clock. An important other one is the temporary loss of 330 synchronization with UTC, for example due to interrupted 331 communication channels or an operator error, and the need for 332 subsequent resynchronization with UTC. Most security-sensitive 333 systems cannot afford to rely on an assumption that their clock is 334 always synchronized to UTC with less than +/- 1000 ms error, or that 335 the rate of their clock does not deviate by up to +/- 0.1% when 336 measured over intervals less than 1000 seconds long. It is, 337 therefore, unlikely that the use of UTC-SLS is going to introduce any 338 new security hazards into an application that would not exist without 339 UTC-SLS and that are not due to unrealistic expectations in the 340 performance of any computer-implemented UTC-synchronized clock. 342 APPENDIX A: Rationale 344 This section lists some of the options considered during the 345 development of this specification, and indicates the reasons for the 346 particular design chosen for UTC-SLS. 348 Functions that read a UTC-synchronized clock and return the current 349 time as a scalar value could behave in a number of different ways 350 near UTC leap seconds. If the scalar timescale allocates an interval 351 of 86400 seconds for each UTC day and the goal is not to deviate in 352 any way from UTC outside a leap second, possible behaviors during 353 inserted UTC leap second include: 355 1a) The scalar value could jump backwards in time by one second at 356 the start of an inserted leap second (so, for example, both 357 23:59:59.1 and 23:59:60.1 will have the same scalar 358 representation, and the last second of the day repeats). 360 1b) The scalar value could jump backwards in time by one second at 361 the end of an inserted leap second (so, for example, both 362 23:59:60.1 and 00:00:00.1 will have the same scalar 363 representation, and the first second of the next day repeats). 365 1c) The function could return, in addition, a leap-second-in-progress 366 bit, to disambiguate the scalar value. 368 1d) Where a separate second and subsecond value is returned, an 369 unambiguous out-of-range subsecond component could be returned, 370 until the inserted leap second is over (for example, a nanosecond 371 count could overflow in the range 1000000000 to 1999999999). 373 1e) The function could delay its reading of the clock and not return 374 until the inserted leap second is over. 376 1f) The clock could stop for 1 s right before reaching 00:00:00. 378 1g) The operating system could suspend all processes during an 379 inserted leap second. 381 1h) The function could abort with an error code when called during an 382 inserted leap second. 384 Deleted leap seconds leave less room for variety and a requirement 385 that the returned value must not deviate in any way from UTC outside 386 a leap second could only be achieved in one way: 388 1i) The scalar value jumps forward in time by one second when the 389 deleted leap second 23:59:59 is reached, directly to 00:00:00. 391 Other options include: 393 2a) The scalar timescale could be defined by allocating 86401 seconds 394 for each UTC day. This would provide an unambiguous scalar 395 representation of an inserted leap second 23:59:60 at the end of 396 each day. 398 2b) The scalar timescale could be defined by allocating the actual 399 number of seconds to each day, this way representing a count of 400 real seconds, rather than being a fixed encoding of a YYYY-MM-DD 401 hh:mm:ss UTC clock reading. The conversion between such a scalar 402 time and a vector representation of UTC would then dependent on 403 the availability of a table of all leap seconds since the origin 404 of the scale ("epoch"). 406 2c) The clock could continue without any adjustment across a leap 407 second, delaying the leap until the system is restarted. 409 2d) The scalar timescale could be defined by allocating 86400 seconds 410 for each UTC day, but the rate at which the clock ticks through 411 the seconds could be changed temporarily. 413 Options 1a) to 1i) and also 2a) all lead to discontinuities in the 414 time scale. If an application measures the time interval between two 415 events by subtracting two of the returned values, then with any of 416 these options, the relative error made has no upper bound. 418 The problem with option 2b) is that the mapping between scalar time 419 values and integer vectors representing the display of a UTC clock is 420 no longer fixed. This mapping changes each time a new leap second is 421 announced and is not predictable more than a few months into the 422 future. So while option 2b) may be very attractive for applications 423 with high accuracy requirements for time-interval measurements (e.g., 424 navigating a spacecraft), it is not well suited for applications that 425 rely on a stable future relationship with UTC (e.g., an office 426 calendar). 428 Option 2c) avoids clock discontinuities while processes are running 429 on the local system. However, it may hinder interoperability with 430 systems that restart at different times. 432 While [C] permits all of the above approaches, [POSIX] explicitely 433 forbids both 2a) and 2b) for its "seconds since the epoch" timescale. 435 This leaves option 2d), the solution chosen in this specification, as 436 the one that is easiest to manage and least likely to cause 437 disruption for a large number of applications. The form of the 438 required rate correction can be chosen in a number of ways, for 439 example: 441 3a) The clock rate switches between three values: normal, slow, fast. 443 3b) The clock rate is ramped up linearly from its normal rate to a 444 peak deviation, and then ramped back again to normal. 446 3c) The difference in offset of the timescale before and after the 447 leap second is fed into the same control loop that keeps the 448 offset and rate of the clock aligned with an external reference. 449 The one-second step will be processed by the loop's low-pass 450 filters, whose output gradually adjusts the rate and offset of 451 the clock for a smooth transition. 453 Option 3a) was chosen for UTC-SLS, because it is the easiest of these 454 alternatives to describe, understand, implement and verify. With it, 455 the mapping between a fixed-frequency counter value and a scalar 456 representation of UTC-SLS is a continuous function that is piece-wise 457 defined through affine functions (polynomials of degree one). 459 With option 3b), that mapping would become a continuously 460 differentiable function that is defined piece-wise through 461 polynomials of degree two. This increase in conceptual and 462 computational complexity would have the benefit of limiting the rate 463 at which the rate of the clock changes. There may be some specialist 464 applications that could benefit from such a limit, in particular 465 those where a control loop is used to steer the motion of a large 466 mass (e.g., a real or simulated "fly wheel") in relation to a UTC- 467 synchronized clock. Besides the question whether UTC-based time 468 scales are appropriate at all for such applications, given that each 469 would have its own particular engineering constraints, it seems more 470 appropriate to use a special-purpose timescale for each, rather than 471 attempt to try and accommodate them all in a general-purpose solution 472 like UTC-SLS. 474 Option 3c) may seem easiest to implement with an already existing 475 control loop. However, there are a large number of design choices 476 and parameters with such control loops, which designers may want to 477 optimize based on the properties of their particular clock hardware 478 and communication channel. Therefore, standardizing any particular 479 one control loop for the purpose of smoothing leap seconds would 480 either place a severe restriction on the designer of a control loop 481 that is primarily needed to track the reference clock, or it would 482 lead to the implementation of separate control loops, defeating the 483 only advantage of option 3c). 485 Having decided to simply switch from the clock's normal rate to a 486 single faster or slower smoothing rate near a leap second, two more 487 choices need to be made. 489 The time interval during which the clock runs at the smoothing rate 490 could be placed 492 4a) entirely after the leap second; 494 4b) entirely before the leap second; 496 4c) centered around the leap second. 498 Option 4c) would have the advantage that the maximum deviation 499 between UTC and UTC-SLS is limited to only half a second. However, 500 this maximum deviation would be reached at midnight, which is a time 501 commonly used to schedule events and deadlines. Both options 4a) and 502 4b) lead to a maximum deviation between UTC and UTC-SLS of one 503 second, but with them, UTC and UTC-SLS are identical at midnight. 504 For this reason, option 4c) was not chosen. 506 Many time-signal providers transmit a leap-second announcement during 507 some time before the leap second, and stop doing so as soon as the 508 leap second is over. With option 4a), a UTC time-signal receiver 509 that is switched on directly after a leap second would not be able to 510 learn about the leap second that has just happened, and would, 511 therefore, not be able to apply the correction necessary to convert 512 UTC into UTC-SLS. With option 4b), the time during which UTC and 513 UTC-SLS differ and the time during which leap-second announcements 514 are usually transmitted overlaps, ensuring that a newly activated UTC 515 receiver can very quickly synchronize with UTC-SLS. 517 The final parameter to be chosen is the length I of the smoothing 518 interval, which also defines the factor 1 - L/I by which the clock 519 rate changes. The chosen value I = 1000 s (or 16 minutes and 40 520 seconds) fulfills the following requirements: 522 5a) The resulting maximal rate error of L/I should be well below any 523 human perception limit for changes in length, duration, rate, 524 rhythm, or pitch, to make it unlikely that anyone will directly 525 perceive the rate change with unaided senses. 527 5b) The length of I should be below half an hour (I < 1800 s), such 528 that UTC and UTC-SLS are identical at every half and full hour in 529 every time zone that differs from UTC by an integral number of 530 full or half hours. This way, many exact deadlines remain 531 unaffected by the difference between UTC and UTC-SLS. 533 5c) The length I should be less than 59 minutes, which is the advance 534 warning time given by some existing time services for an upcoming 535 leap second (e.g., the German DCF77 transmitter). 537 5d) Choosing a power of 10 times one second for the value of I 538 ensures that the conversion between UTC and UTC-SLS is easy to 539 understand and perform when both times are displayed as decimal 540 numbers. 542 The choice of I = 1000 s is the largest value that fulfills all of 543 the above criteria. 545 APPENDIX B: Application Limits 547 Where applications use a UTC-SLS clock to measure the time interval 548 between two events, and do not correct for the variable rate, the 549 maximum possible relative error due to leap seconds is 0.1%. This 550 maximum error can only be reached for intervals of 1000 s or shorter, 551 and decreases for longer intervals. 553 The vast majority of computer applications have far less exacting 554 requirements for time-interval measurements and can, therefore, use 555 UTC-SLS without any concern for leap seconds. 557 Some multimedia standards specify stricter clock-stability 558 requirements, which cannot be met within the constraints listed in 559 Appendix A. For example, [MPEG] defines a 27 MHz system clock 560 frequency with a maximum permitted frequency error of 0.003% (30 ppm, 561 parts per million) and a maximum permitted rate change with time of 562 75 millihertz per second or 0.002777 ppm/s. 564 Whether UTC-SLS can still be used with such specifications depends on 565 the requirements of a particular application. Strict clock-rate 566 tolerances, like those given in [MPEG], can be critical in tightly 567 synchronized television-studio networks. On the other hand, 568 requirements may be far more relaxed if the same audio-visual data is 569 streaming over the Internet. There, the receiver must buffer data 570 anyway for several seconds to compensate network jitter, and a leap 571 second smoothed over 1000 seconds becomes negligible compared to the 572 normal variability in network delay. 574 Examples for other applications with strict clock-stability 575 requirements include spacecraft navigation systems, where the motion 576 of bodies is measured and predicted far more accurately than with 577 0.1% error, or the control of distributed scientific instruments that 578 operate in a global reference frame, such as telescopes and 579 seismographs. Such time-critical applications are usually 580 implemented on special real-time hardware and software that reduce 581 the many scheduling and timing hazards of general-purpose platforms, 582 such as operating systems with preemptive multitasking. Some real- 583 time programming environments provide several clocks with different 584 stability properties. For example, in [POSIX], the clock_gettime() 585 function distinguishes between a "REALTIME" and a "MONOTONIC" clock. 586 The former is meant to approximate UTC, and can do so in the form of 587 UTC-SLS. The "MONOTONIC" clock, on the other hand, does not 588 approximate any external clock, but aims to be as rate stable as 589 possible. It may just count the seconds since the last system 590 restart. It is, therefore, a more suitable choice for sensitive 591 time-interval measurements. 593 A number of standard time scales exist that are, in contrast to UTC 594 and UTC-SLS, not synchronized with Earth's rotation. They are 595 entirely defined by precision clocks and feature no leap seconds. 596 UTC falls behind these timescales by one more second with each 597 positive leap second. Some examples are: 599 - International Atomic Time (TAI) is a leap-second free timescale 600 defined by the same clock network that determines UTC. It was 601 approximately identical to Universal Time on 1958-01-01 and 602 was exactly 10 seconds ahead of UTC by 1972-01-01. 604 - GPS Time is a timescale used within the U.S. Department of 605 Defense Global Positioning System. It has its origin at 606 1980-01-06 00:00 UTC, when TAI was 19 s ahead of UTC. Therefore, 607 GPS Time remains 19 s behind TAI. (Many GPS receivers can 608 display both GPS Time and UTC.) 610 - Terrestrial Time is an International Astronomical Union timescale 611 used in astronomical tables. It is 32.184 s ahead of TAI. 613 It can be expected that some future operating systems will maintain 614 an additional clock that is synchronized with one of these 615 timescales. Such clocks are well suited for highly accurate long- 616 term time-interval measurements. However, they lack the close 617 relationship to legal time that UTC-synchronized clocks offer. And 618 because a clock synchronized to TAI or GPS Time may still need 619 substantial readjustment after a temporary loss of synchronization, 620 they may not guarantee the same short-term rate stability as a clock 621 like "MONOTONIC" that is not externally synchronized. 623 Normative References 625 [ITU-460] "Standard-frequency and time-signal emissions", ITU-R 626 Recommendation TF.460-6, International Telecommunication 627 Union, Geneva, 2002. 629 [IERS-C] Gambis, D., "Bulletin C", International Earth Rotation and 630 Reference Systems Service (IERS), Paris, France. 631 http://hpiers.obspm.fr/iers/bul/bulc/ 633 Informal References 635 [Nel01] Nelson, R., et al., "The leap second: its history and 636 possible future", Metrologia, Vol. 38, 2001, pp. 509-529. 638 [McC91] McCarthy, D.: "Astronomical Time", Proceedings of the 639 IEEE, Vol. 79, No. 7, July 1991, pp. 915-920. 641 [ITU-768] "Standard frequencies and time signals", ITU-R 642 Recommendation TF.768-5, International Telecommunication 643 Union, Geneva, 2002. 645 [ISO8601] "Data elements and interchange formats -- Information 646 interchange -- Representation of dates and times", ISO 647 8601, International Organization for Standardization, 648 Geneva, 2004. 650 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 651 Timestamps", RFC 3339, July 2002. 653 [RFC1305] D. Mills, "Network Time Protocol (Version 3) : 654 Specification, Implementation and Analysis", RFC 1305, 655 March 1992. 657 [IEC1588] "Precision clock synchronization protocol for networked 658 measurement and control systems", IEC 61588, International 659 Electrotechnical Commission, Geneva, 2004. 661 [POSIX] The Open Group, "Single UNIX Specification", Version 3, 662 Base Specifications Issue 6, IEEE Std 1003.1, 2004 663 edition. http://www.unix.org/ 665 [C] "Programming languages -- C", ISO/IEC 9899, International 666 Organization for Standardization, Geneva, 1999. 668 [MPEG] "Information technology -- Generic coding of moving 669 pictures and associated audio information -- Part 1: 670 Systems", ISO/IEC 13818-1, 1997. 672 Author's Address 674 Markus G. Kuhn 675 University of Cambridge 676 Computer Laboratory 677 15 JJ Thomson Avenue 678 Cambridge CB3 0FD 679 England 681 Email: Markus.Kuhn@cl.cam.ac.uk 682 Phone: +44 1223 334676 683 WWW: http://www.cl.cam.ac.uk/~mgk25/ 685 Full Copyright Statement 687 Copyright (C) The Internet Society (2006). 689 This document is subject to the rights, licenses and restrictions 690 contained in BCP 78, and except as set forth therein, the authors 691 retain all their rights. 693 This document and the information contained herein are provided on an 694 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 695 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 696 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 697 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 698 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 699 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 Intellectual Property 703 The IETF takes no position regarding the validity or scope of any 704 Intellectual Property Rights or other rights that might be claimed to 705 pertain to the implementation or use of the technology described in 706 this document or the extent to which any license under such rights 707 might or might not be available; nor does it represent that it has 708 made any independent effort to identify any such rights. Information 709 on the ISOC's procedures with respect to rights in ISOC Documents can 710 be found in BCP 78 and BCP 79. 712 Copies of IPR disclosures made to the IETF Secretariat and any 713 assurances of licenses to be made available, or the result of an 714 attempt made to obtain a general license or permission for the use of 715 such proprietary rights by implementers or users of this 716 specification can be obtained from the IETF on-line IPR repository at 717 http://www.ietf.org/ipr. 719 The IETF invites any interested party to bring to its attention any 720 copyrights, patents or patent applications, or other proprietary 721 rights that may cover technology that may be required to implement 722 this standard. Please address the information to the IETF at 723 ietf-ipr@ietf.org.