idnits 2.17.1 draft-touch-time-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 373 has weird spacing: '... Yes und...' -- The document date (July 19, 2018) is 2101 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ARTWG J. Touch 2 Internet Draft 3 Intended status: Best Current Practice July 19, 2018 4 Expires: January 2019 6 Resolving Multiple Time Scales in the Internet 7 draft-touch-time-04.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, and it may not be 14 published except as an Internet-Draft. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 19, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 Internet systems use a variety of time scales, which can complicate 49 time comparisons and calculations. This document explains these 50 various ways of indicating time and explains how they can be used 51 together safely. This document is intended as a companion to 52 Internet time as discussed in RFC 3339. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Conventions used in this document..............................4 58 3. Terminology....................................................4 59 4. Background.....................................................5 60 4.1. Time uses and properties..................................6 61 4.2. Time scales...............................................7 62 4.3. Comparison of properties..................................8 63 5. Systems that report time.......................................9 64 6. Computing time.................................................9 65 6.1. Conversion...............................................10 66 6.1.1. Continuous and uniform..............................10 67 6.1.2. Uniform but not continuous..........................11 68 6.1.3. Not uniform.........................................11 69 6.1.4. Ordering............................................12 70 6.2. Calculating intervals....................................13 71 7. Advice........................................................14 72 7.1. Selection advice.........................................14 73 7.2. Hazards..................................................15 74 8. Security Considerations.......................................15 75 9. IANA Considerations...........................................15 76 10. References...................................................15 77 10.1. Normative References....................................15 78 10.2. Informative References..................................15 79 11. Acknowledgments..............................................18 81 1. Introduction 83 A popular proverb reads, "a person with one clock always knows what 84 time it is; a person with two clocks is never sure." Unfortunately, 85 Internet systems rely on a variety of time references that often 86 need to be reconciled. This document attempts to explain this issue 87 and provide advice on how to avoid temporal ambiguity. 89 There are various standards for expressing time, including Universal 90 Coordinated Time (UTC) [ITU02], local time (UTC adjusted for time 91 zone location and daylight saving time shifts), and Unix time 93 [OG08], as well as many others. Although the Internet has a standard 94 for expressing time [RFC3339], this document explains the 95 complexities of using any single such time scale and describes how 96 to safely apply any one time scale and to accommodate concurrent use 97 of different time scales. In particular, it focuses on the 98 difficulties using a single time scale to indicate dates to users, 99 to order events, and to measure intervals. This document ignores 100 general and special relativistic effects. 102 Many time frames contain discontinuities, some of which are regular 103 (e.g., time zones, leap days, and daylight saving time shifts), 104 whereas others are irregularly introduced as needed (e.g., leap 105 seconds). These discontinuities complicate interval computation, the 106 latter requiring externally provided context (a table of mandated 107 leap seconds and their scheduled occurrences). Other fine frames are 108 non-uniform, in which the duration of an interval (e.g., a day, a 109 year, or even a second) varies depending on its offset. 111 Despite many attempts, there is no single time scale that supports 112 all common uses easily and without the need for updated external 113 information. As a preview, this document makes the following 114 recommendations for system designers: 116 1. System designers SHOULD NOT invent their own time scale. There 117 are no simpler solutions and more than enough existing variants, 118 although there is no known reason to exclude new variants. 120 2. System designers SHOULD use one time scale as their primary 121 reference and derive all other time scales by conversion, to 122 avoid confusion. Exceptions might optimize for more than one use. 124 3. System designers SHOULD use UTC as their primary time scale 125 because it is most commonly accepted by governments and the basis 126 for the Internet time [RFC3339] (based on ISO 8601 [ISO98]) and 127 the Network Time Protocol (NTP) [RFC5905]. Exceptions optimize 128 computation, e.g., to use TAI [BI06] for interval calculation or 129 local time [ISO98] for user interaction, e.g., calendars. 131 4. System designers SHOULD include location context (e.g., location 132 or zone) as a part of all dates and MUST include that information 133 if conversion to and between civil and local time is required. 135 5. System designers SHOULD maintain updated information regarding 136 leap seconds and time zones and MUST maintain that information if 137 accurate intervals or civil conversions are required. 139 6. System designers SHOULD be explicit about indicating whether 140 intervals are inclusive or exclusive of start and end dates. 141 Doing otherwise is an opportunity for ambiguity. 143 7. System designers SHOULD be very clear about whether timers expire 144 on a date or when an interval has passed, to help understand the 145 impact of continuous and monotonic aspects of time scales. 147 2. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 In this document, these words will appear with that interpretation 154 only when in ALL CAPS. Lowercase uses of these words are not to be 155 interpreted as carrying significance described in RFC 2119. 157 3. Terminology 159 o Instant: a specific moment in time. 161 o Time scale: a system for assigning names to intervals and dates. 163 o Interval: the elapsed time between instants. 165 o Date: the name of an instant in a time scale, typically indicated 166 as an interval from an epoch. 168 o Epoch: an instant used as the origin of a time scale. 170 o Clock: a mechanism indicating the current date in a time scale. 172 o Civil time (or date): a time scale (or date) selected by a 173 government authority. 175 o Solar day: a unit of time defined as the interval of one rotation 176 of the earth as measured between the repeated position of the sun 177 in the sky as viewed from a fixed location. Solar time relative 178 to a single daily position is "apparent solar time". Solar time 179 indicated as a mean over a year (one orbit of the earth around 180 the sun) is "mean solar time". A given solar day can vary by as 181 much as 30 seconds vs. the mean. 183 o Tropical year: a unit of time defined by the interval of one 184 rotation of the earth around the sun as measured using the 185 position of the sun in the sky in the same way as a solar day. 187 o Second: the unit of time, which has multiple definitions whose 188 values differ: 190 o 1/(24 * 60 * 60) of a solar day. 192 o 1/(31,556,925.9747) of a tropical year as of the instant of 193 1900 "January 0" (i.e., December 31) at 12:00:00 Ephemeris 194 time (Ephemeris time is defined later herein) [C61]. 196 o Exactly 9192631770 periods of the radiation corresponding to 197 the hyperfine transition of the ground state of cesium 133 at 198 0K (as an SI unit of time) [BI06]. 200 o Leap seconds: an extra second irregularly inserted into or 201 removed from the UTC time scale (based on SI seconds, see Sec. 202 4.2) to maintain it within 0.9 SI seconds of UT1 (based on solar 203 days, see Sec. 4.2). 205 o Offset: an interval added or subtracted from a date or clock to 206 convert between time scales with different epochs and leap 207 seconds. 209 o Local time: a variation of a time scale intended to approximate 210 that time scale at a given geographic location relative to that 211 time scale at a reference geographic location, indicated as an 212 offset. 214 o Time zone: an offset defined within a geographic region, used to 215 compute local time. 217 4. Background 219 There are a variety of types of time scales in widespread use for 220 scientific, civil, and computational purposes. Scientific time is 221 based on the International System (SI) standard definition of a 222 second based on atomic clocks, and its goal is to provide a uniform 223 standard for the passage of time. Civil time is based on the 224 rotation of the earth, and its goal is to ensure that a single 225 geographic location has the same reference to the sun at the same 226 time each day, including variations that support localized time to 227 approximate that effect for other locations around the earth. 228 Computational time is an approximation of civil time that is 229 intended to be inexpensive for computers to maintain without 230 external information. 232 Each of these time scales has different properties. Scientific time 233 is intended to be continuous and uniform, so that one second of 234 elapsed time always has the effect of moving a scientific clock 235 forward one second. Civil time can be non-continuous, such as when 236 leap seconds or leap days are added to compensate for the difference 237 between elapsed time and the rotation of the earth relative to the 238 sun. Computational time can be non-uniform, such as when Unix system 239 clocks are sped up to synchronize with civil time in a way intended 240 to avoid discontinuity. 242 Each of these types of time scales also has different primary uses. 243 Scientific time ensures uniform comparison of elapsed time and event 244 ordering. Civil time is used by people and their governments. 245 Computational time is used by computers to approximate other time 246 systems. Time represented in each of these systems can be converted 247 to other representations, given sufficient additional information. 249 Time is used throughout the Internet, to govern protocols (e.g., 250 timers in TCP [RFC793]), to improve efficiency (e.g., TCP RTT 251 estimation using timestamps [RFC7323]), as well as to indicate a 252 correlation with civilian time (e.g., NTP [RFC5905] and calendars 253 [RFC5545]). Each of these types of uses has distinct requirements on 254 the kind of time used. 256 4.1. Time uses and properties 258 Protocols use time for three primary purposes: 260 o Ordering: to determine the relative sequence of events across 261 systems, such as with Lamport clocks [La78]. 263 o Determining intervals: to determine actions to occur in a 264 protocol in the absence of user requests and received messages 265 (e.g., timers in TCP [RFC793]), to interact with physical systems 266 (e.g., generating symbols at a given rate on a link), or to 267 determine performance. 269 o Interacting with people: to exchange dates with the real world, 270 as when indicating the civil date of an email transmission 271 [RFC3339], web page [ISO98], or managing calendars [RFC5545]. 273 Each of these uses mandates a key property. Ordering requires that a 274 time reference is monotonic and increasing, such that the time 275 reference values change between any two events whose order needs to 276 be established. Accurate interval calculation requires that a time 277 reference also be continuous and uniform, such that the calculated 278 differences between any two dates separated by the same interval 279 yield the same value. Interacting with people requires the use of a 280 time reference they already use, so that expressed dates have known 281 meaning. 283 These properties are not all supported by the variety of time 284 references in widespread use. Some insert leap seconds and leap 285 days, introducing discontinuities. Some vary their basic interval 286 unit (e.g., to accommodate astronomical variances), which undermines 287 their uniformity. These issues affect the choice of time reference 288 and conversion between time references. 290 4.2. Time scales 292 The following is a description of the time scales in widespread use: 294 o TAI (International Atomic Time) [BI06]: a time scale based on the 295 SI second at mean sea level ("on the geoid"), determined post- 296 facto as a weighted average of a set of particular atomic clocks, 297 adjusted to account for relativistic effects. 299 o UT (Universal Time) [Mc09][Sa78]: a time scale based on the solar 300 day using zero degrees longitude as the earth location and a 301 specific astronomical location (originally the sun, but now more 302 distant objects). UT has several variants, of which the most 303 common is UT1 (where UT is often synonymous with UT1), which 304 includes corrections for earth axis variations. 306 o UTC (Coordinated Universal Time) [ITU02]: an approximation of UT 307 based on TAI adjusted with leap seconds. 309 o Ephemeris time [C61]: an astronomical time reference, originating 310 in Newcomb's tables [Ne1898] and standardized in 1952. 312 o Unix [OG08]: the POSIX/IEEE standard for Unix-based operating 313 system software, in which dates are defined as the number of 314 seconds that have elapsed since UTC 1970-1-1 00:00:00, increased 315 by exactly 86,400 seconds per day (note that neither 'day' nor 316 'second' is defined in Unix time). Note that this is not the same 317 as the POSIX time API (application programmer interface), which 318 provides access to a variety of time scales. 320 The following are somewhat secondary to the time scales above: 322 o DUT1 [IERS]: the number of leap seconds between the current TAI 323 date and the UTC epoch. 325 o GPS [Ha01]: the US Global Positioning System, defined as tracking 326 time as TAI + 19 SI seconds. 328 o GLONASS [RI98]: Russia's satellite clock system, defined as 329 tracking UTC. 331 o IRNSS/NAVIC [IRNSS]: The Indian Regional Navigation System. 333 o BeiDou-2 (prev. COMPASS) [NAE12]: China's satellite clock system. 335 o Galileo [Ga17]: the European Union's satellite clock system. 337 o NTP [RFC5905]: the Network Time Protocol, used in the Internet to 338 synchronize local clocks, in which dates are indicated by UTC 339 values. NTP times track the time of the clock they connect to. 341 4.3. Comparison of properties 343 Time scales can be compared using the following properties, in 344 addition to their epoch and the interval used as their unit of time: 346 o TAI error (Terr): a measure of the typically bounded precision on 347 dates in the given time scale vs. TAI. 349 o Continuous (Cont): are dates in this time scale continuous, i.e., 350 so that intervals can be calculated directly from the difference 351 in dates. 353 o Uniform (Unif): are dates in this time scale uniform, i.e., so 354 that all intervals of the same size represent the same amount of 355 time. 357 The table below describes the time scales considered herein. All 358 time scales use fixed epoch values except GLONASS, which reports 359 dates relative to the current UTC. UT can drift in comparison to TAI 360 by up to 0.9s, at which point a leap second is added. The satellite 361 systems (BeiDou-2, Galileo, GPS, GLONASS, and IRNSS/NAVIC) attempt 362 to track TAI, each with particular variances as design goals. NTP 363 varies from TAI because of network latency variations, except where 364 smearing is used [Go17]. Unix clocks typically use local quartz 365 oscillators as clocks, which can drift from TAI by 1-2s/week unless 366 continuously corrected, e.g., by NTP over the network. 368 Time scale Epoch Unit Terr Cont Unif 369 -------------------------------------------------------- 370 TAI 1977-01-01 SI - Yes Yes 371 UT 1582-10-15 solar 0.9s Yes No 372 UTC 1582-10-15 SI - No Yes 373 Unix 1970-01-01 undef ~100s Yes undef 375 (1) As specified [RFC5905], error as per the FAQ [NTPfaq] 376 (2) Some servers, notably Google's, 'smear' leap seconds [Go17] 377 * TAI comparisons from [Sa11] 379 TAI was designed to be both continuous and uniform. UT was designed 380 to be both uniform and track the solar day. The difference is 381 addressed in different ways in other time scales, which are largely 382 derived from these two. 384 Unix time does not specify the definition of a 'second' or 'day', 385 and so it is not clear whether it intends to track SI seconds (where 386 time would be uniform) or solar time (where it would not). 388 5. Systems that report time 390 Time scale Epoch Unit Terr Cont Unif 391 -------------------------------------------------------- 392 BeiDou-2 2006-01-01 SI 100ns* Yes Yes 393 Galilelo 1999-08-22 SI 50ns* Yes Yes 394 GLONASS UTC SI 1ms* No Yes 395 GPS 1980-01-06 SI 25ns* Yes Yes 396 IRNSS/NAVIC ? SI ? Yes Yes 397 NTP(1) 1900-01-01 SI ~100ms No Yes 398 NTP-smear(2) 1900-01-01 SI 1.1s Yes No 400 (1) As specified [RFC5905], error as per the FAQ [NTPfaq] 401 (2) Some servers, notably Google's, 'smear' leap seconds [Go17] 402 * TAI comparisons from [Sa11] 404 6. Computing time 406 The concurrent use of multiple time scales results in the need to 407 coordinate clocks and convert dates, and can complicate ordering. 408 Conversions require more context than just the time units and 409 epochs. It is also useful to be able to calculate the interval 410 between two dates within a single time scale. Each of these 411 calculations can require context, some of which cannot be statically 412 encoded. Ordering depends on monotonically increasing clocks, which 413 some time scales do not support. 415 6.1. Conversion 417 Dates in different time scales can be converted precisely as long as 418 both time scales are uniform. When both time scales are also 419 continuous, conversion is simple and relies only on the 420 specification of the time scales. If either time scale is 421 discontinuous, an additional table of discontinuities is required. 423 When either time scale is non-uniform, precise conversion is not 424 defined unless the non-uniformity is also precisely indicated. The 425 following subsections address each of these cases. 427 6.1.1. Continuous and uniform 429 For continuous and uniform time scales sharing the same unit of 430 time, the difference in epoch is sufficient to convert one scale to 431 the other, e.g.: 433 TS2_date = TS1_date - TS1_epoch + TS2_epoch 435 This conversion assumes both epochs are indicated in the same time 436 scale (or can be converted to such - if not, no conversion is 437 possible). For example, GPS reports the TAI date as an interval from 438 January 6, 1980, whereas TAI reports the date as an interval from 439 January 1, 1977, and both epochs are indicated in solar time. The 440 difference between those two epochs is exactly 95,040,019 SI 441 seconds, which is the total of 1,100 days of 86,400 SI seconds each 442 and an additional 19 SI seconds, needed to align the epochs 443 indicated as solar dates. As a result, dates indicated in 444 year/month/day/second format need only have their seconds values 445 adjusted as follows: 447 GPS_date = TAI_date + 19s 449 If time scales do not share the same unit of time, the conversion 450 needs to account for the difference in the intervals from epoch. For 451 example, a solar day is composed of 86,400 'solar seconds', but 452 approximately 86,400.002 SI seconds. Conversion now requires that 453 the epochs and units are expressed in a common time scale, and can 454 be computed as follows: 456 TS2_date = (TS1_date - TS1_epoch)/TS1_unit * TS2_unit + TS2_epoch 458 Converting a common time frame to local time further requires 459 knowing the location of each date and consulting a time zone 460 database, which is also available online [tzdb] [RFC7808]. In this 461 way, UTC can be converted to its local equivalent using a similar 462 lookup operation (where TZDB is the time zone database): 464 UTC_localdate = UTC_date + TZDB[UTC_date, local_location] 466 6.1.2. Uniform but not continuous 468 Changes in the rotation of the earth cause variations in the 469 difference between the unit of a second as defined by solar day, 470 tropical year, and SI methods. These differences are corrected by 471 introducing "leap seconds", which are added (or removed) on specific 472 dates [IERS]. E.g., UTC adds or removes leap seconds (known as DUT1) 473 to TAI on specific dates to help it approximate UT. 475 Leap second dates can be approximated using a known calculation, but 476 the exact date is determined administratively (rather than by 477 calculation). Those dates are announced several months in advance 478 and can be obtained online [tzdb][RFC6557][RFC7808]. As a 479 consequence, conversion accounting for leap seconds requires a 480 lookup operation (where "leapDB" is a database that indicates the 481 number of leap seconds added since the epoch): 483 UTC_date = TAI_date + leapDB[TAI_date] 485 Between dates when leap second dates, precise differences in solar 486 vs. SI time scales can be computed below 1s by accounting for the 487 ratio between a solar second and an SI second, but this is rarely 488 considered. 490 6.1.3. Not uniform 492 Some time scales are not uniform, i.e., the duration of an interval 493 is indicated in units that vary and so are not easily directly 494 comparable. Solar days vary by as much as 50 SI seconds because of 495 the earth's variation in its axis of rotation. Because a solar day 496 is defined as a fixed number of (solar) seconds, one solar second 497 varies by as much as 0.06%. This variability is not simple to 498 compute, but can be averaged out over long periods, but only in 499 hindsight. Similarly, the earth's orbit around the sun varies and is 500 slowing over time, resulting in an increasing stretching of a solar 501 second. 503 Some time scales replace discrete leap seconds with a leap smear, 504 stretching the interval of one second over 10-20 hours before the 505 corresponding leap second date [Go17]. This allows a time scale to 506 avoid discontinuities and non-conventional interval values (e.g., 507 minutes with 59 or 61 seconds). Smearing causes non-uniformity of 508 intervals that span the smear, especially because there is no 509 current standard for the smear interval or algorithm. 511 Additionally, some time scales have no precise conversion, e.g., GPS 512 is coordinated to within 25ns of TAI, but the exact difference is 513 known only as a post-facto measurement relative to NIST time (a 514 subset of the clocks used to compute TAI) [NG]. This occurs because 515 GPS uses its own set of atomic clocks rather than using the TAI 516 directly, and the same is true for other satellite systems. Other 517 time scales are imprecise by definition, as with Unix time, which is 518 based on clocks that vary widely by instance and with changes in 519 temperature. 521 6.1.4. Ordering 523 Events in a distributed system often require ordering to ensure 524 consistent views of their aggregate state [La78]. It can be 525 important to know whether a bank deposit occurs before a withdrawal 526 or if a license application has been submitted before a deadline. 528 Time scales that are continuous enable easy ordering of dates, e.g., 529 all dates comparisons correctly either indicate concurrence (when 530 dates match) or a specific order. Time scales that are discontinuous 531 can give false results, such as during a leap second. Consider the 532 UTC date encodings indicated in Figure 1. 534 Instant TAI date UTC encoding (61s minute) 535 -------------------------------------------------------- 536 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 537 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.5 538 C 2016-01-01T00:00:35.0 2016-12-31T23:59:60.0 539 D 2016-01-01T00:00:35.5 2016-12-31T23:59:60.5 540 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 542 Figure 1 Leap seconds with long minutes 544 In both cases, two SI seconds progress between instants A and E. 545 However, the last minute before midnight on December 31, 2016 has a 546 minute that lasts 61 seconds (0..61), rather than 60. Ordering of 547 these instants is unambiguous in this example. 549 Consider instead a system that cannot represent minutes with more 550 than 60 seconds. In such systems, the clock is either stalled or 551 delayed during a leap second insertion, resulting in repeated values 552 (Figure 2). Here, the order of instants B, C, and D cannot be 553 established accurately from the dates. Additionally, intervals that 554 span this "reset" are inaccurately calculated from date differences 555 unless explicitly corrected. 557 Instant TAI date UTC encoding (60s minute) 558 -------------------------------------------------------- 559 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 560 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.5 561 C 2016-01-01T00:00:35.0 2016-12-31T23:59:59.0 562 D 2016-01-01T00:00:35.5 2016-12-31T23:59:59.5 563 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 565 Figure 2 Leap seconds with repeating dates 567 Ordering can be restored using leap smear, as shown in Figure 3, but 568 at the expense of complicating the computation of intervals that 569 span the smear. 571 Instant TAI date UTC encoding (60s minute) 572 -------------------------------------------------------- 573 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 574 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.25 575 C 2016-01-01T00:00:35.0 2016-12-31T23:59:59.5 576 D 2016-01-01T00:00:35.5 2016-12-31T23:59:59.75 577 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 579 Figure 3 Leap seconds with smear 581 6.2. Calculating intervals 583 Intervals can be calculated directly between two dates of a uniform 584 time scale directly as the difference between two dates A and B as 585 follows (where "abs" is the absolute value function): 587 interval = abs(dateA - dateB) 589 It is important that the specification of an interval indicate 590 whether its endpoints are included or not, e.g., whether the 591 interval is open, half-open, or closed. In common mathematical 592 notation, the interval [1:24.00, 1:25.00] includes both 1:24.00 and 593 1:25.00. The interval [1.24.00, 1:25.00) starts at the instant of 594 1:24.00 and ends just before the instant of 1:25.00, i.e., 1:25.00 595 is excluded from the interval. System designers SHOULD clearly 596 indicate whether intervals include or exclude their start and end 597 instants. 599 A non-continuous time scale requires external information, e.g., the 600 leap second dates that occur during the interval. Computing 601 intervals in these time scales requires that the representation does 602 not repeat or smear time. The interval is computed by converting 603 non-continuous time to continuous time by removing the effect of 604 leap seconds and proceeding as with the continuous case, as follows: 606 interval = abs((dateA - leapDB(dateA)) - (dateB - leapDB(dateB))) 608 Non-uniform time scale intervals can sometimes be calculated, but 609 this is rarely supported. 611 7. Advice 613 No single time scale serves all purposes. Use of multiple time 614 scales requires conversion, which often requires external 615 information. Maintaining accurate clocks can also require external 616 information (to insert leap seconds), as can the computation of 617 intervals. 619 7.1. Selection advice 621 A primary time scale SHOULD be chosen from among existing time 622 scales, if possible. Creating a new time scale increases complexity 623 and is unlikely to avoid the issues already present with existing 624 time scales, e.g., being continuous, uniform, requiring conversion, 625 or needing external information for conversion or interval 626 computation. 628 A primary time scale SHOULD be chosen to minimize the need for 629 repeated conversion and/or to minimize the complexity of computing 630 intervals, depending on the expected frequency of these operations. 632 For example, if synchronizing clocks with other systems using NTP is 633 the primary goal, implementers would probably select UTC [RFC5905]. 634 If user presentation is primary, as for email or calendaring, 635 implementers would probably select local time [RFC5545]. If interval 636 computation is primary, implementers would probably select TAI. 638 As a consequence, in most cases, implementers SHOULD select either 639 TAI or UTC, or a system that closely approximates these (e.g., GPS- 640 like systems or NTP), and expect to maintain updated leap second 641 information [RFC7808]. 643 7.2. Hazards 645 Incorrect time scale selection can result in increased computational 646 overhead and the need for increased storage. External information 647 might be needed for conversion, or conversion or calculation may not 648 be possible (as with smearing). 650 Implementers SHOULD NOT use time scales that smear, for two reasons. 651 First, there is no current standard for leap smearing, so the same 652 time scale implemented on different systems are likely to indicate 653 incorrect relative dates (i.e., incorrectly indicating instance 654 ordering). Second, leap smearing complicates interval measurements 655 computed over the smear which can be difficult to compensate. 657 8. Security Considerations 659 Time is used within security systems for a variety of reasons, 660 including indicating the validity of certificates used for 661 encryption and authentication [RFC5280]. Inaccurate dates, 662 intervals, or ordering can affect the ability to use these 663 protocols. 665 As a result, it can be important to secure the protocols used to 666 coordinate time [RFC7384]. NTP, the most common such protocol, 667 supports secure operation [RFC5905]. 669 9. IANA Considerations 671 This document has no IANA considerations. This section should be 672 removed prior to publication as an RFC. 674 10. References 676 10.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 10.2. Informative References 683 [BI06] Bureau International des Poids et Mesures (International 684 Bureau of Weights and Measures), "The International System 685 of Units (SI)," 8th Edition, 2006. 687 [C61] http://www.bipm.org/en/CGPM/db/11/9/ Comptes Rendus de la 688 11e CGPM (1960), 1961, p.86 690 [Ga17] Galileo system web pages, http://galileognss.eu/gst- 691 galileo-system-time/ 693 [Go17] Google's approach to NTP leap smearing, proposed in 2017. 694 https://developers.google.com/time/smear 696 [Ha01] Hoffman-Wellenhof, B., H. Lichtenegger, J. Collins. Global 697 positioning system: theory and practice. New York, 698 Springer-Verlag, 2001. 700 [IERS] International Earth Rotation and Reference Systems Service 701 (IERS). https://www.iers.org/ 703 [IRNSS] Global Indian Navigation Satellites: Constellation 704 studies, August ISRO-ISAC-IRNSS-TR-0887, 2009. 706 [ISO98] International Standards Organization, "Data elements and 707 interchange formats - Information interchange - 708 Representation of dates and times", ISO 8601, 1988. 710 [ITU02] International Telecommunication Union, "Standard-frequency 711 and time-signal emissions," ITU-R Recommendations and 712 Reports, TF.460-6, 2002. 714 [La78] Lamport, L., "Time, Clocks, and the Ordering of Events in 715 a Distributed System," Communications of the ACM, V21 N7, 716 Jul. 1978, pp. 558-565. 718 [Mc09] McCarthy, D., P. Seidelmann, "Time Applications," in Time 719 - From Earth Rotation to Atomic Physics, Wiley-VCH, 2009. 720 doi: 10.1002/9783527627943.ch19 722 [NAE12] National Academy of Engineering, "Global Navigation 723 Satellite Systems," National Academies Press, ISBN 978-0- 724 309-22275-4, 2012. 726 [Ne1898] Newcomb, S., Tables of the Four Inner Planets," Second 727 Edition, 1898. 728 https://ia801005.us.archive.org/11/items/06AstronomicalPap 729 ersPreparedForTheUse/06- 730 Astronomical_Papers_Prepared_for_the_Use_text.pdf 732 [NG] NIST vs. GPS time, https://www.nist.gov/pml/time-and- 733 frequency-division/services/gps-data-archive 735 [NTPfaq] NTP FAQ pages, http://www.ntp.org/ntpfaq/NTP-s-algo.htm 737 [OG08] The Open Group, "Base Specifications, Issue 7, 2016 738 Edition," IEEE Std 1003.1 / POSIX.1-2008, 2008. 740 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 741 September 1981. 743 [RFC3339] Klyne, G., C. Newman, "Date and Time on the Internet: 744 Timestamps," RFC 3339, July 2002. 746 [RFC5280] Cooper, D., S. Santesson, S. Farrell, S. Boeyen, R. 747 Housley, W. Polk, "Internet X.509 Public Key 748 Infrastructure Certificate and Certificate Revocation List 749 (CRL) Profile," RFC 5280, May 2008. 751 [RFC5545] Desruisseaux, B. (Ed.), "Internet Calendaring and 752 Scheduling Core Object Specification (iCalendar)," RFC 753 5545, Sep. 2009. 755 [RFC5905] Mills, D., J. Martin (Ed.), J. Burbank, W. Kasch, "Network 756 Time Protocol Version 4: Protocol and Algorithms 757 Specification," RFC 5905, June 2010. 759 [RFC6557] Lear, E., P. Eggert, "Procedures for Maintaining the Time 760 Zone Database," RFC 6557, BCP 175, Feb. 2012. 762 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 763 (Ed.), "TCP Extensions for High Performance," RFC 7323, 764 Sep. 2014. 766 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 767 Packet Switched Networks," RFC 7384, Oct. 2014. 769 [RFC7808] Douglass, M., C. Daboo, "Time Zone Data Distribution 770 Service," RFC 7808, Mar. 2016. 772 [RI98] Russian Institute of Space Device Engineering, "GLONASS 773 Interface Control Document", 1998. 775 [Sa78] Sadler, D., "Mean Solar Time on the Meridian of 776 Greenwich," Quarterly Journal of the Roayal Astronomical 777 Society, V19, Sept. 1978, p.290. 778 http://adsabs.harvard.edu/cgi-bin/nph- 779 bib_query?bibcode=1978QJRAS..19..290S 781 [Sa11] Sanz Subirana, J., J. Juan Zornoza, M. Hernandez-Pajares, 782 "Time References in GNSS," Navipedia web pages, 2011. 783 http://www.navipedia.net/index.php/Time_References_in_GNSS 785 [tzdb] Time zone database, https://www.iana.org/time-zones 787 11. Acknowledgments 789 This work originated in response to a proposal for a new continuous 790 time scale by Phillip Hallam-Baker, and benefitted from discussion 791 on the IETF list, notably Steve Allen, Patrik Falstrom, Tony Finch, 792 Nicholas Mailhot, Michael Thornburgh, and Nico Williams. 794 This work is partly supported by USC/ISI's Postel Center. 796 This document was prepared using 2-Word-v2.0.template.dot. 798 Authors' Addresses 800 Joe Touch 802 Manhattan Beach, CA 90266 USA 804 Phone: +1 (310) 560-0334 805 Email: touch@strayalpha.com 807 Change Log: 809 draft-touch-time-03: 811 Revise doc to more clearly target summarized recommendations. 813 Sec 4.2 definitions revised based on feedback: 815 - solar day now defined as two different things? 817 - another scrub of existing definitions 819 draft-touch-time-02: 821 Sec 4.2 definitions revised based on feedback 823 Explain difference between Unix time and POSIX time API 825 draft-touch-time-01: 827 Sec 1 expanded to include list of recommendations. 829 Sec 5.2 more detailed description of intervals. 831 draft-touch-time-00: 833 (original version)