diff options
Diffstat (limited to 'doc/rfc/rfc8536.txt')
| -rw-r--r-- | doc/rfc/rfc8536.txt | 1907 |
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc8536.txt b/doc/rfc/rfc8536.txt new file mode 100644 index 0000000..e475f2d --- /dev/null +++ b/doc/rfc/rfc8536.txt @@ -0,0 +1,1907 @@ + + + + + + +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. + + + + + +Olson, et al. Standards Track [Page 1] + +RFC 8536 TZif February 2019 + + +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 + + + + + + + + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 2] + +RFC 8536 TZif February 2019 + + +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. + + + + + +Olson, et al. Standards Track [Page 3] + +RFC 8536 TZif February 2019 + + + 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. + + + + + + + +Olson, et al. Standards Track [Page 4] + +RFC 8536 TZif February 2019 + + + 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. + + + + +Olson, et al. Standards Track [Page 5] + +RFC 8536 TZif February 2019 + + + 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. + + + +Olson, et al. Standards Track [Page 6] + +RFC 8536 TZif February 2019 + + + 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. + + + +Olson, et al. Standards Track [Page 7] + +RFC 8536 TZif February 2019 + + + 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. + + + + +Olson, et al. Standards Track [Page 8] + +RFC 8536 TZif February 2019 + + + (-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". + + + + + + + +Olson, et al. Standards Track [Page 9] + +RFC 8536 TZif February 2019 + + + 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 + + + +Olson, et al. Standards Track [Page 10] + +RFC 8536 TZif February 2019 + + + 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. + + + + + + + + + + +Olson, et al. Standards Track [Page 11] + +RFC 8536 TZif February 2019 + + +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. + + + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 12] + +RFC 8536 TZif February 2019 + + +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 + + + +Olson, et al. Standards Track [Page 13] + +RFC 8536 TZif February 2019 + + + 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". + + + +Olson, et al. Standards Track [Page 14] + +RFC 8536 TZif February 2019 + + + 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. + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 15] + +RFC 8536 TZif February 2019 + + + 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. Standards Track [Page 16] + +RFC 8536 TZif February 2019 + + +6. Security Considerations + + The Time Zone Information Format contains no executable code, and it + 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 it 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 media types [RFC6838] 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 RFC 8536. + + + + +Olson, et al. Standards Track [Page 17] + +RFC 8536 TZif February 2019 + + + Interoperability considerations: See Section 4 of RFC 8536. + + 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) [ZIC] and the GNU C Library [GNU-C]. 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 "Authors' Addresses" section of RFC 8536. + + 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 RFC 8536. + + Interoperability considerations: See Section 4 of RFC 8536. + + Published specification: This specification. + + + +Olson, et al. Standards Track [Page 18] + +RFC 8536 TZif February 2019 + + + 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) [ZIC] and the GNU C Library [GNU-C]. 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 "Authors' Addresses" section of RFC 8536. + + Change controller: IETF + +9. References + +9.1. Normative References + + [GNU-C] "The GNU C Library (glibc)", + <https://www.gnu.org/software/libc/>. + + [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/>. + + [RFC20] 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>. + + + +Olson, et al. Standards Track [Page 19] + +RFC 8536 TZif February 2019 + + + [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>. + + [ZIC] Kerrisk, M., "ZIC(8)", man-pages release 4.16, February + 2010, <http://man7.org/linux/man-pages/man8/zic.8.html>. + +9.2. Informative References + + [EGGERT-TZ] "History for tz", October 2018, + <https://github.com/eggert/tz/commits/master/tzfile.5>. + + [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>. + + [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>. + + + + + + + +Olson, et al. Standards Track [Page 20] + +RFC 8536 TZif February 2019 + + +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 + [EGGERT-TZ]. 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 + 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 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 + documenting 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 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). + + + + +Olson, et al. Standards Track [Page 21] + +RFC 8536 TZif February 2019 + + + 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. + + 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. + + + + + + +Olson, et al. Standards Track [Page 22] + +RFC 8536 TZif February 2019 + + + 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. + + 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, 15 minutes, or 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. + + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 23] + +RFC 8536 TZif February 2019 + + +B.1. Version 1 File Representing UTC (with Leap Seconds) + + +-------+---------------+------------------+------------------------+ + | File | Data Octets | Record Name / | Field Value | + | Offset| (hexadecimal) | Field Name | | + +-------+---------------+------------------+------------------------+ + | 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 | + | | | | | + | | | 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 | + | | | | | + + + + + +Olson, et al. Standards Track [Page 24] + +RFC 8536 TZif February 2019 + + + | | | 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 | + | | | | (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) | + + + +Olson, et al. Standards Track [Page 25] + +RFC 8536 TZif February 2019 + + + | 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 | + | | | | | + | | | 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 | + | | | | | + + + + +Olson, et al. Standards Track [Page 26] + +RFC 8536 TZif February 2019 + + + | | | 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 latest leap-second occurrence prior to the time of + interest (leapsecond[21]) and note the correction value + (LEAPCORR = 22). + + 2. Add LEAPCORR + 10 to the time of interest to yield TAI of + 2000-01-01T00:00:32. + + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 27] + +RFC 8536 TZif February 2019 + + +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) | + | 084 | 00 | desigidx | 0 | + | | | | | + + + + +Olson, et al. Standards Track [Page 28] + +RFC 8536 TZif February 2019 + + + | | | 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" | + | 151 | 32 | version | '2' (2) | + + + + +Olson, et al. Standards Track [Page 29] + +RFC 8536 TZif February 2019 + + + | 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) | + | 271 | 08 | desigidx | 8 | + + + +Olson, et al. Standards Track [Page 30] + +RFC 8536 TZif February 2019 + + + | | | | | + | | | 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' | + +--------+--------------+------------------+------------------------+ + + + + + + + + + + +Olson, et al. Standards Track [Page 31] + +RFC 8536 TZif February 2019 + + + 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: + + 1. Find 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. Look up 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 latest time transition prior to the time of interest + (there is no such transition). + + 2. Look up 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). + + + + + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 32] + +RFC 8536 TZif February 2019 + + +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 | + | 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) | + + + +Olson, et al. Standards Track [Page 33] + +RFC 8536 TZif February 2019 + + + | | | | | + | 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' | + +--------+--------------+------------------+------------------------+ + +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. + +Authors' Addresses + + Arthur David Olson + + Email: arthurdavidolson@gmail.com + + + Paul Eggert + University of California, Los Angeles + + Email: eggert@cs.ucla.edu + + + Kenneth Murchison + FastMail US LLC + + Email: murch@fastmailteam.com + + + + + + + + + + + + + +Olson, et al. Standards Track [Page 34] + |