ARTWG                                                          J. Touch
Internet Draft
Intended status: Best Current Practice                 January 19, 2018
Expires: July 2018

              Resolving Multiple Time Scales in the Internet

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 19, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Touch                   Expires July 19, 2018                  [Page 1]

Internet-Draft      Resolving Multiple Time Scales         January 2018


   Internet systems use a variety of time scales, which can complicate
   time comparisons and calculations. This document explains these
   various ways of indicating time and explains how they can be used
   together safely. This document is intended as a companion to
   Internet time as discussed in RFC 3339.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................4
   3. Terminology....................................................4
   4. Background.....................................................5
      4.1. Time uses and properties..................................6
      4.2. Time scales...............................................7
      4.3. Comparison of properties..................................8
   5. Systems that report time.......................................9
   6. Computing time.................................................9
      6.1. Conversion...............................................10
         6.1.1. Continuous and uniform..............................10
         6.1.2. Uniform but not continuous..........................11
         6.1.3. Not uniform.........................................11
         6.1.4. Ordering............................................12
      6.2. Calculating intervals....................................13
   7. Advice........................................................14
      7.1. Selection advice.........................................14
      7.2. Hazards..................................................15
   8. Security Considerations.......................................15
   9. IANA Considerations...........................................15
   10. References...................................................15
      10.1. Normative References....................................15
      10.2. Informative References..................................15
   11. Acknowledgments..............................................18

1. Introduction

   A popular proverb reads, "a person with one clock always knows what
   time it is; a person with two clocks is never sure." Unfortunately,
   Internet systems rely on a variety of time references that often
   need to be reconciled. This document attempts to explain this issue
   and provide advice on how to avoid temporal ambiguity.

   There are various standards for expressing time, including Universal
   Coordinated Time (UTC) [ITU02], local time (UTC adjusted for time
   zone location and daylight saving time shifts), and Unix time

Touch                   Expires July 19, 2018                  [Page 2]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   [OG08], as well as many others. Although the Internet has a standard
   for expressing time [RFC3339], this document explains the
   complexities of using any single such time scale and describes how
   to safely apply any one time scale and to accommodate concurrent use
   of different time scales. In particular, it focuses on the
   difficulties using a single time scale to indicate dates to users,
   to order events, and to measure intervals. This document ignores
   general and special relativistic effects.

   Many time frames contain discontinuities, some of which are regular
   (e.g., time zones, leap days, and daylight saving time shifts),
   whereas others are irregularly introduced as needed (e.g., leap
   seconds). These discontinuities complicate interval computation, the
   latter requiring externally provided context (a table of mandated
   leap seconds and their scheduled occurrences). Other fine frames are
   non-uniform, in which the duration of an interval (e.g., a day, a
   year, or even a second) varies depending on its offset.

   Despite many attempts, there is no single time scale that supports
   all common uses easily and without the need for updated external
   information. As a preview, this document makes the following
   recommendations for system designers:

   1. System designers SHOULD NOT invent their own time scale. There
      are no simpler solutions and more than enough existing variants,
      although there is no known reason to exclude new variants.

   2. System designers SHOULD use one time scale as their primary
      reference and derive all other time scales by conversion, to
      avoid confusion. Exceptions might optimize for more than one use.

   3. System designers SHOULD use UTC as their primary time scale
      because it is most commonly accepted by governments and the basis
      for the Internet time [RFC3339] (based on ISO 8601 [ISO98]) and
      the Network Time Protocol (NTP) [RFC5905]. Exceptions optimize
      computation, e.g., to use TAI [BI06] for interval calculation or
      local time [ISO98] for user interaction, e.g., calendars.

   4. System designers SHOULD include location context (e.g., location
      or zone) as a part of all dates and MUST include that information
      if conversion to and between civil and local time is required.

   5. System designers SHOULD maintain updated information regarding
      leap seconds and time zones and MUST maintain that information if
      accurate intervals or civil conversions are required.

Touch                   Expires July 19, 2018                  [Page 3]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   6. System designers SHOULD be explicit about indicating whether
      intervals are inclusive or exclusive of start and end dates.
      Doing otherwise is an opportunity for ambiguity.

   7. System designers SHOULD be very clear about whether timers expire
      on a date or when an interval has passed, to help understand the
      impact of continuous and monotonic aspects of time scales.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lowercase uses of these words are not to be
   interpreted as carrying significance described in RFC 2119.

3. Terminology

   o  Instant: a specific moment in time.

   o  Time scale: a system for assigning names to intervals and dates.

   o  Interval: the elapsed time between instants.

   o  Date: the name of an instant in a time scale, typically indicated
      as an interval from an epoch.

   o  Epoch: an instant used as the origin of a time scale.

   o  Clock: a mechanism indicating the current date in a time scale.

   o  Civil time (or date): a time scale (or date) selected by a
      government authority.

   o  Solar day: a unit of time defined as the interval of one rotation
      of the earth as measured between the repeated position of the sun
      in the sky as viewed from a fixed location. Solar time relative
      to a single daily position is "apparent solar time". Solar time
      indicated as a mean over a year (one orbit of the earth around
      the sun) is "mean solar time". A given solar day can vary by as
      much as 30 seconds vs. the mean.

   o  Tropical year: a unit of time defined by the interval of one
      rotation of the earth around the sun as measured using the
      position of the sun in the sky in the same way as a solar day.

Touch                   Expires July 19, 2018                  [Page 4]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   o  Second: the unit of time, which has multiple definitions whose
      values differ:

       o 1/(24 * 60 * 60) of a solar day.

       o 1/(31,556,925.9747) of a tropical year as of the instant of
          1900 "January 0" (i.e., December 31) at 12:00:00 Ephemeris
          time (Ephemeris time is defined later herein) [C61].

       o Exactly 9192631770 periods of the radiation corresponding to
          the hyperfine transition of the ground state of cesium 133 at
          0K (as an SI unit of time) [BI06].

   o  Leap seconds: an extra second irregularly inserted into or
      removed from the UTC time scale (based on SI seconds, see Sec.
      4.2) to maintain it within 0.9 SI seconds of UT1 (based on solar
      days, see Sec. 4.2).

   o  Offset: an interval added or subtracted from a date or clock to
      convert between time scales with different epochs and leap

   o  Local time: a variation of a time scale intended to approximate
      that time scale at a given geographic location relative to that
      time scale at a reference geographic location, indicated as an

   o  Time zone: an offset defined within a geographic region, used to
      compute local time.

4. Background

   There are a variety of types of time scales in widespread use for
   scientific, civil, and computational purposes. Scientific time is
   based on the International System (SI) standard definition of a
   second based on atomic clocks, and its goal is to provide a uniform
   standard for the passage of time. Civil time is based on the
   rotation of the earth, and its goal is to ensure that a single
   geographic location has the same reference to the sun at the same
   time each day, including variations that support localized time to
   approximate that effect for other locations around the earth.
   Computational time is an approximation of civil time that is
   intended to be inexpensive for computers to maintain without
   external information.

   Each of these time scales has different properties. Scientific time
   is intended to be continuous and uniform, so that one second of

Touch                   Expires July 19, 2018                  [Page 5]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   elapsed time always has the effect of moving a scientific clock
   forward one second. Civil time can be non-continuous, such as when
   leap seconds or leap days are added to compensate for the difference
   between elapsed time and the rotation of the earth relative to the
   sun. Computational time can be non-uniform, such as when Unix system
   clocks are sped up to synchronize with civil time in a way intended
   to avoid discontinuity.

   Each of these types of time scales also has different primary uses.
   Scientific time ensures uniform comparison of elapsed time and event
   ordering. Civil time is used by people and their governments.
   Computational time is used by computers to approximate other time
   systems. Time represented in each of these systems can be converted
   to other representations, given sufficient additional information.

   Time is used throughout the Internet, to govern protocols (e.g.,
   timers in TCP [RFC793]), to improve efficiency (e.g., TCP RTT
   estimation using timestamps [RFC7323]), as well as to indicate a
   correlation with civilian time (e.g., NTP [RFC5905] and calendars
   [RFC5545]). Each of these types of uses has distinct requirements on
   the kind of time used.

4.1. Time uses and properties

   Protocols use time for three primary purposes:

   o  Ordering: to determine the relative sequence of events across
      systems, such as with Lamport clocks [La78].

   o  Determining intervals: to determine actions to occur in a
      protocol in the absence of user requests and received messages
      (e.g., timers in TCP [RFC793]), to interact with physical systems
      (e.g., generating symbols at a given rate on a link), or to
      determine performance.

   o  Interacting with people: to exchange dates with the real world,
      as when indicating the civil date of an email transmission
      [RFC3339], web page [ISO98], or managing calendars [RFC5545].

   Each of these uses mandates a key property. Ordering requires that a
   time reference is monotonic and increasing, such that the time
   reference values change between any two events whose order needs to
   be established. Accurate interval calculation requires that a time
   reference also be continuous and uniform, such that the calculated
   differences between any two dates separated by the same interval
   yield the same value. Interacting with people requires the use of a

Touch                   Expires July 19, 2018                  [Page 6]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   time reference they already use, so that expressed dates have known

   These properties are not all supported by the variety of time
   references in widespread use. Some insert leap seconds and leap
   days, introducing discontinuities. Some vary their basic interval
   unit (e.g., to accommodate astronomical variances), which undermines
   their uniformity. These issues affect the choice of time reference
   and conversion between time references.

4.2. Time scales

   The following is a description of the time scales in widespread use:

   o  TAI (International Atomic Time) [BI06]: a time scale based on the
      SI second at mean sea level ("on the geoid"), determined post-
      facto as a weighted average of a set of particular atomic clocks,
      adjusted to account for relativistic effects.

   o  UT (Universal Time) [Mc09][Sa78]: a time scale based on the solar
      day using zero degrees longitude as the earth location and a
      specific astronomical location (originally the sun, but now more
      distant objects). UT has several variants, of which the most
      common is UT1 (where UT is often synonymous with UT1), which
      includes corrections for earth axis variations.

   o  UTC (Coordinated Universal Time) [ITU02]: an approximation of UT
      based on TAI adjusted with leap seconds.

   o  Ephemeris time [C61]: an astronomical time reference, originating
      in Newcomb's tables [Ne1898] and standardized in 1952.

   o  Unix [OG08]: the POSIX/IEEE standard for Unix-based operating
      system software, in which dates are defined as the number of
      seconds that have elapsed since UTC 1970-1-1 00:00:00, increased
      by exactly 86,400 seconds per day (note that neither 'day' nor
      'second' is defined in Unix time). Note that this is not the same
      as the POSIX time API (application programmer interface), which
      provides access to a variety of time scales.

   The following are somewhat secondary to the time scales above:

   o  DUT1 [IERS]: the number of leap seconds between the current TAI
      date and the UTC epoch.

   o  GPS [Ha01]: the US Global Positioning System, defined as tracking
      time as TAI + 19 SI seconds.

Touch                   Expires July 19, 2018                  [Page 7]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   o  GLONASS [RI98]: Russia's satellite clock system, defined as
      tracking UTC.

   o  IRNSS/NAVIC [IRNSS]: The Indian Regional Navigation System.

   o  BeiDou-2 (prev. COMPASS) [NAE12]: China's satellite clock system.

   o  Galileo [Ga17]: the European Union's satellite clock system.

   o  NTP [RFC5905]: the Network Time Protocol, used in the Internet to
      synchronize local clocks, in which dates are indicated by UTC
      values. NTP times track the time of the clock they connect to.

4.3. Comparison of properties

   Time scales can be compared using the following properties, in
   addition to their epoch and the interval used as their unit of time:

   o  TAI error (Terr): a measure of the typically bounded precision on
      dates in the given time scale vs. TAI.

   o  Continuous (Cont): are dates in this time scale continuous, i.e.,
      so that intervals can be calculated directly from the difference
      in dates.

   o  Uniform (Unif): are dates in this time scale uniform, i.e., so
      that all intervals of the same size represent the same amount of

   The table below describes the time scales considered herein. All
   time scales use fixed epoch values except GLONASS, which reports
   dates relative to the current UTC. UT can drift in comparison to TAI
   by up to 0.9s, at which point a leap second is added. The satellite
   systems (BeiDou-2, Galileo, GPS, GLONASS, and IRNSS/NAVIC) attempt
   to track TAI, each with particular variances as design goals. NTP
   varies from TAI because of network latency variations, except where
   smearing is used [Go17]. Unix clocks typically use local quartz
   oscillators as clocks, which can drift from TAI by 1-2s/week unless
   continuously corrected, e.g., by NTP over the network.

Touch                   Expires July 19, 2018                  [Page 8]

Internet-Draft      Resolving Multiple Time Scales         January 2018

         Time scale   Epoch        Unit    Terr     Cont   Unif
         TAI          1977-01-01   SI      -        Yes    Yes
         UT           1582-10-15   solar    0.9s    Yes    No
         UTC          1582-10-15   SI      -        No     Yes
         Unix         1970-01-01   undef   ~100s    Yes    undef

     (1) As specified [RFC5905], error as per the FAQ [NTPfaq]
     (2) Some servers, notably Google's, 'smear' leap seconds [Go17]
      *  TAI comparisons from [Sa11]

   TAI was designed to be both continuous and uniform. UT was designed
   to be both uniform and track the solar day. The difference is
   addressed in different ways in other time scales, which are largely
   derived from these two.

   Unix time does not specify the definition of a 'second' or 'day',
   and so it is not clear whether it intends to track SI seconds (where
   time would be uniform) or solar time (where it would not).

5. Systems that report time

         Time scale   Epoch        Unit    Terr     Cont   Unif
         BeiDou-2     2006-01-01   SI      100ns*   Yes    Yes
         Galilelo     1999-08-22   SI      50ns*    Yes    Yes
         GLONASS      UTC          SI      1ms*     No     Yes
         GPS          1980-01-06   SI      25ns*    Yes    Yes
         IRNSS/NAVIC  ?            SI      ?        Yes    Yes
         NTP(1)       1900-01-01   SI      ~100ms   No     Yes
         NTP-smear(2) 1900-01-01   SI      1.1s     Yes    No

     (1) As specified [RFC5905], error as per the FAQ [NTPfaq]
     (2) Some servers, notably Google's, 'smear' leap seconds [Go17]
      *  TAI comparisons from [Sa11]

6. Computing time

   The concurrent use of multiple time scales results in the need to
   coordinate clocks and convert dates, and can complicate ordering.
   Conversions require more context than just the time units and
   epochs. It is also useful to be able to calculate the interval
   between two dates within a single time scale. Each of these
   calculations can require context, some of which cannot be statically

Touch                   Expires July 19, 2018                  [Page 9]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   encoded. Ordering depends on monotonically increasing clocks, which
   some time scales do not support.

6.1. Conversion

   Dates in different time scales can be converted precisely as long as
   both time scales are uniform. When both time scales are also
   continuous, conversion is simple and relies only on the
   specification of the time scales. If either time scale is
   discontinuous, an additional table of discontinuities is required.

   When either time scale is non-uniform, precise conversion is not
   defined unless the non-uniformity is also precisely indicated. The
   following subsections address each of these cases.

6.1.1. Continuous and uniform

   For continuous and uniform time scales sharing the same unit of
   time, the difference in epoch is sufficient to convert one scale to
   the other, e.g.:

                TS2_date = TS1_date - TS1_epoch + TS2_epoch

   This conversion assumes both epochs are indicated in the same time
   scale (or can be converted to such - if not, no conversion is
   possible). For example, GPS reports the TAI date as an interval from
   January 6, 1980, whereas TAI reports the date as an interval from
   January 1, 1977, and both epochs are indicated in solar time. The
   difference between those two epochs is exactly 95,040,019 SI
   seconds, which is the total of 1,100 days of 86,400 SI seconds each
   and an additional 19 SI seconds, needed to align the epochs
   indicated as solar dates. As a result, dates indicated in
   year/month/day/second format need only have their seconds values
   adjusted as follows:

                         GPS_date = TAI_date + 19s

   If time scales do not share the same unit of time, the conversion
   needs to account for the difference in the intervals from epoch. For
   example, a solar day is composed of 86,400 'solar seconds', but
   approximately 86,400.002 SI seconds. Conversion now requires that
   the epochs and units are expressed in a common time scale, and can
   be computed as follows:

     TS2_date = (TS1_date - TS1_epoch)/TS1_unit * TS2_unit + TS2_epoch

Touch                   Expires July 19, 2018                 [Page 10]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   Converting a common time frame to local time further requires
   knowing the location of each date and consulting a time zone
   database, which is also available online [tzdb] [RFC7808]. In this
   way, UTC can be converted to its local equivalent using a similar
   lookup operation (where TZDB is the time zone database):

         UTC_localdate = UTC_date + TZDB[UTC_date, local_location]

6.1.2. Uniform but not continuous

   Changes in the rotation of the earth cause variations in the
   difference between the unit of a second as defined by solar day,
   tropical year, and SI methods. These differences are corrected by
   introducing "leap seconds", which are added (or removed) on specific
   dates [IERS]. E.g., UTC adds or removes leap seconds (known as DUT1)
   to TAI on specific dates to help it approximate UT.

   Leap second dates can be approximated using a known calculation, but
   the exact date is determined administratively (rather than by
   calculation). Those dates are announced several months in advance
   and can be obtained online [tzdb][RFC6557][RFC7808]. As a
   consequence, conversion accounting for leap seconds requires a
   lookup operation (where "leapDB" is a database that indicates the
   number of leap seconds added since the epoch):

                  UTC_date = TAI_date + leapDB[TAI_date]

   Between dates when leap second dates, precise differences in solar
   vs. SI time scales can be computed below 1s by accounting for the
   ratio between a solar second and an SI second, but this is rarely

6.1.3. Not uniform

   Some time scales are not uniform, i.e., the duration of an interval
   is indicated in units that vary and so are not easily directly
   comparable. Solar days vary by as much as 50 SI seconds because of
   the earth's variation in its axis of rotation. Because a solar day
   is defined as a fixed number of (solar) seconds, one solar second
   varies by as much as 0.06%. This variability is not simple to
   compute, but can be averaged out over long periods, but only in
   hindsight. Similarly, the earth's orbit around the sun varies and is
   slowing over time, resulting in an increasing stretching of a solar

   Some time scales replace discrete leap seconds with a leap smear,
   stretching the interval of one second over 10-20 hours before the

Touch                   Expires July 19, 2018                 [Page 11]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   corresponding leap second date [Go17]. This allows a time scale to
   avoid discontinuities and non-conventional interval values (e.g.,
   minutes with 59 or 61 seconds). Smearing causes non-uniformity of
   intervals that span the smear, especially because there is no
   current standard for the smear interval or algorithm.

   Additionally, some time scales have no precise conversion, e.g., GPS
   is coordinated to within 25ns of TAI, but the exact difference is
   known only as a post-facto measurement relative to NIST time (a
   subset of the clocks used to compute TAI) [NG]. This occurs because
   GPS uses its own set of atomic clocks rather than using the TAI
   directly, and the same is true for other satellite systems. Other
   time scales are imprecise by definition, as with Unix time, which is
   based on clocks that vary widely by instance and with changes in

6.1.4. Ordering

   Events in a distributed system often require ordering to ensure
   consistent views of their aggregate state [La78]. It can be
   important to know whether a bank deposit occurs before a withdrawal
   or if a license application has been submitted before a deadline.

   Time scales that are continuous enable easy ordering of dates, e.g.,
   all dates comparisons correctly either indicate concurrence (when
   dates match) or a specific order. Time scales that are discontinuous
   can give false results, such as during a leap second. Consider the
   UTC date encodings indicated in Figure 1.

         Instant   TAI date                UTC encoding (61s minute)
         A         2016-01-01T00:00:34.0   2016-12-31T23:59:59.0
         B         2016-01-01T00:00:34.5   2016-12-31T23:59:59.5
         C         2016-01-01T00:00:35.0   2016-12-31T23:59:60.0
         D         2016-01-01T00:00:35.5   2016-12-31T23:59:60.5
         E         2016-01-01T00:00:36.0   2016-01-01T00:00:00.0

                  Figure 1 Leap seconds with long minutes

   In both cases, two SI seconds progress between instants A and E.
   However, the last minute before midnight on December 31, 2016 has a
   minute that lasts 61 seconds (0..61), rather than 60. Ordering of
   these instants is unambiguous in this example.

   Consider instead a system that cannot represent minutes with more
   than 60 seconds. In such systems, the clock is either stalled or
   delayed during a leap second insertion, resulting in repeated values

Touch                   Expires July 19, 2018                 [Page 12]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   (Figure 2). Here, the order of instants B, C, and D cannot be
   established accurately from the dates. Additionally, intervals that
   span this "reset" are inaccurately calculated from date differences
   unless explicitly corrected.

         Instant   TAI date                UTC encoding (60s minute)
         A         2016-01-01T00:00:34.0   2016-12-31T23:59:59.0
         B         2016-01-01T00:00:34.5   2016-12-31T23:59:59.5
         C         2016-01-01T00:00:35.0   2016-12-31T23:59:59.0
         D         2016-01-01T00:00:35.5   2016-12-31T23:59:59.5
         E         2016-01-01T00:00:36.0   2016-01-01T00:00:00.0

                Figure 2 Leap seconds with repeating dates

   Ordering can be restored using leap smear, as shown in Figure 3, but
   at the expense of complicating the computation of intervals that
   span the smear.

         Instant   TAI date                UTC encoding (60s minute)
         A         2016-01-01T00:00:34.0   2016-12-31T23:59:59.0
         B         2016-01-01T00:00:34.5   2016-12-31T23:59:59.25
         C         2016-01-01T00:00:35.0   2016-12-31T23:59:59.5
         D         2016-01-01T00:00:35.5   2016-12-31T23:59:59.75
         E         2016-01-01T00:00:36.0   2016-01-01T00:00:00.0

                     Figure 3 Leap seconds with smear

6.2. Calculating intervals

   Intervals can be calculated directly between two dates of a uniform
   time scale directly as the difference between two dates A and B as
   follows (where "abs" is the absolute value function):

                       interval = abs(dateA - dateB)

   It is important that the specification of an interval indicate
   whether its endpoints are included or not, e.g., whether the
   interval is open, half-open, or closed. In common mathematical
   notation, the interval [1:24.00, 1:25.00] includes both 1:24.00 and
   1:25.00. The interval [1.24.00, 1:25.00) starts at the instant of
   1:24.00 and ends just before the instant of 1:25.00, i.e., 1:25.00
   is excluded from the interval. System designers SHOULD clearly
   indicate whether intervals include or exclude their start and end

Touch                   Expires July 19, 2018                 [Page 13]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   A non-continuous time scale requires external information, e.g., the
   leap second dates that occur during the interval. Computing
   intervals in these time scales requires that the representation does
   not repeat or smear time. The interval is computed by converting
   non-continuous time to continuous time by removing the effect of
   leap seconds and proceeding as with the continuous case, as follows:

     interval = abs((dateA - leapDB(dateA)) - (dateB - leapDB(dateB)))

   Non-uniform time scale intervals can sometimes be calculated, but
   this is rarely supported.

7. Advice

   No single time scale serves all purposes. Use of multiple time
   scales requires conversion, which often requires external
   information. Maintaining accurate clocks can also require external
   information (to insert leap seconds), as can the computation of

7.1. Selection advice

   A primary time scale SHOULD be chosen from among existing time
   scales, if possible. Creating a new time scale increases complexity
   and is unlikely to avoid the issues already present with existing
   time scales, e.g., being continuous, uniform, requiring conversion,
   or needing external information for conversion or interval

   A primary time scale SHOULD be chosen to minimize the need for
   repeated conversion and/or to minimize the complexity of computing
   intervals, depending on the expected frequency of these operations.

   For example, if synchronizing clocks with other systems using NTP is
   the primary goal, implementers would probably select UTC [RFC5905].
   If user presentation is primary, as for email or calendaring,
   implementers would probably select local time [RFC5545]. If interval
   computation is primary, implementers would probably select TAI.

   As a consequence, in most cases, implementers SHOULD select either
   TAI or UTC, or a system that closely approximates these (e.g., GPS-
   like systems or NTP), and expect to maintain updated leap second
   information [RFC7808].

Touch                   Expires July 19, 2018                 [Page 14]

Internet-Draft      Resolving Multiple Time Scales         January 2018

7.2. Hazards

   Incorrect time scale selection can result in increased computational
   overhead and the need for increased storage. External information
   might be needed for conversion, or conversion or calculation may not
   be possible (as with smearing).

   Implementers SHOULD NOT use time scales that smear, for two reasons.
   First, there is no current standard for leap smearing, so the same
   time scale implemented on different systems are likely to indicate
   incorrect relative dates (i.e., incorrectly indicating instance
   ordering). Second, leap smearing complicates interval measurements
   computed over the smear which can be difficult to compensate.

8. Security Considerations

   Time is used within security systems for a variety of reasons,
   including indicating the validity of certificates used for
   encryption and authentication [RFC5280]. Inaccurate dates,
   intervals, or ordering can affect the ability to use these

   As a result, it can be important to secure the protocols used to
   coordinate time [RFC7384]. NTP, the most common such protocol,
   supports secure operation [RFC5905].

9. IANA Considerations

   This document has no IANA considerations. This section should be
   removed prior to publication as an RFC.

10. References

10.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Informative References

   [BI06]    Bureau International des Poids et Mesures (International
             Bureau of Weights and Measures), "The International System
             of Units (SI)," 8th Edition, 2006.

   [C61] Comptes Rendus de la
             11e CGPM (1960), 1961, p.86

Touch                   Expires July 19, 2018                 [Page 15]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   [Ga17]    Galileo system web pages,

   [Go17]    Google's approach to NTP leap smearing, proposed in 2017.

   [Ha01]    Hoffman-Wellenhof, B., H. Lichtenegger, J. Collins. Global
             positioning system: theory and practice. New York,
             Springer-Verlag, 2001.

   [IERS]    International Earth Rotation and Reference Systems Service

   [IRNSS]   Global Indian  Navigation  Satellites: Constellation
             studies, August ISRO-ISAC-IRNSS-TR-0887, 2009.

   [ISO98]   International Standards Organization, "Data elements and
             interchange formats - Information interchange -
             Representation of dates and times", ISO 8601, 1988.

   [ITU02]   International Telecommunication Union, "Standard-frequency
             and time-signal emissions," ITU-R Recommendations and
             Reports, TF.460-6, 2002.

   [La78]    Lamport, L., "Time, Clocks, and the Ordering of Events in
             a Distributed System," Communications of the ACM, V21 N7,
             Jul. 1978, pp. 558-565.

   [Mc09]    McCarthy, D., P. Seidelmann, "Time Applications," in Time
             - From Earth Rotation to Atomic Physics, Wiley-VCH, 2009.
             doi: 10.1002/9783527627943.ch19

   [NAE12]   National Academy of Engineering, "Global Navigation
             Satellite Systems," National Academies Press, ISBN 978-0-
             309-22275-4, 2012.

   [Ne1898]  Newcomb, S., Tables of the Four Inner Planets," Second
             Edition, 1898.

   [NG]      NIST vs. GPS time,

   [NTPfaq]  NTP FAQ pages,

Touch                   Expires July 19, 2018                 [Page 16]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   [OG08]    The Open Group, "Base Specifications, Issue 7, 2016
             Edition," IEEE Std 1003.1 / POSIX.1-2008, 2008.

   [RFC793]  Postel, J., "Transmission Control Protocol" RFC 793,
             September 1981.

   [RFC3339] Klyne, G., C. Newman, "Date and Time on the Internet:
             Timestamps," RFC 3339, July 2002.

   [RFC5280] Cooper, D., S. Santesson, S. Farrell, S. Boeyen, R.
             Housley, W. Polk, "Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation List
             (CRL) Profile," RFC 5280, May 2008.

   [RFC5545] Desruisseaux, B. (Ed.), "Internet Calendaring and
             Scheduling Core Object Specification (iCalendar)," RFC
             5545, Sep. 2009.

   [RFC5905] Mills, D., J. Martin (Ed.), J. Burbank, W. Kasch, "Network
             Time Protocol Version 4: Protocol and Algorithms
             Specification," RFC 5905, June 2010.

   [RFC6557] Lear, E., P. Eggert, "Procedures for Maintaining the Time
             Zone Database," RFC 6557, BCP 175, Feb. 2012.

   [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger
             (Ed.), "TCP Extensions for High Performance," RFC 7323,
             Sep. 2014.

   [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
             Packet Switched Networks," RFC 7384, Oct. 2014.

   [RFC7808] Douglass, M., C. Daboo, "Time Zone Data Distribution
             Service," RFC 7808, Mar. 2016.

   [RI98]    Russian Institute of Space Device Engineering, "GLONASS
             Interface Control Document", 1998.

   [Sa78]    Sadler, D., "Mean Solar Time on the Meridian of
             Greenwich," Quarterly Journal of the Roayal Astronomical
             Society, V19, Sept. 1978, p.290.

   [Sa11]    Sanz Subirana, J., J. Juan Zornoza, M. Hernandez-Pajares,
             "Time References in GNSS," Navipedia web pages, 2011.

Touch                   Expires July 19, 2018                 [Page 17]

Internet-Draft      Resolving Multiple Time Scales         January 2018

   [tzdb]    Time zone database,

11. Acknowledgments

   This work originated in response to a proposal for a new continuous
   time scale by Phillip Hallam-Baker, and benefitted from discussion
   on the IETF list, notably Steve Allen, Patrik Falstrom, Tony Finch,
   Nicholas Mailhot, Michael Thornburgh, and Nico Williams.

   This work is partly supported by USC/ISI's Postel Center.

   This document was prepared using

Authors' Addresses

   Joe Touch

   Manhattan Beach, CA 90266 USA

   Phone: +1 (310) 560-0334

   Change Log:


      Revise doc to more clearly target summarized recommendations.

      Sec 4.2 definitions revised based on feedback:

      - solar day now defined as two different things?

      - another scrub of existing definitions


      Sec 4.2 definitions revised based on feedback

      Explain difference between Unix time and POSIX time API


      Sec 1 expanded to include list of recommendations.

      Sec 5.2 more detailed description of intervals.

Touch                   Expires July 19, 2018                 [Page 18]

Internet-Draft      Resolving Multiple Time Scales         January 2018


      (original version)

Touch                   Expires July 19, 2018                 [Page 19]