Internet DRAFT - draft-murchison-tzdist-tzif

draft-murchison-tzdist-tzif







Independent Submission                                          A. Olson
Internet-Draft
Intended status: Standards Track                               P. Eggert
Expires: June 8, 2019                                               UCLA
                                                            K. Murchison
                                                                FastMail
                                                        December 5, 2018


                The Time Zone Information Format (TZif)
                     draft-murchison-tzdist-tzif-16

Abstract

   This document specifies the Time Zone Information Format (TZif) for
   representing and exchanging time zone information, independent of any
   particular service or protocol.  Two MIME media types for this format
   are also defined.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 8, 2019.

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
   (https://trustee.ietf.org/license-info) 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.




Olson, et al.             Expires June 8, 2019                  [Page 1]

Internet-Draft                    TZif                     December 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  The Time Zone Information Format (TZif) . . . . . . . . . . .   5
     3.1.  TZif Header . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  TZif Data Block . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  TZif Footer . . . . . . . . . . . . . . . . . . . . . . .  11
       3.3.1.  TZ String Extensions  . . . . . . . . . . . . . . . .  12
   4.  Interoperability Considerations . . . . . . . . . . . . . . .  13
   5.  Use with the Time Zone Data Distribution Service  . . . . . .  14
     5.1.  Truncating TZif Files . . . . . . . . . . . . . . . . . .  14
     5.2.  Example TZDIST Request for TZif Data  . . . . . . . . . .  15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  application/tzif  . . . . . . . . . . . . . . . . . . . .  17
     8.2.  application/tzif-leap . . . . . . . . . . . . . . . . . .  18
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  20
     10.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Appendix A.  Common Interoperability Issues . . . . . . . . . . .  21
   Appendix B.  Example TZif Files . . . . . . . . . . . . . . . . .  24
     B.1.  Version 1 File Representing UTC (with Leap Seconds) . . .  24
     B.2.  Version 2 File Representing Pacific/Honolulu  . . . . . .  28
     B.3.  Truncated Version 3 File Representing Asia/Jerusalem  . .  32
   Appendix C.  Change History (To be removed by RFC Editor before
                publication) . . . . . . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

   Time zone data typically consists of offsets from Universal Time
   (UT), daylight saving transition rules, one or more local time
   designations (acronyms or abbreviations), and optional leap second
   adjustments.  One such format for conveying this information is
   iCalendar [RFC5545].  It is a text-based format used by calendaring
   and scheduling systems.

   This document specifies the widely deployed Time Zone Information
   Format (TZif).  It is a binary format used by most UNIX systems to
   calculate local time.  This format was introduced in the 1980s and
   has evolved since then into multiple upward-compatible versions.
   There is a wide variety of interoperable software [tz-link] capable
   of generating and reading files in this format.




Olson, et al.             Expires June 8, 2019                  [Page 2]

Internet-Draft                    TZif                     December 2018


   This specification does not define the source of the data assembled
   into a TZif file.  One such source is the IANA-hosted time zone
   database [RFC6557].

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are used in this document (see "Sources for Time
   Zone and Daylight Saving Time Data" [tz-link] for more-detailed
   information about civil timekeeping data and practice):

   Coordinated Universal Time (UTC):  The basis for civil time since
      1960.  It is approximately equal to mean solar time at the prime
      meridian (0 degrees longitude).

   Daylight Saving Time (DST):  The time according to a location's law
      or practice, when adjusted as necessary from standard time.  The
      adjustment may be positive or negative, and the amount of
      adjustment may vary depending on the date and time; the TZif
      format even allows the adjustment to be zero, although this is not
      common practice.

   International Atomic Time (TAI):  The time standard based on atomic
      clocks since 1972.  It is equal to UTC except without leap second
      adjustments.

   Leap Second Correction (LEAPCORR):  The value of TAI - UTC - 10 for
      timestamps after the first leap second, and zero for timestamps
      before that.  The expression "TAI - UTC - 10" comes from the fact
      that TAI - UTC was defined to be 10 just prior to the first leap
      second in 1972, so clocks with leap seconds have a zero LEAPCORR
      before the first leap second.

   Local Time:  Civil time for a particular location.  Its offset from
      Universal Time can depend on the date and time of day.

   POSIX Epoch:  1970-01-01 00:00:00 UTC, the basis for absolute
      timestamps in this document.

   Standard Time:  The time according to a location's law or practice,
      unadjusted for Daylight Saving Time.





Olson, et al.             Expires June 8, 2019                  [Page 3]

Internet-Draft                    TZif                     December 2018


   Time Change:  A change to civil timekeeping practice.  It occurs when
      one or more of the following happen simultaneously:

      1.  a change in UT offset

      2.  a change in whether daylight saving time is in effect

      3.  a change in time zone abbreviation

      4.  a leap second (i.e., a change in LEAPCORR)

   Time Zone Data:  The Time Zone Data Distribution Service (TZDIST)
      [RFC7808] defines "Time zone data" as "data that defines a single
      time zone, including an identifier, UTC offset values, DST rules,
      and other information such as time zone abbreviations."  The
      interchange format defined in this document is one such form of
      time zone data.

   Transition Time:  The moment of occurrence of a time change that is
      not a leap second.  It is identified with a signed integer count
      of Unix Leap Time seconds since the POSIX Epoch.

   Universal Time (UT):  The basis of civil time.  This is the principal
      form of the mean solar time at the prime meridian (0 degrees
      longitude) for timestamps before UTC was introduced in 1960, and
      is UTC for timestamps thereafter.  Although UT is sometimes called
      "UTC" or "GMT" in other sources, this specification uses the term
      "UT" to avoid confusion with UTC or with GMT.

   UNIX Time:  The time as returned by the C time() function (see
      Section 3 of the "System Interfaces" Volume [2] of [POSIX]).  This
      is an integer number of seconds since the POSIX Epoch, not
      counting leap seconds.  As an extension to POSIX, negative values
      represent times before the POSIX Epoch, using UT.

   UNIX Leap Time:  UNIX time plus all preceding leap second
      corrections.  For example, if the first leap second record in a
      TZif file occurs at 1972-06-30 23:59:60 UTC, the UNIX leap time
      for the timestamp 1972-07-01 00:00:00 UTC would be 78796801, one
      greater than the UNIX time for the same timestamp.  Similarly, if
      the second leap second record occurs at 1972-12-31 23:59:60 UTC it
      accounts for the first leap second, so the UNIX leap time of
      1972-12-31 23:59:60 UTC would be 94694401 and the Unix leap time
      of 1973-01-01 00:00:00 UTC would be 94694402.  If a TZif file
      specifies no leap second records, UNIX leap time is equal to UNIX
      time.

   Wall Time:  Another name for local time; short for "wall clock time".



Olson, et al.             Expires June 8, 2019                  [Page 4]

Internet-Draft                    TZif                     December 2018


3.  The Time Zone Information Format (TZif)

   The time zone information format begins with a fixed 44-octet version
   1 header (Section 3.1) containing a field that specifies the version
   of the file's format.  Readers designed for version N can read
   version N+1 files without too much trouble; data specific to version
   N+1 either appears after version N data so that earlier-version
   readers can easily ignore later-version data they are not designed
   for, or it appears as a minor extension to version N that version N
   readers are likely to tolerate well.

   The version 1 header is followed by a variable-length version 1 data
   block (Section 3.2) containing four-octet (32-bit) transition times
   and leap second occurrences.  These 32-bit values are limited to
   representing time changes from 1901-12-13 20:45:52 through 2038-01-19
   03:14:07 UT, and the version 1 header and data block are present only
   for backward compatibility with obsolescent readers as discussed in
   Common Interoperability Issues (Appendix A).

   Version 1 files terminate after the version 1 data block.  Version 2
   and 3 files extend the format by appending a second 44-octet version
   2+ header, a variable-length version 2+ data block containing eight-
   octet (64-bit) transition times and leap second occurrences, and a
   variable length footer (Section 3.3).  These 64-bit values can
   represent times approximately 292 billion years into the past or
   future.

   NOTE: All multi-octet integer values MUST be stored in network octet
   order format (high-order octet first, otherwise known as big-endian),
   with all bits significant.  Signed integer values MUST be represented
   using two's complement.

   A TZif file is structured as follows:


















Olson, et al.             Expires June 8, 2019                  [Page 5]

Internet-Draft                    TZif                     December 2018


                        Version 1       Versions 2 & 3
                     +-------------+   +-------------+
                     |  Version 1  |   |  Version 1  |
                     |   Header    |   |   Header    |
                     +-------------+   +-------------+
                     |  Version 1  |   |  Version 1  |
                     |  Data Block |   |  Data Block |
                     +-------------+   +-------------+
                                       |  Version 2+ |
                                       |   Header    |
                                       +-------------+
                                       |  Version 2+ |
                                       |  Data Block |
                                       +-------------+
                                       |   Footer    |
                                       +-------------+

                       General Format of TZif Files

3.1.  TZif Header

   A TZif header is structured as follows (the lengths of multi-octet
   fields are shown in parentheses):

       +---------------+---+
       |  magic    (4) |ver|
       +---------------+---+---------------------------------------+
       |           [unused - reserved for future use] (15)         |
       +---------------+---------------+---------------+-----------+
       |  isutcnt  (4) |  isstdcnt (4) |  leapcnt  (4) |
       +---------------+---------------+---------------+
       |  timecnt  (4) |  typecnt  (4) |  charcnt  (4) |
       +---------------+---------------+---------------+

                                TZif Header

   The fields of the header are defined as follows:

   magic:  The four-octet ASCII [RFC0020] sequence "TZif" (0x54 0x5A
      0x69 0x66) which identifies the file as utilizing the Time Zone
      Information Format.

   ver(sion):  An octet identifying the version of the file's format.
      The value MUST be one of the following:

      NUL (0x00)  Version 1 - The file contains only the version 1
         header and data block.  Version 1 files MUST NOT contain a
         version 2+ header, data block, or footer.



Olson, et al.             Expires June 8, 2019                  [Page 6]

Internet-Draft                    TZif                     December 2018


      '2' (0x32)  Version 2 - The file MUST contain the version 1 header
         and data block, a version 2+ header and data block, and a
         footer.  The TZ string in the footer (Section 3.3), if
         nonempty, MUST strictly adhere to the requirements for the TZ
         environment variable as defined in Section 8.3 of the "Base
         Definitions" Volume [3] of [POSIX], and MUST encode the POSIX
         portable character set as ASCII.

      '3' (0x33)  Version 3 - The file MUST contain the version 1 header
         and data block, a version 2+ header and data block, and a
         footer.  The TZ string in the footer (Section 3.3), if
         nonempty, MUST conform to POSIX requirements with ASCII
         encoding, except that it MAY use the TZ string extensions
         described below (Section 3.3.1).

   isutcnt:  A four-octet unsigned integer specifying the number of UT/
      local indicators contained in the data block - MUST either be zero
      or equal to 'typecnt'.

   isstdcnt:  A four-octet unsigned integer specifying the number of
      standard/wall indicators contained in the data block - MUST either
      be zero or equal to 'typecnt'.

   leapcnt:  A four-octet unsigned integer specifying the number of leap
      second records contained in the data block.

   timecnt:  A four-octet unsigned integer specifying the number of
      transition times contained in the data block.

   typecnt:  A four-octet unsigned integer specifying the number of
      local time type records contained in the data block - MUST NOT be
      zero.  (Although local time type records convey no useful
      information in files that have nonempty TZ strings but no
      transitions, at least one such record is nevertheless required
      because many TZif readers reject files that have zero time types.)

   charcnt:  A four-octet unsigned integer specifying the total number
      of octets used by the set of time zone designations contained in
      the data block - MUST NOT be zero.  The count includes the
      trailing NUL (0x00) octet at the end of the last time zone
      designation.

   Although the version 1 and 2+ headers have the same format with the
   same magic number and version fields, their count fields may differ
   because the version 1 data can be a subset of the version 2+ data.






Olson, et al.             Expires June 8, 2019                  [Page 7]

Internet-Draft                    TZif                     December 2018


3.2.  TZif Data Block

   A TZif data block consists of seven variable-length elements, each of
   which is a series of items.  The number of items in each series is
   determined by the corresponding count field in the header.  The total
   length of each element is calculated by multiplying the number of
   items by the size of each item.  Therefore, implementations that do
   not wish to parse or use the version 1 data block can calculate its
   total length and skip directly to the header of the version 2+ data
   block.

   In the version 1 data block, time values are 32-bit (TIME_SIZE = 4
   octets).  In the version 2+ data block, present only in version 2 and
   3 files, time values are 64-bit (TIME_SIZE = 8 octets).

   The data block is structured as follows (the lengths of multi-octet
   fields are shown in parentheses):

        +---------------------------------------------------------+
        |  transition times          (timecnt x TIME_SIZE)        |
        +---------------------------------------------------------+
        |  transition types          (timecnt)                    |
        +---------------------------------------------------------+
        |  local time type records   (typecnt x 6)                |
        +---------------------------------------------------------+
        |  time zone designations    (charcnt)                    |
        +---------------------------------------------------------+
        |  leap second records       (leapcnt x (TIME_SIZE + 4))  |
        +---------------------------------------------------------+
        |  standard/wall indicators  (isstdcnt)                   |
        +---------------------------------------------------------+
        |  UT/local indicators       (isutcnt)                    |
        +---------------------------------------------------------+

                              TZif Data Block

   The elements of the data block are defined as follows:

   transition times:  A series of four- or eight-octet UNIX leap time
      values sorted in strictly ascending order.  Each value is used as
      a transition time at which the rules for computing local time may
      change.  The number of time values is specified by the 'timecnt'
      field in the header.  Each time value SHOULD be at least -2**59.
      (-2**59 is the greatest negated power of 2 that predates the Big
      Bang, and avoiding earlier timestamps works around known TZif
      reader bugs relating to outlandlishly negative timestamps.)





Olson, et al.             Expires June 8, 2019                  [Page 8]

Internet-Draft                    TZif                     December 2018


   transition types:  A series of one-octet unsigned integers specifying
      the type of local time of the corresponding transition time.
      These values serve as zero-based indices into the array of local
      time type records.  The number of type indices is specified by the
      'timecnt' field in the header.  Each type index MUST be in the
      range [0, 'typecnt' - 1].

   local time type records:  A series of six-octet records specifying a
      local time type.  The number of records is specified by the
      'typecnt' field in the header.  Each record has the following
      format (the lengths of multi-octet fields are shown in
      parentheses):

      +---------------+---+---+
      |  utoff (4)    |dst|idx|
      +---------------+---+---+

      utoff:  A four-octet signed integer specifying the number of
         seconds to be added to UT in order to determine local time.
         The value MUST NOT be -2**31, and SHOULD be in the range
         [-89999, 93599] (i.e., its value SHOULD be more than -25 hours
         and less than 26 hours).  (Avoiding -2**31 allows 32-bit
         clients to negate the value without overflow.  Restricting it
         to [-89999, 93599] allows easy support by implementations that
         already support the the POSIX-required range [-24:59:59,
         25:59:59].)

      (is)dst:  A one-octet value indicating whether local time should
         be considered Daylight Saving Time (DST).  The value MUST be 0
         or 1.  A value of one (1) indicates that this type time is DST.
         A value of zero (0) indicates that this time type is standard
         time.

      (desig)idx:  A one-octet unsigned integer specifying a zero-based
         index into the series of time zone designation octets, thereby
         selecting a particular designation string.  Each index MUST be
         in the range [0, 'charcnt' - 1], and designates the NUL-
         terminated string of octets starting at position 'idx' in the
         time zone designations.  (This string MAY be empty.)  A NUL
         octet MUST exist in the time zone designations at or after
         position 'idx'.

   time zone designations:  A series of octets constituting an array of
      NUL-terminated (0x00) time zone designation strings.  The total
      number of octets is specified by the 'charcnt' field in the
      header.  Note that two designations MAY overlap if one is a suffix
      of the other.  The character encoding of time zone designation
      strings is not specified; however, see Section 4 of this document.



Olson, et al.             Expires June 8, 2019                  [Page 9]

Internet-Draft                    TZif                     December 2018


   leap second records:  A series of eight- or twelve-octet records
      specifying the corrections that need to be applied to UTC in order
      to determine TAI.  The records are sorted by the occurrence time
      in strictly ascending order.  The number of records is specified
      by the 'leapcnt' field in the header.  Each record has one of the
      following structures (the lengths of multi-octet fields are shown
      in parentheses):

      Version 1 Data Block:

      +---------------+---------------+
      |  occur (4)    |  corr (4)     |
      +---------------+---------------+

      version 2+ Data Block:

      +---------------+---------------+---------------+
      |  occur (8)                    |  corr (4)     |
      +---------------+---------------+---------------+

      occur(rence):  A four- or eight-octet UNIX leap time value
         specifying the time at which a leap second correction occurs.
         The first value, if present, MUST be nonnegative, and each
         later value MUST be at least 2419199 greater than the previous
         value.  (This is 28 days' worth of seconds, minus a potential
         negative leap second.)

      corr(ection):  A four-octet signed integer specifying the value of
         LEAPCORR on or after the occurrence.  The correction value in
         the first leap second record, if present, MUST be either one
         (1) or minus one (-1).  The correction values in adjacent leap
         second records MUST differ by exactly one (1).  The value of
         LEAPCORR is zero for timestamps that occur before the
         occurrence time in the first leap second record (or for all
         timestamps if there are no leap second records).

   standard/wall indicators:  A series of one-octet values indicating
      whether the transition times associated with local time types were
      specified as standard time or wall clock time.  Each value MUST be
      0 or 1.  A value of one (1) indicates standard time, and MUST be
      set to one (1) if the corresponding UT/local indicator is set to
      one (1).  A value of zero (0) indicates wall time.  The number of
      values is specified by the 'isstdcnt' field in the header.  If
      'isstdcnt' is zero (0), all transition times associated with local
      time types are assumed to be specified as wall time.

   UT/local indicators:  A series of one-octet values indicating whether
      the transition times associated with local time types were



Olson, et al.             Expires June 8, 2019                 [Page 10]

Internet-Draft                    TZif                     December 2018


      specified as UT or local time.  Each value MUST be 0 or 1.  A
      value of one (1) indicates UT, and the corresponding standard/wall
      indicator MUST also be set to one (1).  A value of zero (0)
      indicates local time.  The number of values is specified by the
      'isutcnt' field in the header.  If 'isutcnt' is zero (0), all
      transition times associated with local time types are assumed to
      be specified as local time.

   The type corresponding to a transition time specifies local time for
   timestamps starting at the given transition time and continuing up
   to, but not including, the next transition time.  Local time for
   timestamps before the first transition is specified by the first time
   type (time type 0).  Local time for timestamps on or after the last
   transition is specified by the TZ string in the footer (Section 3.3)
   if present and nonempty, and is unspecified otherwise.  If there are
   no transitions, local time for all timestamps is specified by the TZ
   string in the footer if present and nonempty, and is specified by
   time type 0 otherwise.

   A given pair of standard/wall and UT/local indicators is used to
   designate whether the corresponding transition time was specified as
   UT, standard time, or wall clock time.  Note that there are only
   three combinations of the two indicators given that the standard/wall
   value MUST be one (1) if the UT/local value is one (1).  This
   information can be useful if the transition times in a TZif file need
   to be transformed into transitions appropriate for another time zone
   (e.g. when calculating transition times for a simple POSIX TZ string
   such as "AKST9AKDT").

   In order to eliminate unused space in a TZif file, every nonzero
   local time type index SHOULD appear at least once in the transition
   type array.  Likewise, every octet in the time zone designations
   array SHOULD be used by at least one time type record.

3.3.  TZif Footer

   The TZif footer is structured as follows (the lengths of multi-octet
   fields are shown in parentheses):

                      +---+--------------------+---+
                      | NL|  TZ string (0...)  |NL |
                      +---+--------------------+---+

                                TZif Footer

   The elements of the footer are defined as follows:

   NL:  An ASCII new line character (0x0A).



Olson, et al.             Expires June 8, 2019                 [Page 11]

Internet-Draft                    TZif                     December 2018


   TZ string:  A rule for computing local time changes after the last
      transition time stored in the version 2+ data block.  The string
      is either empty or uses the expanded format of the "TZ"
      environment variable as defined in Section 8.3 of the "Base
      Definitions" Volume [4] of [POSIX] with ASCII encoding, possibly
      utilizing extensions described below (Section 3.3.1) in version 3
      files.  If the string is empty, the corresponding information is
      not available.  If the string is nonempty and one or more
      transitions appear in the version 2+ data, the string MUST be
      consistent with the last version 2+ transition - i.e., evaluating
      the TZ string at the time of the last transition should yield the
      same time type as the time type specified in the last transition.
      The string MUST NOT contain NUL octets or be NUL-terminated, and
      SHOULD NOT begin with the ':' (colon) character.

   The TZif footer is present only in Version 2 and 3 files, as the
   obsolescent Version 1 format was designed before the need for a
   footer was apparent.

3.3.1.  TZ String Extensions

   The TZ string in a Version 3 TZif file MAY use the following
   extensions to POSIX TZ strings.  These extensions are described using
   the terminology of Section 8.3 of the "Base Definitions" Volume [5]
   of [POSIX].

   o  The hours part of the transition times may be signed and range
      from -167 through 167 (-167 <= hh <= 167) instead of the POSIX-
      required unsigned values from 0 through 24.

      Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1
         This represents a time zone that observes daylight saving time
         from 22:00 on the day before March's last Sunday until 23:00 on
         the day before October's last Sunday.  Standard time is 3 hours
         west of UT and is abbreviated "-03"; daylight saving time is 2
         hours west of UT and is abbreviated "-02".

   o  DST is considered to be in effect all year if it starts January 1
      at 00:00 and ends December 31 at 24:00 plus the difference between
      daylight saving and standard time, leaving no room for standard
      time in the calendar.

      Example: EST5EDT,0/0,J365/25
         This represents a time zone that observes daylight saving time
         all year.  It is 4 hours west of UT and is abbreviated "EDT".






Olson, et al.             Expires June 8, 2019                 [Page 12]

Internet-Draft                    TZif                     December 2018


4.  Interoperability Considerations

   The following practices help ensure interoperability of TZif
   applications.

   o  Version 1 files are considered a legacy format and SHOULD NOT be
      generated, as they do not support transition times after the year
      2038.

   o  Implementations that only understand Version 1 MUST ignore any
      data that extends beyond the calculated end of the version 1 data
      block.

   o  Implementations SHOULD generate a version 3 file if TZ string
      extensions are necessary to accurately model transition times.
      Otherwise, version 2 files SHOULD be generated.

   o  The sequence of time changes defined by the version 1 header and
      data block SHOULD be a contiguous subsequence of the time changes
      defined by the version 2+ header and data block, and by the
      footer.  This guideline helps obsolescent version 1 readers agree
      with current readers about timestamps within the contiguous
      subsequence.  It also lets writers not supporting obsolescent
      readers use a 'timecnt' of zero in the version 1 data block to
      save space.

   o  Time zone designations SHOULD consist of at least three (3) and no
      more than six (6) ASCII characters from the set of alphanumerics,
      '-', and '+'.  This is for compatibility with POSIX requirements
      for time zone abbreviations.

   o  When reading a version 2 or 3 file, implementations SHOULD ignore
      the version 1 header and data block except for the purpose of
      skipping over them.

   o  Implementations SHOULD calculate the total lengths of the headers
      and data blocks and check that they all fit within the actual file
      size, as part of a validity check for the file.

   o  When a TZif file is used in a MIME message entity it SHOULD be
      indicated by one of the following media types:

      *  "application/tzif-leap" (Section 8.2) to indicate that leap
         second records are included in the TZif data as necessary (none
         are necessary if the file is truncated to a range that precedes
         the first leap second).





Olson, et al.             Expires June 8, 2019                 [Page 13]

Internet-Draft                    TZif                     December 2018


      *  "application/tzif" (Section 8.1) to indicate that leap second
         records are not included in the TZif data; 'leapcnt' in the
         header(s) MUST be zero (0).

   o  Common interoperability issues and possible workarounds are
      described in Appendix A.

5.  Use with the Time Zone Data Distribution Service

   The Time Zone Data Distribution Service (TZDIST) [RFC7808] is a
   service that allows reliable, secure, and fast delivery of time zone
   data and leap second rules to client systems such as calendaring and
   scheduling applications or operating systems.

   A TZDIST service MAY supply time zone data to clients in the Time
   Zone Information Format.  Such a service MUST indicate that it
   supports this format by including the MIME media type "application/
   tzif" (Section 8.1) in its "capabilities" response (see Section 5.1
   of [RFC7808]).  A TZDIST service MAY also include the MIME media type
   "application/tzif-leap" (Section 8.2) in its "capabilities" response
   if it is able to generate TZif files containing leap second records.
   A TZDIST service MUST NOT advertise the "application/tzif-leap" MIME
   media type without also advertising "application/tzif".

   TZDIST clients MUST use the HTTP "Accept" [RFC7231] header field to
   indicate their preference to receive data in the "application/tzif"
   and/or "application/tzif-leap" formats.

5.1.  Truncating TZif Files

   As described in Section 3.9 of [RFC7808], a TZDIST service MAY
   truncate time zone transition data.  A truncated TZif file is valid
   from its first and up to, but not including, its last version 2+
   transition time, if present.

   When truncating the start of a TZif file, the service MUST supply in
   the version 2+ data a first transition time that is the start point
   of the truncation range.  As with untruncated TZif files, time type 0
   indicates local time immediately before the start point, and the time
   type of the first transition indicates local time thereafter.

   When truncating the end of a TZif file, the service MUST supply in
   the version 2+ data a last transition time that is the end point of
   the truncation range, and MUST supply an empty TZ string.  As with
   untruncated TZif files with empty TZ strings, a truncated TZif file
   does not indicate local time after the last transition.





Olson, et al.             Expires June 8, 2019                 [Page 14]

Internet-Draft                    TZif                     December 2018


   All represented information that falls inside the truncation range
   MUST be the same as that represented by a corresponding untruncated
   TZif file.

   TZDIST clients SHOULD NOT use a truncated TZif file (as described
   above) to interpret timestamps outside the truncation time range.

5.2.  Example TZDIST Request for TZif Data

   In this example, the client checks the server for the available
   formats and then requests that the time zone with a specific time
   zone identifier be returned in Time Zone Information Format.







































Olson, et al.             Expires June 8, 2019                 [Page 15]

Internet-Draft                    TZif                     December 2018


   Note that this example presumes that the time zone context path has
   been discovered (see [RFC7808] Section 4.2.1) to be "/tzdist".

   >> Request <<

   GET /tzdist/capabilities HTTP/1.1
   Host: tz.example.com

   >> Response <<

   HTTP/1.1 200 OK
   Date: Fri, 01 Jun 2018 14:52:23 GMT
   Content-Type: application/json; charset="utf-8"
   Content-Length: xxxx

   {
     "version": 1,

     "info": {
       "primary-source": "IANA:2018e",
       "formats": [
         "text/calendar",
         "application/tzif",
         "application/tzif-leap"
       ],
   ...
     },
   ...
   }


   >> Request <<

   GET /tzdist/zones/America%2FNew_York HTTP/1.1
   Host: tz.example.com
   Accept: application/tzif

   >> Response <<

   HTTP/1.1 200 OK
   Date: Fri, 01 Jun 2018 14:52:24 GMT
   Content-Type: application/tzif
   Content-Length: xxxx
   ETag: "123456789-000-111"

   TZif2...[binary data without leap second records]...
   EST5EDT,M3.2.0,M11.1.0




Olson, et al.             Expires June 8, 2019                 [Page 16]

Internet-Draft                    TZif                     December 2018


6.  Security Considerations

   The Time Zone Information Format contains no executable code and the
   format does not define any extensible areas that could be used to
   store such code.

   TZif contains counted arrays of data elements.  All counts should be
   checked when processing TZif objects to guard against references past
   the end of the object.

   TZif provides no confidentiality or integrity protection.  Time zone
   information is normally public and does not call for confidentiality
   protection.  Since time zone information is used in many critical
   applications, integrity protection may be required, and must be
   provided externally.

7.  Privacy Considerations

   The Time Zone Information Format contains publicly available data and
   the format does not define any extensible areas that could be used to
   store private data.

   As discussed in Section 9 of [RFC7808], transmission of time zone
   data over an insecure communications channel could leak the past,
   current, or future location of a device or user.  As such, TZif data
   transmitted over a public communications channel MUST be protected
   with a confidentiality layer such as that provided by Transport Layer
   Security (TLS) [RFC8446].

8.  IANA Considerations

   This document defines two MIME [RFC6838] media types for the exchange
   of data utilizing the Time Zone Information Format.

8.1.  application/tzif

   Type name:  application

   Subtype name:  tzif

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  binary

   Security considerations:  See Section 6 of this document.




Olson, et al.             Expires June 8, 2019                 [Page 17]

Internet-Draft                    TZif                     December 2018


   Interoperability considerations:  See Section 4 of this document.

   Published specification:  This specification.

   Applications that use this media type:  This media type is designed
      for widespread use by applications that need to use or exchange
      time zone information, such as the Time Zone Information Compiler
      (zic) [6] and the GNU C Library [7].  The Time Zone Distribution
      Service [RFC7808] can directly use this media type.

   Fragment identifier considerations:  N/A

   Additional information:

      Magic number(s):  The first 4 octets are 0x54, 0x5A, 0x69, 0x66

      File extensions(s):  N/A

      Macintosh file type code(s):  N/A

   Person & email address to contact for further
   information:
      Time Zone Database mailing list <tz@iana.org>

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See the "Author's Address" section of this document.

   Change controller:  IETF

8.2.  application/tzif-leap

   Type name:  application

   Subtype name:  tzif-leap

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  binary

   Security considerations:  See Section 6 of this document.

   Interoperability considerations:  See Section 4 of this document.




Olson, et al.             Expires June 8, 2019                 [Page 18]

Internet-Draft                    TZif                     December 2018


   Published specification:  This specification.

   Applications that use this media type:  This media type is designed
      for widespread use by applications that need to use or exchange
      time zone information, such as the Time Zone Information Compiler
      (zic) [8] and the GNU C Library [9].  The Time Zone Distribution
      Service [RFC7808] can directly use this media type.

   Fragment identifier considerations:  N/A

   Additional information:

      Magic number(s):  The first 4 octets are 0x54, 0x5A, 0x69, 0x66

      File extensions(s):  N/A

      Macintosh file type code(s):  N/A

   Person & email address to contact for further
   information:
      Time Zone Database mailing list <tz@iana.org>

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See the "Author's Address" section of this document.

   Change controller:  IETF

9.  Acknowledgments

   The authors would like to thank the following individuals for
   contributing their ideas and support for writing this specification:
   Michael Douglass, Ned Freed, Guy Harris, Eliot Lear, and Alexey
   Melnikov.

10.  References

10.1.  Normative References

   [POSIX]    IEEE, "Standard for Information Technology--Portable
              Operating System Interface (POSIX(R)) Base Specifications,
              Issue 7", IEEE 1003.1-2017,
              DOI 10.1109/IEEESTD.2018.8277153, January 2018,
              <http://pubs.opengroup.org/onlinepubs/9699919799/>.





Olson, et al.             Expires June 8, 2019                 [Page 19]

Internet-Draft                    TZif                     December 2018


              This standard is also
              <https://ieeexplore.ieee.org/servlet/
              opac?punumber=8277151> published by ieeexplore.ieee.org.

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7808]  Douglass, M. and C. Daboo, "Time Zone Data Distribution
              Service", RFC 7808, DOI 10.17487/RFC7808, March 2016,
              <https://www.rfc-editor.org/info/rfc7808>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
              Scheduling Core Object Specification (iCalendar)",
              RFC 5545, DOI 10.17487/RFC5545, September 2009,
              <https://www.rfc-editor.org/info/rfc5545>.

   [RFC6557]  Lear, E. and P. Eggert, "Procedures for Maintaining the
              Time Zone Database", BCP 175, RFC 6557,
              DOI 10.17487/RFC6557, February 2012,
              <https://www.rfc-editor.org/info/rfc6557>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.





Olson, et al.             Expires June 8, 2019                 [Page 20]

Internet-Draft                    TZif                     December 2018


   [tz-link]  Eggert, P. and A. Olson, "Sources for Time Zone and
              Daylight Saving Time Data", 2018,
              <https://www.iana.org/time-zones/repository/tz-link.html>.

10.3.  URIs

   [1] https://tools.ietf.org/html/bcp14

   [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/
       time.html

   [3] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
       V1_chap08.html#tag_08_03

   [4] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
       V1_chap08.html#tag_08_03

   [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
       V1_chap08.html#tag_08_03

   [6] http://man7.org/linux/man-pages/man8/zic.8.html

   [7] https://www.gnu.org/software/libc/

   [8] http://man7.org/linux/man-pages/man8/zic.8.html

   [9] https://www.gnu.org/software/libc/

   [10] https://github.com/eggert/tz/commits/master/tzfile.5

Appendix A.  Common Interoperability Issues

   This section documents common problems in implementing this
   specification.  Most of these are problems in generating TZif files
   for use by readers conforming to predecessors of this specification
   [10].  The goals of this section are:

   1.  to help TZif writers output files that avoid common pitfalls in
       older or buggy TZif readers,

   2.  to help TZif readers avoid common pitfalls when reading files
       generated by future TZif writers, and

   3.  to help any future specification authors see what sort of
       problems arise when the TZif format is changed.

   When new versions of the TZif format have been defined, a design goal
   has been that a reader can successfully use a TZif file even if the



Olson, et al.             Expires June 8, 2019                 [Page 21]

Internet-Draft                    TZif                     December 2018


   file is of a later TZif version than what the reader was designed
   for.  When complete compatibility was not achieved, an attempt was
   made to limit glitches to rarely-used timestamps, and to allow simple
   partial workarounds in writers designed to generate new-version data
   useful even for older-version readers.  This section attempts to
   document these compatibility issues and workarounds, as well as to
   document other common bugs in readers.

   Interoperability problems with TZif include the following:

   o  Some readers examine only version 1 data.  As a partial
      workaround, a writer can output as much version 1 data as
      possible.  However, a reader should ignore version 1 data, and
      should use version 2+ data even if the reader's native timestamps
      have only 32 bits.

   o  Some readers designed for version 2 might mishandle timestamps
      after a version 3 file's last transition, because they cannot
      parse extensions to POSIX in the TZ-like string.  As a partial
      workaround, a writer can output more transitions than necessary,
      so that only far-future timestamps are mishandled by version 2
      readers.

   o  Some readers designed for version 2 do not support permanent
      daylight saving time, e.g., a TZ string "EST5EDT,0/0,J365/25"
      denoting permanent Eastern Daylight Time (-04).  As a partial
      workaround, a writer can substitute standard time for the next
      time zone east, e.g., "AST4" for permanent Atlantic Standard Time
      (-04).

   o  Some readers ignore the footer, and instead predict future
      timestamps from the time type of the last transition.  As a
      partial workaround, a writer can output more transitions than
      necessary.

   o  Some readers do not use time type 0 for timestamps before the
      first transition, in that they infer a time type using a heuristic
      that does not always select time type 0.  As a partial workaround,
      a writer can output a dummy (no-op) first transition at an early
      time.

   o  Some readers mishandle timestamps before the first transition that
      has a timestamp not less than -2**31.  Readers that support only
      32-bit timestamps are likely to be more prone to this problem, for
      example, when they process 64-bit transitions only some of which
      are representable in 32 bits.  As a partial workaround, a writer
      can output a dummy transition at timestamp -2**31.




Olson, et al.             Expires June 8, 2019                 [Page 22]

Internet-Draft                    TZif                     December 2018


   o  Some readers mishandle a transition if its timestamp has the
      minimum possible signed 64-bit value.  Timestamps less than -2**59
      are not recommended.

   o  Some readers mishandle POSIX-style TZ strings that contain '<' or
      '>'.  As a partial workaround, a writer can avoid using '<' or '>'
      for time zone abbreviations containing only alphabetic characters.

   o  Many readers mishandle time zone abbreviations that contain non-
      ASCII characters.  These characters are not recommended.

   o  Some readers may mishandle time zone abbreviations that contain
      fewer than 3 or more than 6 characters, or that contain ASCII
      characters other than alphanumerics, '-', and '+'.  These
      abbreviations are not recommended.

   o  Some readers mishandle TZif files that specify daylight-saving
      time UT offsets that are less than the UT offsets for the
      corresponding standard time.  These readers do not support
      locations like Ireland, which uses the equivalent of the POSIX TZ
      string "IST-1GMT0,M10.5.0,M3.5.0/1", observing standard time (IST,
      +01) in summer and daylight saving time (GMT, +00) in winter.  As
      a partial workaround, a writer can output data for the equivalent
      of the POSIX TZ string "GMT0IST,M3.5.0/1,M10.5.0", thus swapping
      standard and daylight saving time.  Although this workaround
      misidentifies which part of the year uses daylight saving time, it
      records UT offsets and time zone abbreviations correctly.

   Some interoperability problems are reader bugs that are listed here
   mostly as warnings to developers of readers.

   o  Some readers do not support negative timestamps.  Developers of
      distributed applications should keep this in mind if they need to
      deal with pre-1970 data.

   o  Some readers mishandle timestamps before the first transition that
      has a nonnegative timestamp.  Readers that do not support negative
      timestamps are likely to be more prone to this problem.

   o  Some readers mishandle time zone abbreviations like "-08" that
      contain '+', '-', or digits.

   o  Some readers mishandle UT offsets that are out of the traditional
      range of -12 through +12 hours, and so do not support locations
      like Kiritimati that are outside this range.






Olson, et al.             Expires June 8, 2019                 [Page 23]

Internet-Draft                    TZif                     December 2018


   o  Some readers mishandle UT offsets in the range [-3599, -1] seconds
      from UT, because they integer-divide the offset by 3600 to get 0
      and then display the hour part as "+00".

   o  Some readers mishandle UT offsets that are not a multiple of one
      hour, or of 15 minutes, or of 1 minute.

Appendix B.  Example TZif Files

   The following sections contain annotated hexadecimal dumps of example
   TZif files.

   Note that these examples should only be considered informative.
   Although the example data entries are current as of the publication
   date of this document, the data will likely change in the future as
   leap seconds are added and changes are made to civil time.

B.1.  Version 1 File Representing UTC (with Leap Seconds)

   +-------+---------------+------------------+------------------------+
   | File  | Data Octets   | Record Name /    | Field Value            |
   | Offse | (hexadecimal) | Field Name       |                        |
   | t     |               |                  |                        |
   +-------+---------------+------------------+------------------------+
   | 000   | 54 5a 69 66   | magic            | "TZif"                 |
   | 004   | 00            | version          | 0 (1)                  |
   | 005   | 00 00 00 00   |                  |                        |
   |       | 00 00 00 00   |                  |                        |
   |       | 00 00 00 00   |                  |                        |
   |       | 00 00 00      |                  |                        |
   | 020   | 00 00 00 01   | isutccnt         | 1                      |
   | 024   | 00 00 00 01   | isstdcnt         | 1                      |
   | 028   | 00 00 00 1b   | isleapcnt        | 27                     |
   | 032   | 00 00 00 00   | timecnt          | 0                      |
   | 036   | 00 00 00 01   | typecnt          | 1                      |
   | 040   | 00 00 00 04   | charcnt          | 4                      |
   |       |               |                  |                        |
   |       |               | localtimetype[0] |                        |
   | 044   | 00 00 00 00   | utcoff           | 00:00                  |
   | 048   | 00            | isdst            | 0 (no)                 |
   | 049   | 00            | desigidx         | 0                      |
   |       |               |                  |                        |
   | 050   | 55 54 43 00   | designations[0]  | "UTC"                  |
   |       |               |                  |                        |
   |       |               | leapsecond[0]    |                        |
   | 054   | 04 b2 58 00   | occurrence       | 78796800               |
   |       |               |                  | (1972-06-30T23:59:60Z) |
   | 058   | 00 00 00 01   | correction       | 1                      |



Olson, et al.             Expires June 8, 2019                 [Page 24]

Internet-Draft                    TZif                     December 2018


   |       |               |                  |                        |
   |       |               | leapsecond[1]    |                        |
   | 062   | 05 a4 ec 01   | occurrence       | 94694401               |
   |       |               |                  | (1972-12-31T23:59:60Z) |
   | 066   | 00 00 00 02   | correction       | 2                      |
   |       |               |                  |                        |
   |       |               | leapsecond[2]    |                        |
   | 070   | 07 86 1f 82   | occurrence       | 126230402              |
   |       |               |                  | (1973-12-31T23:59:60Z) |
   | 074   | 00 00 00 03   | correction       | 3                      |
   |       |               |                  |                        |
   |       |               | leapsecond[3]    |                        |
   | 078   | 09 67 53 03   | occurrence       | 157766403              |
   |       |               |                  | (1974-12-31T23:59:60Z) |
   | 082   | 00 00 00 04   | correction       | 4                      |
   |       |               |                  |                        |
   |       |               | leapsecond[4]    |                        |
   | 086   | 0b 48 86 84   | occurrence       | 189302404              |
   |       |               |                  | (1975-12-31T23:59:60Z) |
   | 090   | 00 00 00 05   | correction       | 5                      |
   |       |               |                  |                        |
   |       |               | leapsecond[5]    |                        |
   | 094   | 0d 2b 0b 85   | occurrence       | 220924805              |
   |       |               |                  | (1976-12-31T23:59:60Z) |
   | 098   | 00 00 00 06   | correction       | 6                      |
   |       |               |                  |                        |
   |       |               | leapsecond[6]    |                        |
   | 102   | 0f 0c 3f 06   | occurrence       | 252460806              |
   |       |               |                  | (1977-12-31T23:59:60Z) |
   | 106   | 00 00 00 07   | correction       | 7                      |
   |       |               |                  |                        |
   |       |               | leapsecond[7]    |                        |
   | 110   | 10 ed 72 87   | occurrence       | 283996807              |
   |       |               |                  | (1978-12-31T23:59:60Z) |
   | 114   | 00 00 00 08   | correction       | 8                      |
   |       |               |                  |                        |
   |       |               | leapsecond[8]    |                        |
   | 118   | 12 ce a6 08   | occurrence       | 315532808              |
   |       |               |                  | (1979-12-31T23:59:60Z) |
   | 122   | 00 00 00 09   | correction       | 9                      |
   |       |               |                  |                        |
   |       |               | leapsecond[9]    |                        |
   | 126   | 15 9f ca 89   | occurrence       | 362793609              |
   |       |               |                  | (1981-06-30T23:59:60Z) |
   | 130   | 00 00 00 0a   | correction       | 10                     |
   |       |               |                  |                        |
   |       |               | leapsecond[10]   |                        |
   | 134   | 17 80 fe 0a   | occurrence       | 394329610              |



Olson, et al.             Expires June 8, 2019                 [Page 25]

Internet-Draft                    TZif                     December 2018


   |       |               |                  | (1982-06-30T23:59:60Z) |
   | 138   | 00 00 00 0b   | correction       | 11                     |
   |       |               |                  |                        |
   |       |               | leapsecond[11]   |                        |
   | 142   | 19 62 31 8b   | occurrence       | 425865611              |
   |       |               |                  | (1983-06-30T23:59:60Z) |
   | 146   | 00 00 00 0c   | correction       | 12                     |
   |       |               |                  |                        |
   |       |               | leapsecond[12]   |                        |
   | 150   | 1d 25 ea 0c   | occurrence       | 489024012              |
   |       |               |                  | (1985-06-30T23:59:60Z) |
   | 154   | 00 00 00 0d   | correction       | 13                     |
   |       |               |                  |                        |
   |       |               | leapsecond[13]   |                        |
   | 158   | 21 da e5 0d   | occurrence       | 567993613              |
   |       |               |                  | (1987-12-31T23:59:60Z) |
   | 162   | 00 00 00 0e   | correction       | 14                     |
   |       |               |                  |                        |
   |       |               | leapsecond[14]   |                        |
   | 166   | 25 9e 9d 8e   | occurrence       | 631152014              |
   |       |               |                  | (1989-12-31T23:59:60Z) |
   | 170   | 00 00 00 0f   | correction       | 15                     |
   |       |               |                  |                        |
   |       |               | leapsecond[15]   |                        |
   | 174   | 27 7f d1 0f   | occurrence       | 662688015              |
   |       |               |                  | (1990-12-31T23:59:60Z) |
   | 178   | 00 00 00 10   | correction       | 16                     |
   |       |               |                  |                        |
   |       |               | leapsecond[16]   |                        |
   | 182   | 2a 50 f5 90   | occurrence       | 709948816              |
   |       |               |                  | (1992-06-30T23:59:60Z) |
   | 186   | 00 00 00 11   | correction       | 17                     |
   |       |               |                  |                        |
   |       |               | leapsecond[17]   |                        |
   | 190   | 2c 32 29 11   | occurrence       | 741484817              |
   |       |               |                  | (1993-06-30T23:59:60Z) |
   | 194   | 00 00 00 12   | correction       | 18                     |
   |       |               |                  |                        |
   |       |               | leapsecond[18]   |                        |
   | 198   | 2e 13 5c 92   | occurrence       | 773020818              |
   |       |               |                  | (1994-06-30T23:59:60Z) |
   | 202   | 00 00 00 13   | correction       | 19                     |
   |       |               |                  |                        |
   |       |               | leapsecond[19]   |                        |
   | 206   | 30 e7 24 13   | occurrence       | 820454419              |
   |       |               |                  | (1995-12-31T23:59:60Z) |
   | 210   | 00 00 00 14   | correction       | 20                     |
   |       |               |                  |                        |



Olson, et al.             Expires June 8, 2019                 [Page 26]

Internet-Draft                    TZif                     December 2018


   |       |               | leapsecond[20]   |                        |
   | 214   | 33 b8 48 94   | occurrence       | 867715220              |
   |       |               |                  | (1997-06-30T23:59:60Z) |
   | 218   | 00 00 00 15   | correction       | 21                     |
   |       |               |                  |                        |
   |       |               | leapsecond[21]   |                        |
   | 222   | 36 8c 10 15   | occurrence       | 915148821              |
   |       |               |                  | (1998-12-31T23:59:60Z) |
   | 226   | 00 00 00 16   | correction       | 22                     |
   |       |               |                  |                        |
   |       |               | leapsecond[22]   |                        |
   | 230   | 43 b7 1b 96   | occurrence       | 1136073622             |
   |       |               |                  | (2005-12-31T23:59:60Z) |
   | 234   | 00 00 00 17   | correction       | 23                     |
   |       |               |                  |                        |
   |       |               | leapsecond[23]   |                        |
   | 238   | 49 5c 07 97   | occurrence       | 1230768023             |
   |       |               |                  | (2008-12-31T23:59:60Z) |
   | 242   | 00 00 00 18   | correction       | 24                     |
   |       |               |                  |                        |
   |       |               | leapsecond[24]   |                        |
   | 246   | 4f ef 93 18   | occurrence       | 1341100824             |
   |       |               |                  | (2012-06-30T23:59:60Z) |
   | 250   | 00 00 00 19   | correction       | 25                     |
   |       |               |                  |                        |
   |       |               | leapsecond[25]   |                        |
   | 254   | 55 93 2d 99   | occurrence       | 1435708825             |
   |       |               |                  | (2015-06-30T23:59:60Z) |
   | 258   | 00 00 00 1a   | correction       | 26                     |
   |       |               |                  |                        |
   |       |               | leapsecond[26]   |                        |
   | 262   | 58 68 46 9a   | occurrence       | 1483228826             |
   |       |               |                  | (2016-12-31T23:59:60Z) |
   | 266   | 00 00 00 1b   | correction       | 27                     |
   |       |               |                  |                        |
   | 270   | 00            | UT/local[0]      | 0 (local)              |
   |       |               |                  |                        |
   | 271   | 00            | standard/wall[0] | 0 (wall)               |
   +-------+---------------+------------------+------------------------+

   To determine TAI corresponding to 2000-01-01T00:00:00Z (UNIX time =
   946684800), the following procedure would be followed:

   1.  Find the the latest leap second occurrence prior to the time of
       interest (leapsecond[21]) and note the correction value (LEAPCORR
       = 22).





Olson, et al.             Expires June 8, 2019                 [Page 27]

Internet-Draft                    TZif                     December 2018


   2.  Add LEAPCORR + 10 to the time of interest to yield TAI of
       2000-01-01T00:00:32.

B.2.  Version 2 File Representing Pacific/Honolulu

   +--------+--------------+------------------+------------------------+
   | File   | Hexadecimal  | Record Name /    | Field Value            |
   | Offset | Octets       | Field Name       |                        |
   +--------+--------------+------------------+------------------------+
   | 000    | 54 5a 69 66  | magic            | "TZif"                 |
   | 004    | 32           | version          | '2' (2)                |
   | 005    | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00     |                  |                        |
   | 020    | 00 00 00 06  | isutccnt         | 6                      |
   | 024    | 00 00 00 06  | isstdcnt         | 6                      |
   | 028    | 00 00 00 00  | isleapcnt        | 0                      |
   | 032    | 00 00 00 07  | timecnt          | 7                      |
   | 036    | 00 00 00 06  | typecnt          | 6                      |
   | 040    | 00 00 00 14  | charcnt          | 20                     |
   |        |              |                  |                        |
   | 044    | 80 00 00 00  | trans time[0]    | -2147483648            |
   |        |              |                  | (1901-12-13T20:45:52Z) |
   | 048    | bb 05 43 48  | trans time[1]    | -1157283000            |
   |        |              |                  | (1933-04-30T12:30:00Z) |
   | 052    | bb 21 71 58  | trans time[2]    | -1155436200            |
   |        |              |                  | (1933-05-21T21:30:00Z) |
   | 056    | cb 89 3d c8  | trans time[3]    | -880198200             |
   |        |              |                  | (1942-02-09T12:30:00Z) |
   | 060    | d2 23 f4 70  | trans time[4]    | -769395600             |
   |        |              |                  | (1945-08-14T23:00:00Z) |
   | 064    | d2 61 49 38  | trans time[5]    | -765376200             |
   |        |              |                  | (1945-09-30T11:30:00Z) |
   | 068    | d5 8d 73 48  | trans time[6]    | -712150200             |
   |        |              |                  | (1947-06-08T12:30:00Z) |
   |        |              |                  |                        |
   | 072    | 01           | trans type[0]    | 1                      |
   | 073    | 02           | trans type[1]    | 2                      |
   | 074    | 01           | trans type[2]    | 1                      |
   | 075    | 03           | trans type[3]    | 3                      |
   | 076    | 04           | trans type[4]    | 4                      |
   | 077    | 01           | trans type[5]    | 1                      |
   | 078    | 05           | trans type[6]    | 5                      |
   |        |              |                  |                        |
   |        |              | localtimetype[0] |                        |
   | 079    | ff ff 6c 02  | utcoff           | -37886 (-10:21:26)     |
   | 083    | 00           | isdst            | 0 (no)                 |



Olson, et al.             Expires June 8, 2019                 [Page 28]

Internet-Draft                    TZif                     December 2018


   | 084    | 00           | desigidx         | 0                      |
   |        |              |                  |                        |
   |        |              | localtimetype[1] |                        |
   | 085    | ff ff 6c 58  | utcoff           | -37800 (-10:30)        |
   | 089    | 00           | isdst            | 0 (no)                 |
   | 090    | 04           | desigidx         | 4                      |
   |        |              |                  |                        |
   |        |              | localtimetype[2] |                        |
   | 091    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 095    | 01           | isdst            | 1 (yes)                |
   | 096    | 08           | desigidx         | 8                      |
   |        |              |                  |                        |
   |        |              | localtimetype[3] |                        |
   | 097    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 101    | 01           | isdst            | 1 (yes)                |
   | 102    | 0c           | desigidx         | 12                     |
   |        |              |                  |                        |
   |        |              | localtimetype[4] |                        |
   | 103    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 107    | 01           | isdst            | 1 (yes)                |
   | 108    | 10           | desigidx         | 16                     |
   |        |              |                  |                        |
   |        |              | localtimetype[5] |                        |
   | 109    | ff ff 73 60  | utcoff           | -36000 (-10:00)        |
   | 113    | 00           | isdst            | 0 (no)                 |
   | 114    | 04           | desigidx         | 4                      |
   |        |              |                  |                        |
   | 115    | 4c 4d 54 00  | designations[0]  | "LMT"                  |
   | 119    | 48 53 54 00  | designations[4]  | "HST"                  |
   | 123    | 48 44 54 00  | designations[8]  | "HDT"                  |
   | 127    | 48 57 54 00  | designations[12] | "HWT"                  |
   | 131    | 48 50 54 00  | designations[16] | "HPT"                  |
   |        |              |                  |                        |
   | 135    | 00           | UT/local[0]      | 1 (UT)                 |
   | 136    | 00           | UT/local[1]      | 0 (local)              |
   | 137    | 00           | UT/local[2]      | 0 (local)              |
   | 138    | 00           | UT/local[3]      | 0 (local)              |
   | 139    | 01           | UT/local[4]      | 1 (UT)                 |
   | 140    | 00           | UT/local[5]      | 0 (local)              |
   |        |              |                  |                        |
   | 141    | 00           | standard/wall[0] | 1 (standard)           |
   | 142    | 00           | standard/wall[1] | 0 (wall)               |
   | 143    | 00           | standard/wall[2] | 0 (wall)               |
   | 144    | 00           | standard/wall[3] | 0 (wall)               |
   | 145    | 01           | standard/wall[4] | 1 (standard)           |
   | 146    | 00           | standard/wall[5] | 0 (wall)               |
   |        |              |                  |                        |
   | 147    | 54 5a 69 66  | magic            | "TZif"                 |



Olson, et al.             Expires June 8, 2019                 [Page 29]

Internet-Draft                    TZif                     December 2018


   | 151    | 32           | version          | '2' (2)                |
   | 152    | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00     |                  |                        |
   | 167    | 00 00 00 06  | isutccnt         | 6                      |
   | 171    | 00 00 00 06  | isstdcnt         | 6                      |
   | 175    | 00 00 00 00  | isleapcnt        | 0                      |
   | 179    | 00 00 00 07  | timecnt          | 7                      |
   | 183    | 00 00 00 06  | typecnt          | 6                      |
   | 187    | 00 00 00 14  | charcnt          | 20                     |
   |        |              |                  |                        |
   | 191    | ff ff ff ff  | trans time[0]    | -2334101314            |
   |        | 74 e0 70 be  |                  | (1896-01-13T22:31:26Z) |
   | 199    | ff ff ff ff  | trans time[1]    | -1157283000            |
   |        | bb 05 43 48  |                  | (1933-04-30T12:30:00Z) |
   | 207    | ff ff ff ff  | trans time[2]    | -1155436200            |
   |        | bb 21 71 58  |                  | (1933-05-21T21:30:00Z) |
   | 215    | ff ff ff ff  | trans time[3]    | -880198200             |
   |        | cb 89 3d c8  |                  | (1942-02-09T12:30:00Z) |
   | 223    | ff ff ff ff  | trans time[4]    | -769395600             |
   |        | d2 23 f4 70  |                  | (1945-08-14T23:00:00Z) |
   | 231    | ff ff ff ff  | trans time[5]    | -765376200             |
   |        | d2 61 49 38  |                  | (1945-09-30T11:30:00Z) |
   | 239    | ff ff ff ff  | trans time[6]    | -712150200             |
   |        | d5 8d 73 48  |                  | (1947-06-08T12:30:00Z) |
   |        |              |                  |                        |
   | 247    | 01           | trans type[0]    | 1                      |
   | 248    | 02           | trans type[1]    | 2                      |
   | 249    | 01           | trans type[2]    | 1                      |
   | 250    | 03           | trans type[3]    | 3                      |
   | 251    | 04           | trans type[4]    | 4                      |
   | 252    | 01           | trans type[5]    | 1                      |
   | 253    | 05           | trans type[6]    | 5                      |
   |        |              |                  |                        |
   |        |              | localtimetype[0] |                        |
   | 254    | ff ff 6c 02  | utcoff           | -37886 (-10:21:26)     |
   | 258    | 00           | isdst            | 0 (no)                 |
   | 259    | 00           | desigidx         | 0                      |
   |        |              |                  |                        |
   |        |              | localtimetype[1] |                        |
   | 260    | ff ff 6c 58  | utcoff           | -37800 (-10:30)        |
   | 264    | 00           | isdst            | 0 (no)                 |
   | 265    | 04           | desigidx         | 4                      |
   |        |              |                  |                        |
   |        |              | localtimetype[2] |                        |
   | 266    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 270    | 01           | isdst            | 1 (yes)                |



Olson, et al.             Expires June 8, 2019                 [Page 30]

Internet-Draft                    TZif                     December 2018


   | 271    | 08           | desigidx         | 8                      |
   |        |              |                  |                        |
   |        |              | localtimetype[3] |                        |
   | 272    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 276    | 01           | isdst            | 1 (yes)                |
   | 277    | 0c           | desigidx         | 12                     |
   |        |              |                  |                        |
   |        |              | localtimetype[4] |                        |
   | 278    | ff ff 7a 68  | utcoff           | -34200 (-09:30)        |
   | 282    | 01           | isdst            | 1 (yes)                |
   | 283    | 10           | desigidx         | 16                     |
   |        |              |                  |                        |
   |        |              | localtimetype[5] |                        |
   | 284    | ff ff 73 60  | utcoff           | -36000 (-10:00)        |
   | 288    | 00           | isdst            | 0 (no)                 |
   | 289    | 04           | desigidx         | 4                      |
   |        |              |                  |                        |
   | 290    | 4c 4d 54 00  | designations[0]  | "LMT"                  |
   | 294    | 48 53 54 00  | designations[4]  | "HST"                  |
   | 298    | 48 44 54 00  | designations[8]  | "HDT"                  |
   | 302    | 48 57 54 00  | designations[12] | "HWT"                  |
   | 306    | 48 50 54 00  | designations[16] | "HPT"                  |
   |        |              |                  |                        |
   | 310    | 00           | UT/local[0]      | 0 (local)              |
   | 311    | 00           | UT/local[1]      | 0 (local)              |
   | 312    | 00           | UT/local[2]      | 0 (local)              |
   | 313    | 00           | UT/local[3]      | 0 (local)              |
   | 314    | 01           | UT/local[4]      | 1 (UT)                 |
   | 315    | 00           | UT/local[5]      | 0 (local)              |
   |        |              |                  |                        |
   | 316    | 00           | standard/wall[0] | 0 (wall)               |
   | 317    | 00           | standard/wall[1] | 0 (wall)               |
   | 318    | 00           | standard/wall[2] | 0 (wall)               |
   | 319    | 00           | standard/wall[3] | 0 (wall)               |
   | 320    | 01           | standard/wall[4] | 1 (standard)           |
   | 321    | 00           | standard/wall[5] | 0 (wall)               |
   |        |              |                  |                        |
   | 322    | 0a           | NL               | '\n'                   |
   | 323    | 48 53 54 31  | TZ string        | "HST10"                |
   |        | 30           |                  |                        |
   | 328    | 0a           | NL               | '\n'                   |
   +--------+--------------+------------------+------------------------+

   To determine the local time in this time zone corresponding to
   1933-05-04T12:00:00Z (UNIX time = -1156939200), the following
   procedure would be followed:





Olson, et al.             Expires June 8, 2019                 [Page 31]

Internet-Draft                    TZif                     December 2018


   1.  Find the the latest time transition prior to the time of interest
       (trans time[1]).

   2.  Reference the corresponding transition type (trans type[1]) to
       determine the local time type index (2).

   3.  Reference the corresponding local time type (localtimetype[2]) to
       determine the offset from UTC (-09:30), the daylight saving
       indicator (1 = yes), and the index into the time zone designation
       strings (8).

   4.  Lookup the corresponding time zone designation string
       (designations[8] = "HDT").

   5.  Add the UTC offset to the time of interest to yield a local
       daylight saving time of 1933-05-04T02:30:00-09:30 (HDT).

   To determine the local time in this time zone corresponding to
   2019-01-01T00:00:00Z (UNIX time = 1546300800), the following
   procedure would be followed:

   1.  Find the the latest time transition prior to the time of interest
       (there is no such transition).

   2.  Lookup the TZ string in the footer ("HST10"), which indicates
       that the time zone designation is "HST" year round, and the
       offset to UTC is 10:00.

   3.  Subtract the UTC offset from the time of interest to yield a
       standard local time of 2018-12-31T14:00:00-10:00 (HST).

B.3.  Truncated Version 3 File Representing Asia/Jerusalem

   The following TZif file has been truncated to start on
   2038-01-01T00:00:00Z.

   +--------+--------------+------------------+------------------------+
   | File   | Hexadecimal  | Record Name /    | Field Value            |
   | Offset | Octets       | Field Name       |                        |
   +--------+--------------+------------------+------------------------+
   | 000    | 54 5a 69 66  | magic            | "TZif"                 |
   | 004    | 33           | version          | '3' (3)                |
   | 005    | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00     |                  |                        |
   | 020    | 00 00 00 00  | isutccnt         | 0                      |
   | 024    | 00 00 00 00  | isstdcnt         | 0                      |



Olson, et al.             Expires June 8, 2019                 [Page 32]

Internet-Draft                    TZif                     December 2018


   | 028    | 00 00 00 00  | isleapcnt        | 0                      |
   | 032    | 00 00 00 00  | timecnt          | 0                      |
   | 036    | 00 00 00 00  | typecnt          | 0                      |
   | 040    | 00 00 00 00  | charcnt          | 0                      |
   |        |              |                  |                        |
   | 044    | 54 5a 69 66  | magic            | "TZif"                 |
   | 048    | 33           | version          | '3' (3)                |
   | 049    | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00 00  |                  |                        |
   |        | 00 00 00     |                  |                        |
   | 064    | 00 00 00 03  | isutccnt         | 1                      |
   | 068    | 00 00 00 03  | isstdcnt         | 1                      |
   | 072    | 00 00 00 00  | isleapcnt        | 0                      |
   | 076    | 00 00 00 03  | timecnt          | 1                      |
   | 080    | 00 00 00 03  | typecnt          | 1                      |
   | 084    | 00 00 00 08  | charcnt          | 4                      |
   |        |              |                  |                        |
   | 088    | 00 00 00 00  | trans time[0]    | 2145916800             |
   |        | 7f e8 17 80  |                  | (2038-01-01T00:00:00Z) |
   |        |              |                  |                        |
   | 096    | 00           | trans type[0]    | 0                      |
   |        |              |                  |                        |
   |        |              | localtimetype[0] |                        |
   | 097    | 00 00 1c 20  | utcoff           | 7200 (+02:00)          |
   | 101    | 00           | isdst            | 0 (no)                 |
   | 102    | 00           | desigidx         | 0                      |
   |        |              |                  |                        |
   | 103    | 49 53 54 00  | designations[0]  | "IST"                  |
   |        |              |                  |                        |
   | 107    | 01           | UT/local[0]      | 1 (UT)                 |
   |        |              |                  |                        |
   | 108    | 01           | standard/wall[0] | 1 (standard)           |
   |        |              |                  |                        |
   | 109    | 0a           | NL               | '\n'                   |
   | 110    | 49 53 54 2d  | TZ string        | "IST-2IDT,             |
   |        | 32 49 44 54  |                  | M3.4.4/26,M10.5.0"     |
   |        | 2c 4d 33 2e  |                  |                        |
   |        | 34 2e 34 2f  |                  |                        |
   |        | 32 36 2c 4d  |                  |                        |
   |        | 31 30 2e 35  |                  |                        |
   |        | 2e 30        |                  |                        |
   | 136    | 0a           | NL               | '\n'                   |
   +--------+--------------+------------------+------------------------+







Olson, et al.             Expires June 8, 2019                 [Page 33]

Internet-Draft                    TZif                     December 2018


Appendix C.  Change History (To be removed by RFC Editor before
             publication)

   Changes since -15:

   o  Addressed IESG comments from Ben Campbell.

   o  Addressed IESG comments from Spencer Dawkins.

   o  Addressed IESG comments from Benjamin Kaduk.

   o  Added annotated example files.

   o  Minor editorial changes.

   Changes since -14:

   o  Addressed last call comments from Tom Petch.

   o  Addressed last call comments from Qin Wu.

   o  Addressed last call comments from Dale Worley.

   Changes since -13:

   o  Added text to Privacy Considerations.

   Changes since -12:

   o  Added reference to RFC0020.

   o  Fully fleshed out application/tzif-leap declaration rather than
      referencing application/tzif.

   o  Added definition for "Leap Second Correction".

   o  Added external references directly to the relevant sections of
      POSIX.

   Changes since -11:

   o  Removed text requiring leapcnt by non-zero for application/tzif-
      leap files.

   Changes since -10:

   o  Removed text mandating all TZDIST features be supported.




Olson, et al.             Expires June 8, 2019                 [Page 34]

Internet-Draft                    TZif                     December 2018


   o  Minor editorial changes.

   Changes since -09:

   o  Removed "Update 7808" from header as this spec doesn't introduce
      new TZDIST functionality.

   o  Added text regarding truncation of TZif via TZDIST.

   o  Expanded what this spec DOESN'T define.

   o  Added reasons for some of the recommended practices.

   o  Added common interoperability issues appendix.

   o  Minor editorial changes.

   Changes since -08:

   o  Clarifying text regarding MIME types.

   o  Consolidated/referenced duplicate security and interoperability
      text.

   o  Switched to 'octets' instead of 'characters' when describing time
      zone designations.

   o  Minor editorial changes.

   Changes since -07:

   o  Clarifying text regarding TZ string.

   o  Added "application/tzif-leap" MIME media type.

   o  New reference for zic(8) man page.

   o  Minor editorial changes.

   Changes since -06:

   o  Added definition of UNIX Leap Time and used it to describe
      transition times and leap second occurrences.

   o  Moved TZif generation recommendations into discussion of version
      field.

   o  Repeated TZif generation recommendations in TZDIST section.



Olson, et al.             Expires June 8, 2019                 [Page 35]

Internet-Draft                    TZif                     December 2018


   o  Rewrote part of the TZ string text.

   o  Minor editorial changes.

   Changes since -05:

   o  Clarify TAI, leap seconds, some descriptions, and some field
      values/ranges with text from Paul Eggert.

   o  Refined MIME declaration based on feedback from Ned Freed.

   Changes since -04:

   o  Edited text discussing timestamps before first and after last
      transition.

   o  Specified legal range of time type indices and time zone
      designation indices.

   o  Notes that corrections in adjacent leap second records must differ
      by one.

   o  Added recommendations to eliminate unused space.

   o  Minor editorial changes.

   Changes since -03:

   o  Removed definition of GMT.

   o  Updated definitions of UTC, TAI, and UT

   o  Switched to using UT rather than UTC.

   o  Added more text about the use of standard/wall and UT/local
      indicators.

   o  Added Acknowledgments.

   o  Minor editorial changes.

   Changes since -02:

   o  Updated definitions of Standard Time and DST.

   o  Added definitions of GMT and UT.

   o  Added a definition of Time Zone Data from RFC7808.



Olson, et al.             Expires June 8, 2019                 [Page 36]

Internet-Draft                    TZif                     December 2018


   o  Removed sentence stating that TZDB is accurate.

   o  Added more text for standard/wall and UTC/local indicators and
      counts.

   o  Added text discussing timestamps before first and after last
      transition.

   o  Added more guidance text regarding 32-bit and 64-bit data
      consistency.

   o  Minor editorial changes.

   Changes since -01:

   o  Renamed "POSIX Time" to "UNIX Time" and noted that values can be
      negative.

   o  Noted that signed values MUST be represented using two's
      complement.

   o  Renamed "POSIX TZ string" to "TZ string" and noted that it can be
      empty.

   o  Moved TZ string extensions into its own subsection with examples.

   o  Renamed leap second "epoch" to "occurrence".

   o  Editorial changes from Paul Eggert.

   Changes since -00:

   o  Split TZif format description into a general overview and 3
      subsections.

   o  Updated Keywords boilerplate.

   o  Updated POSIX reference.

   o  Editorial changes from Eliot Lear.

Authors' Addresses

   Arthur David Olson

   Email: arthurdavidolson@gmail.com





Olson, et al.             Expires June 8, 2019                 [Page 37]

Internet-Draft                    TZif                     December 2018


   Paul Eggert
   University of California, Los Angeles

   Email: eggert@cs.ucla.edu


   Kenneth Murchison
   FastMail US LLC

   Email: murch@fastmailteam.com









































Olson, et al.             Expires June 8, 2019                 [Page 38]