Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8536

The Time Zone Information Format (TZif)

Pages: 34
Proposed Standard
Errata
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC8536 - Page 1
Internet Engineering Task Force (IETF)                          A. Olson
Request for Comments: 8536
Category: Standards Track                                      P. Eggert
ISSN: 2070-1721                                                     UCLA
                                                            K. Murchison
                                                                FastMail
                                                           February 2019


                The Time Zone Information Format (TZif)

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 media types for this format are also defined. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8536. Copyright Notice Copyright (c) 2019 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Top   ToC   RFC8536 - Page 2

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. TZ String Extensions . . . . . . . . . . . . . . . . 13 4. Interoperability Considerations . . . . . . . . . . . . . . . 13 5. Use with the Time Zone Data Distribution Service . . . . . . 14 5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 15 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Common Interoperability Issues . . . . . . . . . . . 21 Appendix B. Example TZif Files . . . . . . . . . . . . . . . . . 23 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 . . 33 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
Top   ToC   RFC8536 - Page 3

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 capable of generating and reading files in this format [tz-link]. 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 [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 but without leap-second adjustments.
Top   ToC   RFC8536 - Page 4
   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.

   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.
Top   ToC   RFC8536 - Page 5
   UNIX Time:  The time as returned by the time() function provided by
      the C programming language (see Section 3 of the "System
      Interfaces" volume 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".

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. Files from versions 2 and 3 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.
Top   ToC   RFC8536 - Page 6
   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:

                        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 [RFC20] sequence "TZif" (0x54 0x5A 0x69 0x66), which identifies the file as utilizing the Time Zone Information Format.
Top   ToC   RFC8536 - Page 7
   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.

      '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 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.
Top   ToC   RFC8536 - Page 8
   Although the version 1 and 2+ headers have the same format, magic
   number, and version fields, their count fields may differ, because
   the version 1 data can be a subset of the version 2+ data.

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 bits (TIME_SIZE = 4 octets). In the version 2+ data block, present only in version 2 and 3 files, time values are 64 bits (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.
Top   ToC   RFC8536 - Page 9
      (-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 outlandishly negative timestamps.)

   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 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 of 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]; it 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".
Top   ToC   RFC8536 - Page 10
   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.

   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.  The value
      MUST be set to one (1) if the corresponding UT/local indicator is
Top   ToC   RFC8536 - Page 11
      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
      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; otherwise, it is unspecified.  If there are
   no transitions, local time for all timestamps is specified by the TZ
   string in the footer if present and nonempty; otherwise, it is
   specified by time type 0.

   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.
Top   ToC   RFC8536 - Page 12

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). 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 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. In other words, evaluating the TZ string at the time of the last transition should yield the same time type as was specified in the last transition. The string MUST NOT contain NUL octets or be NUL-terminated, and it 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.
Top   ToC   RFC8536 - Page 13

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

4. Interoperability Considerations

The following practices help ensure the 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 sub-sequence 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
Top   ToC   RFC8536 - Page 14
      with current readers about timestamps within the contiguous sub-
      sequence.  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).

      *  "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 media type "application/tzif" (Section 8.1) in its "capabilities" response (see Section 5.1 of [RFC7808]). A TZDIST service MAY also include the 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" media type without also advertising "application/tzif".
Top   ToC   RFC8536 - Page 15
   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. 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.
Top   ToC   RFC8536 - Page 16
   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


(next page on part 2)

Next Section