idnits 2.17.1 draft-touch-time-06.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 408 has weird spacing: '...ch date unde...' -- The document date (November 19, 2019) is 1619 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) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ARTWG J. Touch 2 Internet Draft Independent consultant 3 Intended status: Best Current Practice November 19, 2019 4 Expires: May 2020 6 Resolving Multiple Time Scales in the Internet 7 draft-touch-time-06.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 May 19, 2020. 34 Copyright Notice 36 Copyright (c) 2019 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......................................10 64 6. Computing time................................................10 65 6.1. Conversion...............................................10 66 6.1.1. Continuous and uniform..............................11 67 6.1.2. Uniform but not continuous..........................11 68 6.1.3. Not uniform.........................................12 69 6.1.4. Ordering............................................13 70 6.2. Calculating intervals....................................14 71 7. Advice........................................................15 72 7.1. Selecting a time scale...................................15 73 7.2. Hazards of some time scales..............................15 74 7.3. Alternate solutions for ordering.........................16 75 8. Security Considerations.......................................16 76 9. IANA Considerations...........................................16 77 10. References...................................................17 78 10.1. Normative References....................................17 79 10.2. Informative References..................................17 80 11. Acknowledgments..............................................19 82 1. Introduction 84 A popular proverb reads, "a person with one clock always knows what 85 time it is; a person with two clocks is never sure." Unfortunately, 86 Internet systems rely on a variety of time references that often 87 need to be reconciled. This document attempts to explain this issue 88 and provide advice on how to avoid temporal ambiguity. 90 There are various standards for expressing time, including Universal 91 Coordinated Time (UTC) [ITU02], local time (UTC adjusted for time 92 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 or revisions to daylight savings time shifts). These 106 discontinuities complicate interval computation, the latter 107 requiring externally provided context (a table of mandated leap 108 seconds and their scheduled occurrences). Other fine frames are non- 109 uniform, in which the duration of an interval (e.g., a day, a year, 110 or even a second) varies depending on its offset. 112 Despite many attempts, there is no single time scale that supports 113 all common uses easily and without the need for updated external 114 information. As a preview, this document makes the following 115 recommendations for system designers: 117 1. System designers SHOULD NOT invent their own time scale. There 118 are no simpler solutions and more than enough existing variants, 119 although there is no known reason to exclude new variants. 121 2. System designers SHOULD use one time scale as their primary 122 reference and derive all other time scales by conversion, to 123 avoid confusion. Exceptions might optimize for more than one use. 125 3. System designers SHOULD use UTC as their primary time scale 126 because it is most commonly accepted by governments and the basis 127 for the Internet time [RFC3339] (based on ISO 8601 [ISO98]) and 128 the Network Time Protocol (NTP) [RFC5905]. Exceptions optimize 129 computation, e.g., to use TAI [BI06] for interval calculation or 130 local time [ISO98] for user interaction, e.g., calendars. 132 4. System designers SHOULD include location context (e.g., location 133 or zone) as a part of all dates and MUST include that information 134 if conversion to and between civil and local time is required. 136 5. System designers SHOULD maintain updated information regarding 137 leap seconds and time zones and MUST maintain that information if 138 accurate intervals or civil conversions are required. 140 6. System designers SHOULD be explicit about indicating whether 141 intervals are inclusive or exclusive of start and end dates. 142 Doing otherwise is an opportunity for ambiguity. 144 7. System designers SHOULD be very clear about whether timers expire 145 on a date or when an interval has passed, to help understand the 146 impact of continuous and monotonic aspects of time scales. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Terminology 158 The following terminology is used in this document. Note that some 159 units are presented as "generally defined" (provided as 160 approximations), whereas others are "precisely defined" (provided as 161 specific). 163 o Instant: a specific moment in time. 165 o Time scale: a system for assigning names to intervals and dates. 167 o Interval: the elapsed time between instants. 169 o Date: the name of an instant in a time scale, typically indicated 170 as an interval from an epoch. 172 o Epoch: an instant used as the origin (zero) of a time scale. 174 o Onset: an instant after which a time scale is valid. This term is 175 introduced in this document. 177 o Expiry: an instant after which a time scale is invalid, in 178 contrast to the onset. This term is introduced in this document. 179 It applies most notably to the Julian calendar. 181 o Clock: a mechanism indicating the current date in a time scale. 183 o Civil time (or date): a time scale (or date) selected by a 184 government authority. 186 o Solar day: a unit of time generally defined as the interval of 187 one rotation of the earth as measured between the repeated 188 position of the sun in the sky as viewed from a fixed location. 189 Solar time relative to a single daily position is "apparent solar 190 time". Solar time indicated as a mean over a year (one orbit of 191 the earth around the sun) is "mean solar time". A given solar day 192 can vary by as much as 30 seconds vs. the mean. 194 o Tropical year: a unit of time generally defined by the interval 195 of one rotation of the earth around the sun as measured using the 196 position of the sun in the sky in the same way as a solar day. 198 o Second: the unit of time, which has multiple definitions whose 199 values differ, only the last of which is precise; others are 200 derived from "generally defined" units: 202 o 1/(24 * 60 * 60) of a solar day. 204 o 1/(31,556,925.9747) of a tropical year as of the instant of 205 1900 "January 0" (i.e., December 31) at 12:00:00 Ephemeris 206 time (Ephemeris time is defined later herein) [C61]. 208 o Exactly 9192631770 periods of the radiation corresponding to 209 the hyperfine transition of the ground state of cesium 133 at 210 0K (precisely defined as an SI unit of time) [BI06]. 212 o Leap seconds: an extra second irregularly inserted into or 213 removed from the UTC time scale (based on SI seconds, see Sec. 214 4.2) to maintain it within 0.9 SI seconds of UT1 (based on solar 215 days, see Sec. 4.2). 217 o Offset: an interval added or subtracted from a date or clock to 218 convert between time scales with different epochs and leap 219 seconds. 221 o Local time: a variation of a time scale intended to approximate 222 that time scale at a given geographic location relative to that 223 time scale at a reference geographic location, indicated as an 224 offset. 226 o Time zone: an offset defined within a geographic region, used to 227 compute local time. 229 4. Background 231 There are a variety of types of time scales in widespread use for 232 scientific, civil, and computational purposes. Scientific time is 233 based on the International System (SI) standard definition of a 234 second based on atomic clocks, and its goal is to provide a uniform 235 standard for the passage of time. Civil time is based on the 236 rotation of the earth and it attempts to coordinate a single 237 geographic location with the same reference to the sun at the same 238 time each day, including variations that support localized time to 239 approximate that effect for other locations around the earth. 240 Computational time is an approximation of civil time that is 241 intended to be inexpensive for computers to maintain without 242 external information. 244 Each of these time scales has different properties. Scientific time 245 is intended to be continuous and uniform, so that one second of 246 elapsed time always has the effect of moving a scientific clock 247 forward one second. Civil time can be non-continuous, such as when 248 leap seconds or leap days are added to compensate for the difference 249 between elapsed time and the rotation of the earth relative to the 250 sun. Computational time can be non-uniform, such as when the rate of 251 Unix system clocks are varied to synchronize with civil time in a 252 way intended to avoid discontinuity. 254 Each of these types of time scales also has different primary uses. 255 Scientific time ensures uniform comparison of elapsed time and event 256 ordering. Civil time is used by people and their governments. 257 Computational time is used by computers to approximate other time 258 systems. Time represented in each of these systems can be converted 259 to other representations, given sufficient additional information. 261 Time is used throughout the Internet, to govern protocols (e.g., 262 timers in TCP [RFC793]), to improve efficiency (e.g., TCP RTT 263 estimation using timestamps [RFC7323]), as well as to indicate a 264 correlation with civilian time (e.g., NTP [RFC5905] and calendars 265 [RFC5545]). Each of these types of uses has distinct requirements on 266 the kind of time used. 268 4.1. Time uses and properties 270 Protocols use time for three primary purposes: 272 o Ordering: to determine the relative sequence of events across 273 systems, such as with Lamport clocks [La78] or Vector clocks 274 [Fi88][Ma88]. 276 o Determining intervals: to determine actions to occur in a 277 protocol in the absence of user requests and received messages 278 (e.g., timers in TCP [RFC793]), to interact with physical systems 279 (e.g., generating symbols at a given rate on a link), or to 280 determine performance. 282 o Interacting with people: to exchange dates with the real world, 283 as when indicating the civil date of an email transmission 284 [RFC5321], web page [RFC7231], or managing calendars [RFC5545]. 286 Each of these uses mandates a key property. Ordering requires that a 287 time reference is monotonic and increasing, such that the time 288 reference values change between any two events whose order needs to 289 be established. Accurate interval calculation requires that a time 290 reference also be continuous and uniform, such that the calculated 291 differences between any two dates separated by the same interval 292 yield the same value. Interacting with people requires the use of a 293 time reference they already use, so that expressed dates have known 294 meaning. 296 These properties are not all supported by the variety of time 297 references in widespread use. Some insert leap seconds and leap 298 days, introducing discontinuities. Some vary their basic interval 299 unit (e.g., to accommodate astronomical variances), which undermines 300 their uniformity. These issues affect the choice of time reference 301 and conversion between time references. 303 4.2. Time scales 305 The following is a description of the time scales in widespread use: 307 o TAI (International Atomic Time) [BI06]: a time scale based on the 308 SI second at mean sea level ("on the geoid"), determined post- 309 facto as a weighted average of a set of particular atomic clocks, 310 adjusted to account for relativistic effects. 312 o UT (Universal Time) [Mc09][Sa78]: a time scale based on the solar 313 day using zero degrees longitude as the earth location and a 314 specific astronomical location (originally the sun, but now more 315 distant objects). UT has several variants, of which the most 316 common is UT1 (where UT is often synonymous with UT1), which 317 includes corrections for earth axis variations. 319 o UTC (Coordinated Universal Time) [ITU02]: an approximation of UT 320 based on TAI adjusted with leap seconds. 322 o Ephemeris time [C61]: an astronomical time reference, originating 323 in Newcomb's tables [Ne1898] and standardized in 1952. 325 o Unix [OG08]: the POSIX/IEEE standard for Unix-based operating 326 system software, in which dates are defined as the number of 327 seconds that have elapsed since UTC 1970-1-1 00:00:00, increased 328 by exactly 86,400 seconds per day (note that neither 'day' nor 329 'second' is defined in Unix time). Note that this is not the same 330 as the POSIX time API (application programmer interface), which 331 provides access to a variety of time scales. 333 The following are somewhat secondary to the time scales above: 335 o DUT1 [IERS]: the number of leap seconds between the current TAI 336 date and the UTC epoch. 338 o GPS [Ha01]: the US Global Positioning System, defined as tracking 339 time as TAI + 19 SI seconds. 341 o GLONASS [RI98]: Russia's satellite clock system, defined as 342 tracking UTC. 344 o IRNSS/NAVIC [IRNSS]: The Indian Regional Navigation System. 346 o BeiDou-2 (prev. COMPASS) [NAE12]: China's satellite clock system. 348 o Galileo [Ga17]: the European Union's satellite clock system. 350 o NTP [RFC5905]: the Network Time Protocol, used in the Internet to 351 synchronize local clocks, in which dates are indicated by UTC 352 values. NTP times track the time of the clock they connect to. 354 Some of these time scales have a single reported value, such as GPS 355 and NTP time. In other cases, the time scale is a weighted aggregate 356 of contributions that are individually reported as well, such as UTC 357 vs the component contributed by the U.S. Naval Observatory 358 (UTC(USNO)) or the US National Institute of Standards and Time 359 (UTC(NIST)). These components vary from their weighted averages, 360 typically varying by only a few nanoseconds. 362 4.3. Comparison of properties 364 Time scales can be compared using the following properties, in 365 addition to their epoch and the interval used as their unit of time: 367 o TAI error (Terr): a measure of the typically bounded precision on 368 dates in the given time scale vs. TAI. 370 o Continuous (Cont): are dates in this time scale continuous, i.e., 371 so that intervals can be calculated directly from the difference 372 in dates. 374 o Uniform (Unif): are dates in this time scale uniform, i.e., so 375 that all intervals of the same size represent the same amount of 376 time. 378 o Onset (and expiry): the date after which a time scale is valid 379 (or no longer valid), as introduced by this document. 381 Onset and expiry are not commonly indicated in many time scales. 382 They are introduced here to help explain the difference between the 383 zero time (epoch) of a time scale and the validity period of a time 384 scale. Some time scales have no invalidity period, i.e., their onset 385 is infinitely negative in the past, notably when values can be 386 negative relative to their epoch. The Julian calendar has an expiry 387 of 1852-10-05 and the Gregorian calendar has an onset of 1852-10-15, 388 even though both calendars have an epoch of 0 AD and both calendars 389 have been projected to dates in the past (at which point the 390 difference is often not relevant, e.g., 100 BC). 392 The table below describes the time scales considered herein. All 393 time scales use fixed epoch values except GLONASS, which reports 394 dates relative to the current UTC. UT can drift in comparison to TAI 395 by up to 0.9s, at which point a leap second is added. The satellite 396 systems (BeiDou-2, Galileo, GPS, GLONASS, and IRNSS/NAVIC) attempt 397 to track TAI, each with particular variances as design goals. NTP 398 varies from TAI because of network latency variations, except where 399 smearing is used [Go17]. Unix clocks typically use local quartz 400 oscillators as clocks, which can drift from TAI by 1-2s/week unless 401 continuously corrected, e.g., by NTP over the network. 403 Time scale Epoch Onset Unit Terr Cont Unif 404 ----------------------------------------------------------------- 405 TAI 1977-01-01 1960-01-01 SI - Yes Yes 406 UT 0 AD (1) 1848-10-22 solar 0.9s Yes No 407 UTC 0 AD (1) 1972-01-01 SI - No Yes 408 Unix 1970-01-01 epoch date undef ~100s Yes undef 410 (1) The epoch of UT and UCT is when all fields are zero. Although 411 time is expressed relative to that date, it precedes the onset. The 412 onset dates indicate the onset of the most recent definition of the 413 time scale indicated. 415 TAI was designed to be both continuous and uniform. UT was designed 416 to be both uniform and track the solar day. The difference is 417 addressed in different ways in other time scales, which are largely 418 derived from these two. 420 Unix time does not specify the definition of a 'second' or 'day', 421 and so it is not clear whether it intends to track SI seconds (where 422 time would be uniform) or solar time (where it would not). 424 5. Systems that report time 426 The following is a partial listing of widely used systems that 427 report time. 429 Time scale Epoch Unit Terr Cont Unif 430 -------------------------------------------------------- 431 BeiDou-2 2006-01-01 SI 100ns* Yes Yes 432 Galilelo 1999-08-22 SI 50ns* Yes Yes 433 GLONASS UTC SI 1ms* No Yes 434 GPS 1980-01-06 SI 25ns* Yes Yes 435 IRNSS/NAVIC ? SI ? Yes Yes 436 NTP(1) 1900-01-01 SI ~100ms No Yes 437 NTP-smear(2) 1900-01-01 SI 1.1s Yes No 439 (1) As specified [RFC5905], error as per the FAQ [NTPfaq] 440 (2) Some servers, notably Google's, 'smear' leap seconds [Go17] 441 * TAI comparisons from [Sa11] 443 6. Computing time 445 The concurrent use of multiple time scales results in the need to 446 coordinate clocks and convert dates, and can complicate ordering. 447 Conversions require more context than just the time units and 448 epochs. It is also useful to be able to calculate the interval 449 between two dates within a single time scale. Each of these 450 calculations can require context, some of which cannot be statically 451 encoded. Ordering depends on monotonically increasing clocks, which 452 some time scales do not support. 454 6.1. Conversion 456 Dates in different time scales can be converted precisely as long as 457 both time scales are uniform. When both time scales are also 458 continuous, conversion is simple and relies only on the 459 specification of the time scales. If either time scale is 460 discontinuous, an additional table of discontinuities is required. 462 When either time scale is non-uniform, precise conversion is not 463 defined unless the non-uniformity is also precisely indicated. The 464 following subsections address each of these cases. 466 6.1.1. Continuous and uniform 468 For continuous and uniform time scales sharing the same unit of 469 time, the difference in epoch is sufficient to convert one scale to 470 the other, e.g.: 472 TS2_date = TS1_date - TS1_epoch + TS2_epoch 474 This conversion assumes both epochs are indicated in the same time 475 scale (or can be converted to such - if not, no conversion is 476 possible). For example, GPS reports the TAI date as an interval from 477 January 6, 1980, whereas TAI reports the date as an interval from 478 January 1, 1977, and both epochs are indicated in solar time. The 479 difference between those two epochs is exactly 95,040,019 SI 480 seconds, which is the total of 1,100 days of 86,400 SI seconds each 481 and an additional 19 SI seconds, needed to align the epochs 482 indicated as solar dates. As a result, dates indicated in 483 year/month/day/second format need only have their seconds values 484 adjusted as follows: 486 GPS_date = TAI_date + 19s 488 If time scales do not share the same unit of time, the conversion 489 needs to account for the difference in the intervals from epoch. For 490 example, a solar day is composed of 86,400 'solar seconds', but 491 approximately 86,400.002 SI seconds. Conversion now requires that 492 the epochs and units are expressed in a common time scale, and can 493 be computed as follows: 495 TS2_date = (TS1_date - TS1_epoch)/TS1_unit * TS2_unit + TS2_epoch 497 Converting a common time frame to local time further requires 498 knowing the location of each date and consulting a time zone 499 database, which is also available online [tzdb] [RFC7808]. In this 500 way, UTC can be converted to its local equivalent using a similar 501 lookup operation (where TZDB is the time zone database): 503 UTC_localdate = UTC_date + TZDB[UTC_date, local_location] 505 6.1.2. Uniform but not continuous 507 Changes in the rotation of the earth cause variations in the 508 difference between the unit of a second as defined by solar day, 509 tropical year, and SI methods. These differences are corrected by 510 introducing "leap seconds", which are added (or removed) on specific 511 dates [IERS]. E.g., UTC adds or removes leap seconds (known as DUT1) 512 to TAI on specific dates to help it approximate UT. 514 Leap second dates can be approximated using a known calculation, but 515 the exact date is determined administratively (rather than by 516 calculation). Those dates are announced several months in advance 517 and can be obtained online [tzdb][RFC6557][RFC7808]. As a 518 consequence, conversion accounting for leap seconds requires a 519 lookup operation (where "leapDB" is a database that indicates the 520 number of leap seconds added since the epoch): 522 UTC_date = TAI_date + leapDB[TAI_date] 524 Between dates when leap second dates, precise differences in solar 525 vs. SI time scales can be computed below 1s by accounting for the 526 ratio between a solar second and an SI second, but this is rarely 527 considered. 529 6.1.3. Not uniform 531 Some time scales are not uniform, i.e., the duration of an interval 532 is indicated in units that vary and so are not easily directly 533 comparable. Solar days vary by as much as 50 SI seconds because of 534 the earth's variation in its axis of rotation. Because a solar day 535 is defined as a fixed number of (solar) seconds, one solar second 536 varies by as much as 0.06%. This variability is not simple to 537 compute, but can be averaged out over long periods, but only in 538 hindsight. Similarly, the earth's orbit around the sun varies and is 539 slowing over time, resulting in an increasing stretching of a solar 540 second. 542 Some time scales replace discrete leap seconds with a leap smear, 543 stretching the interval of one second over 10-20 hours before (and 544 sometimes after) the corresponding leap second date [Go17]. This 545 allows a time scale to avoid discontinuities and non-conventional 546 interval values (e.g., minutes with 59 or 61 seconds). Smearing 547 causes non-uniformity of intervals that span the smear, especially 548 because there is no current standard for the smear interval or 549 algorithm. 551 Additionally, some time scales have no precise conversion, e.g., GPS 552 is coordinated to within 25ns of TAI, but the exact difference is 553 known only as a post-facto measurement relative to NIST time (a 554 subset of the clocks used to compute TAI) [NG]. This occurs because 555 GPS uses its own set of atomic clocks rather than using the TAI 556 directly, and the same is true for other satellite systems. Other 557 time scales are imprecise by definition, as with Unix time, which is 558 based on clocks that vary widely by instance and with changes in 559 temperature. 561 6.1.4. Ordering 563 Events in a distributed system often require ordering to ensure 564 consistent views of their aggregate state [La78]. It can be 565 important to know whether a bank deposit occurs before a withdrawal 566 or if a license application has been submitted before a deadline. 567 This can be accomplished for individual events using simple counters 568 (Lamport clocks) but can become unwieldy for coordinating pairs or 569 groups of events (Vector clocks [Fi88][Ma88]). Time scales can 570 provide an alternative to these ordering mechanisms. 572 Time scales that are continuous enable easy ordering of dates, e.g., 573 all dates comparisons correctly either indicate concurrence (when 574 dates match) or a specific order. Time scales that are discontinuous 575 can give false results, such as during a leap second. Consider the 576 UTC date encodings indicated in Figure 1. 578 Instant TAI date UTC encoding (61s minute) 579 -------------------------------------------------------- 580 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 581 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.5 582 C 2016-01-01T00:00:35.0 2016-12-31T23:59:60.0 583 D 2016-01-01T00:00:35.5 2016-12-31T23:59:60.5 584 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 586 Figure 1 Leap seconds with long minutes 588 In both cases, two SI seconds progress between instants A and E. 589 However, the last minute before midnight on December 31, 2016 has a 590 minute that lasts 61 seconds (0..61), rather than 60. Ordering of 591 these instants is unambiguous in this example. 593 Consider instead a system that cannot represent minutes with more 594 than 60 seconds. In such systems, the clock is either stalled or 595 delayed during a leap second insertion, resulting in repeated values 596 (Figure 2). Here, the order of instants B, C, and D cannot be 597 established accurately from the dates. Additionally, intervals that 598 span this "reset" are inaccurately calculated from date differences 599 unless explicitly corrected. 601 Instant TAI date UTC encoding (60s minute) 602 -------------------------------------------------------- 603 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 604 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.5 605 C 2016-01-01T00:00:35.0 2016-12-31T23:59:59.0 606 D 2016-01-01T00:00:35.5 2016-12-31T23:59:59.5 607 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 609 Figure 2 Leap seconds with repeating dates 611 Ordering can be restored using leap smear, as shown in Figure 3, but 612 at the expense of complicating the computation of intervals that 613 span the duration of the smear, which can be several hours. 615 Instant TAI date UTC encoding (60s minute) 616 -------------------------------------------------------- 617 A 2016-01-01T00:00:34.0 2016-12-31T23:59:59.0 618 B 2016-01-01T00:00:34.5 2016-12-31T23:59:59.25 619 C 2016-01-01T00:00:35.0 2016-12-31T23:59:59.5 620 D 2016-01-01T00:00:35.5 2016-12-31T23:59:59.75 621 E 2016-01-01T00:00:36.0 2016-01-01T00:00:00.0 623 Figure 3 Leap seconds with smear 625 6.2. Calculating intervals 627 Intervals can be calculated directly between two dates of a uniform 628 time scale directly as the difference between two dates A and B as 629 follows (where "abs" is the absolute value function): 631 interval = abs(dateA - dateB) 633 It is important that the specification of an interval indicate 634 whether its endpoints are included or not, e.g., whether the 635 interval is open, half-open, or closed. In common mathematical 636 notation, the interval [1:24.00, 1:25.00] includes both 1:24.00 and 637 1:25.00. The interval [1.24.00, 1:25.00) starts at the instant of 638 1:24.00 and ends just before the instant of 1:25.00, i.e., 1:25.00 639 is excluded from the interval. System designers SHOULD clearly 640 indicate whether intervals include or exclude their start and end 641 instants. 643 A non-continuous time scale requires external information, e.g., the 644 leap second dates that occur during the interval. Computing 645 intervals in these time scales requires that the representation does 646 not repeat or smear time. The interval is computed by converting 647 non-continuous time to continuous time by removing the effect of 648 leap seconds and proceeding as with the continuous case, as follows: 650 interval = abs((dateA - leapDB(dateA)) - (dateB - leapDB(dateB))) 652 Non-uniform time scale intervals can sometimes be calculated, but 653 this is rarely supported. Computing intervals into the future can be 654 hazardous due to unpredicted changes, e.g., the addition of future 655 leap seconds or changes in time zones and daylight savings time. 657 7. Advice 659 No single time scale serves all purposes. Use of multiple time 660 scales requires conversion, which often requires external 661 information. Maintaining accurate clocks can also require external 662 information (to insert leap seconds), as can the computation of 663 intervals. 665 7.1. Selecting a time scale 667 A primary time scale SHOULD be chosen from among existing time 668 scales, if possible. Creating a new time scale increases complexity 669 and is unlikely to avoid the issues already present with existing 670 time scales, e.g., being continuous, uniform, requiring conversion, 671 or needing external information for conversion or interval 672 computation. 674 A primary time scale SHOULD be chosen to minimize the need for 675 repeated conversion and/or to minimize the complexity of computing 676 intervals, depending on the expected frequency of these operations. 678 For example, if synchronizing clocks with other systems using NTP is 679 the primary goal, implementers would probably select UTC [RFC5905]. 680 If user presentation is primary, as for email or calendaring, 681 implementers would probably select local time (which requires a 682 comprehensive table) [RFC5545]. If interval computation is primary, 683 implementers would probably select TAI. 685 As a consequence, in most cases, implementers seeking a primary time 686 scale SHOULD select either TAI or UTC, or a system that closely 687 approximates these (e.g., GPS-like systems or NTP), and expect to 688 maintain updated leap second information [RFC7808]. 690 7.2. Hazards of some time scales 692 Incorrect time scale selection can result in increased computational 693 overhead and the need for increased storage. External information 694 might be needed for conversion, or conversion or calculation may not 695 be possible (as with smearing). 697 Implementers SHOULD NOT use time scales that smear, for two reasons. 698 First, there is no current standard for leap smearing, so the same 699 time scale implemented on different systems are likely to indicate 700 incorrect relative dates (i.e., incorrectly indicating instance 701 ordering). Second, leap smearing complicates interval measurements 702 computed over the smear which can be difficult to compensate. 704 7.3. Alternate solutions for ordering 706 Time scales can be used for ordering but other solutions can be 707 simpler and less dependent on external sources. Notably, Lamport 708 clocks [La78] provide individual event ordering and Vector clocks 709 [Fi88][Ma88] and their derivatives provide event pair ordering, both 710 without the need for precise time keeping and epoch coordination. 712 These mechanisms rely on the use of integer counters that increase 713 with each event and tracking those counters where their uses provide 714 a continuous trace that indicates an ordering. They rely on direct 715 interactions and corresponding message exchanges to provide that 716 trace, which can be complex and incur high overheads in some cases. 717 These systems become increasing complex as groups of events require 718 ordering and may not be feasible when post-facto ordering is desired 719 in the absence of direct communication. 721 8. Security Considerations 723 Time is used within security systems for a variety of reasons, 724 including indicating the validity of certificates used for 725 encryption and authentication [RFC5280]. Inaccurate dates, 726 intervals, or ordering can affect the ability to use these 727 protocols. 729 As a result, it can be important to secure the protocols used to 730 coordinate time [RFC7384]. NTP, the most common such protocol, 731 supports secure operation [RFC5905]. 733 9. IANA Considerations 735 This document has no IANA considerations. This section should be 736 removed prior to publication as an RFC. 738 10. References 740 10.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 746 2119 Key Words," RFC 2119, May 2017. 748 10.2. Informative References 750 [BI06] Bureau International des Poids et Mesures (International 751 Bureau of Weights and Measures), "The International System 752 of Units (SI)," 8th Edition, 2006. 754 [C61] http://www.bipm.org/en/CGPM/db/11/9/ Comptes Rendus de la 755 11e CGPM (1960), 1961, pp. 86. 757 [Fi88] Fidge, C., "Timestamps in Message-Passing Systems That 758 Preserve the Partial Ordering," Proc. 11th Australian 759 Computer Science Conference (ACSC'88), pp. 55-66. 761 [Ga17] Galileo system web pages, http://galileognss.eu/gst- 762 galileo-system-time/ 764 [Go17] Google's approach to NTP leap smearing, proposed in 2017. 765 https://developers.google.com/time/smear 767 [Ha01] Hoffman-Wellenhof, B., H. Lichtenegger, J. Collins. Global 768 positioning system: theory and practice. New York, 769 Springer-Verlag, 2001. 771 [IERS] International Earth Rotation and Reference Systems Service 772 (IERS). https://www.iers.org/ 774 [IRNSS] Global Indian Navigation Satellites: Constellation 775 studies, August ISRO-ISAC-IRNSS-TR-0887, 2009. 777 [ISO98] International Standards Organization, "Data elements and 778 interchange formats - Information interchange - 779 Representation of dates and times", ISO 8601, 1988. 781 [ITU02] International Telecommunication Union, "Standard-frequency 782 and time-signal emissions," ITU-R Recommendations and 783 Reports, TF.460-6, 2002. 785 [La78] Lamport, L., "Time, Clocks, and the Ordering of Events in 786 a Distributed System," Communications of the ACM, V21 N7, 787 Jul. 1978, pp. 558-565. 789 [Ma88] Mattern, F., "Virtual Time and Global States of 790 Distributed Systems," Proc. Workshop on Parallel and 791 Distributed Algorithms, pp. 215-226. 793 [Mc09] McCarthy, D., P. Seidelmann, "Time Applications," in Time 794 - From Earth Rotation to Atomic Physics, Wiley-VCH, 2009. 795 doi: 10.1002/9783527627943.ch19 797 [NAE12] National Academy of Engineering, "Global Navigation 798 Satellite Systems," National Academies Press, ISBN 978-0- 799 309-22275-4, 2012. 801 [Ne1898] Newcomb, S., Tables of the Four Inner Planets," Second 802 Edition, 1898. 803 https://ia801005.us.archive.org/11/items/06AstronomicalPap 804 ersPreparedForTheUse/06- 805 Astronomical_Papers_Prepared_for_the_Use_text.pdf 807 [NG] NIST vs. GPS time, https://www.nist.gov/pml/time-and- 808 frequency-division/services/gps-data-archive 810 [NTPfaq] NTP FAQ pages, http://www.ntp.org/ntpfaq/NTP-s-algo.htm 812 [OG08] The Open Group, "Base Specifications, Issue 7, 2016 813 Edition," IEEE Std 1003.1 / POSIX.1-2008, 2008. 815 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 816 September 1981. 818 [RFC3339] Klyne, G., C. Newman, "Date and Time on the Internet: 819 Timestamps," RFC 3339, July 2002. 821 [RFC5280] Cooper, D., S. Santesson, S. Farrell, S. Boeyen, R. 822 Housley, W. Polk, "Internet X.509 Public Key 823 Infrastructure Certificate and Certificate Revocation List 824 (CRL) Profile," RFC 5280, May 2008. 826 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol," RFC 5321, 827 Oct. 2008. 829 [RFC5545] Desruisseaux, B. (Ed.), "Internet Calendaring and 830 Scheduling Core Object Specification (iCalendar)," RFC 831 5545, Sep. 2009. 833 [RFC5905] Mills, D., J. Martin (Ed.), J. Burbank, W. Kasch, "Network 834 Time Protocol Version 4: Protocol and Algorithms 835 Specification," RFC 5905, June 2010. 837 [RFC6557] Lear, E., P. Eggert, "Procedures for Maintaining the Time 838 Zone Database," RFC 6557, BCP 175, Feb. 2012. 840 [RFC7231] Fielding, R., J. Reshke (Eds), "Hypertext Transfer 841 Protocol (HTTP/1.1): Semantics and Content," RFC 7231, 842 June 2014. 844 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 845 (Ed.), "TCP Extensions for High Performance," RFC 7323, 846 Sep. 2014. 848 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 849 Packet Switched Networks," RFC 7384, Oct. 2014. 851 [RFC7808] Douglass, M., C. Daboo, "Time Zone Data Distribution 852 Service," RFC 7808, Mar. 2016. 854 [RI98] Russian Institute of Space Device Engineering, "GLONASS 855 Interface Control Document", 1998. 857 [Sa78] Sadler, D., "Mean Solar Time on the Meridian of 858 Greenwich," Quarterly Journal of the Roayal Astronomical 859 Society, V19, Sept. 1978, p.290. 860 http://adsabs.harvard.edu/cgi-bin/nph- 861 bib_query?bibcode=1978QJRAS..19..290S 863 [Sa11] Sanz Subirana, J., J. Juan Zornoza, M. Hernandez-Pajares, 864 "Time References in GNSS," Navipedia web pages, 2011. 865 http://www.navipedia.net/index.php/Time_References_in_GNSS 867 [tzdb] Time zone database, https://www.iana.org/time-zones 869 11. Acknowledgments 871 This work originated in response to a proposal for a new continuous 872 time scale by Phillip Hallam-Baker, and benefitted from discussion 873 on the IETF list, notably Steve Allen, Gerard Ashton, Patrik 874 Falstrom, Tony Finch, Nicholas Mailhot, Juergen Schoenwaelder, 875 Michael Thornburgh, and Nico Williams. 877 This work is partly supported by USC/ISI's Postel Center. 879 This document was prepared using 2-Word-v2.0.template.dot. 881 Authors' Addresses 883 Joe Touch 885 Manhattan Beach, CA 90266 USA 887 Phone: +1 (310) 560-0334 888 Email: touch@strayalpha.com 890 Change Log: 892 draft-touch-time-06: 894 Update discussion of epoch to add onset date. 896 draft-touch-time-05: 898 Numerous clarifications to address imprecision of definitions. 900 Added discussion on alternate solutions for ordering. 902 draft-touch-time-04: 904 Revised terminology to indicate that some definitions are not 905 precise 907 Clarified the use and benefits of integer (Lamport, Vector) 908 clocks 910 Clarified that some time scales have individual (UTC(NIST)) and 911 aggregate (UTC) values. 913 draft-touch-time-03: 915 Revise doc to more clearly target summarized recommendations. 917 Sec 4.2 definitions revised based on feedback: 919 - solar day now defined as two different things 921 - another scrub of existing definitions 923 draft-touch-time-02: 925 Sec 4.2 definitions revised based on feedback 926 Explain difference between Unix time and POSIX time API 928 draft-touch-time-01: 930 Sec 1 expanded to include list of recommendations. 932 Sec 5.2 more detailed description of intervals. 934 draft-touch-time-00: 936 (original version)