summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8536.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc8536.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc8536.txt')
-rw-r--r--doc/rfc/rfc8536.txt1907
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]
+