Internet-Draft | TZif | November 2023 |
Olson, et al. | Expires 23 May 2024 | [Page] |
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.¶
This document replaces and obsoletes RFC 8536.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 May 2024.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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].¶
This document obsoletes RFC 8536, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 8536. Additionally, a new version of the format is defined. The changes from RFC 8536 are summarized in Appendix C.¶
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 "Time zone and daylight saving time data" [tz-link] for more detailed information about civil timekeeping data and practice):¶
A change to civil timekeeping practice. It occurs when one or more of the following happen simultaneously:¶
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 higher extend the format by appending a second 44-octet version 2+ header, a variable-length version 2+ data block containing eight-octet (64-bit) transition times and leap-second occurrences, and a variable-length footer (Section 3.3). These 64-bit values can represent times approximately 292 billion years into the past or future.¶
NOTE: All multi-octet integer values MUST be stored in network octet order format (high-order octet first, otherwise known as big-endian), with all bits significant. Signed integer values MUST be represented using two's complement.¶
A TZif file is structured as follows:¶
Version 1 Versions 2+ +-------------+ +-------------+ | Version 1 | | Version 1 | | Header | | Header | +-------------+ +-------------+ | Version 1 | | Version 1 | | Data Block | | Data Block | +-------------+ +-------------+ | Version 2+ | | Header | +-------------+ | Version 2+ | | Data Block | +-------------+ | Footer | +-------------+
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) | +---------------+---------------+---------------+
The fields of the header are defined as follows:¶
An octet identifying the version of the file's format. The value MUST be one of the following:¶
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.¶
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 higher 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) | +---------------------------------------------------------+
The elements of the data block are defined as follows:¶
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| +---------------+---+---+¶
A series of eight- or twelve-octet records specifying the corrections that need to be applied to UTC in order to determine TAI, also known as the leap-second table. 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):¶
+---------------+---------------+ | occur (4) | corr (4) | +---------------+---------------+¶
+---------------+---------------+---------------+ | occur (8) | corr (4) | +---------------+---------------+---------------+¶
A four-octet signed integer specifying the value of LEAPCORR on or after the occurrence. If "leapcnt" is zero, LEAPCORR is zero for all timestamps; otherwise, for timestamps before the first occurrence time, LEAPCORR is zero if the first correction is one (1) or minus one (-1), and is unspecified otherwise (which can happen only in files truncated at the start (Section 5.1)).¶
The first leap second is a positive leap second if and only if its correction is positive. Each correction after the first MUST differ from the previous correction by either one (1) for a positive leap second or minus one (-1) for a negative leap second, except that in version 4 files with two or more leap-second records, the correction value of the last two records MAY be the same, with the occurrence of last record indicating the expiration time of the leap-second table.¶
The leap-second table expiration time is the time at which the table no longer records the presence or absence of future leap-second corrections, and post-expiration timestamps can not be accurately calculated. For example, a leap-second table published in January, which predicts the presence or absence of a leap second at June's end, might expire in mid-December because it is not known whether a leap second will occur at December's end.¶
If leap seconds become permanently discontinued, as requested by the General Conference on Weights and Measures [CGPM-2022-R4], leap-second tables published after the discontinuation time SHOULD NOT expire, since they will not be updated in the foreseeable future.¶
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 time type with a designation string of "-00" represents an unspecified local time.¶
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. 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-like 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.¶
The following practices help ensure the interoperability of TZif applications.¶
When a TZif file is used in a MIME message entity, it SHOULD be indicated by one of the following media types:¶
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 (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".¶
TZDIST clients MUST use the HTTP "Accept" header field [RFC9110], Section 12.5.1 to indicate their preference to receive data in the "application/tzif" and/or "application/tzif-leap" formats.¶
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. Time type 0 SHOULD be a placeholder indicating that local time is unspecified.¶
When truncating the start of a TZif file containing leap-second records, the service MUST keep all leap-second records governing timestamps within the truncation range, even if the first such record precedes the start point of the truncation range. If the truncated leap-second table is nonempty, its first record MUST have a positive correction if and only if it represents a positive leap second.¶
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. To this end, the time type of the last transition SHOULD be a placeholder indicating that local time is unspecified.¶
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.¶
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.¶
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 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¶
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.¶
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].¶
This document defines two media types [RFC6838] for the exchange of data utilizing the Time Zone Information Format.¶
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:¶
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:¶
Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers.¶
The following sections contain annotated hexadecimal dumps of example TZif files.¶
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.¶
File Offset | Hexadecimal Octets | Record Name / Field Name | Field Value |
---|---|---|---|
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 | isutcnt | 1 |
024 | 00 00 00 01 | isstdcnt | 1 |
028 | 00 00 00 1b | leapcnt | 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 | utoff | 0 (+00:00) |
048 | 00 | isdst | 0 (no) |
049 | 00 | desigidx | 0 |
050 | 55 54 43 00 | designations[0] | "UTC\0" |
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 |
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) |
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 |
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 | standard/wall[0] | 0 (wall) |
271 | 00 | UT/local[0] | 0 (local) |
To determine TAI corresponding to 2000-01-01T00:00:00Z (UNIX time = 946684800), the following procedure would be followed:¶
File Offset | Hexadecimal Octets | Record Name / Field Name | Field Value |
---|---|---|---|
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 | isutcnt | 6 |
024 | 00 00 00 06 | isstdcnt | 6 |
028 | 00 00 00 00 | leapcnt | 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 | utoff | -37886 (-10:31:26) |
083 | 00 | isdst | 0 (no) |
084 | 00 | desigidx | 0 |
localtimetype[1] | |||
085 | ff ff 6c 58 | utoff | -37800 (-10:30) |
089 | 00 | isdst | 0 (no) |
090 | 04 | desigidx | 4 |
localtimetype[2] | |||
091 | ff ff 7a 68 | utoff | -34200 (-09:30) |
095 | 01 | isdst | 1 (yes) |
096 | 08 | desigidx | 8 |
localtimetype[3] | |||
097 | ff ff 7a 68 | utoff | -34200 (-09:30) |
101 | 01 | isdst | 1 (yes) |
102 | 0c | desigidx | 12 |
localtimetype[4] | |||
103 | ff ff 7a 68 | utoff | -34200 (-09:30) |
107 | 01 | isdst | 1 (yes) |
108 | 10 | desigidx | 16 |
localtimetype[5] | |||
109 | ff ff 73 60 | utoff | -36000 (-10:00) |
113 | 00 | isdst | 0 (no) |
114 | 04 | desigidx | 4 |
115 | 4c 4d 54 00 | designations[0] | "LMT\0" |
119 | 48 53 54 00 | designations[4] | "HST\0" |
123 | 48 44 54 00 | designations[8] | "HDT\0" |
127 | 48 57 54 00 | designations[12] | "HWT\0" |
131 | 48 50 54 00 | designations[16] | "HPT\0" |
135 | 00 | standard/wall[0] | 0 (wall) |
136 | 00 | standard/wall[1] | 0 (wall) |
137 | 00 | standard/wall[2] | 0 (wall) |
138 | 00 | standard/wall[3] | 0 (wall) |
139 | 01 | standard/wall[4] | 1 (standard) |
140 | 00 | standard/wall[5] | 0 (wall) |
141 | 00 | UT/local[0] | 0 (local) |
142 | 00 | UT/local[1] | 0 (local) |
143 | 00 | UT/local[2] | 0 (local) |
144 | 00 | UT/local[3] | 0 (local) |
145 | 01 | UT/local[4] | 1 (UT) |
146 | 00 | UT/local[5] | 0 (local) |
147 | 54 5a 69 66 | magic | "TZif" |
151 | 32 | version | '2' (2) |
152 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
167 | 00 00 00 06 | isutcnt | 6 |
171 | 00 00 00 06 | isstdcnt | 6 |
175 | 00 00 00 00 | leapcnt | 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 74 e0 70 be | trans time[0] | -2334101314 (1896-01-13T22:31:26Z) |
199 | ff ff ff ff bb 05 43 48 | trans time[1] | -1157283000 (1933-04-30T12:30:00Z) |
207 | ff ff ff ff bb 21 71 58 | trans time[2] | -1155436200 (1933-05-21T21:30:00Z) |
215 | ff ff ff ff cb 89 3d c8 | trans time[3] | -880198200 (1942-02-09T12:30:00Z) |
223 | ff ff ff ff d2 23 f4 70 | trans time[4] | -769395600 (1945-08-14T23:00:00Z) |
231 | ff ff ff ff d2 61 49 38 | trans time[5] | -765376200 (1945-09-30T11:30:00Z) |
239 | ff ff ff ff d5 8d 73 48 | trans time[6] | -712150200 (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 | utoff | -37886 (-10:31:26) |
258 | 00 | isdst | 0 (no) |
259 | 00 | desigidx | 0 |
localtimetype[1] | |||
260 | ff ff 6c 58 | utoff | -37800 (-10:30) |
264 | 00 | isdst | 0 (no) |
265 | 04 | desigidx | 4 |
localtimetype[2] | |||
266 | ff ff 7a 68 | utoff | -34200 (-09:30) |
270 | 01 | isdst | 1 (yes) |
271 | 08 | desigidx | 8 |
localtimetype[3] | |||
272 | ff ff 7a 68 | utoff | -34200 (-09:30) |
276 | 01 | isdst | 1 (yes) |
277 | 0c | desigidx | 12 |
localtimetype[4] | |||
278 | ff ff 7a 68 | utoff | -34200 (-09:30) |
282 | 01 | isdst | 1 (yes) |
283 | 10 | desigidx | 16 |
localtimetype[5] | |||
284 | ff ff 73 60 | utoff | -36000 (-10:00) |
288 | 00 | isdst | 0 (no) |
289 | 04 | desigidx | 4 |
290 | 4c 4d 54 00 | designations[0] | "LMT\0" |
294 | 48 53 54 00 | designations[4] | "HST\0" |
298 | 48 44 54 00 | designations[8] | "HDT\0" |
302 | 48 57 54 00 | designations[12] | "HWT\0" |
306 | 48 50 54 00 | designations[16] | "HPT\0" |
310 | 00 | standard/wall[0] | 0 (wall) |
311 | 00 | standard/wall[1] | 0 (wall) |
312 | 00 | standard/wall[2] | 0 (wall) |
313 | 00 | standard/wall[3] | 0 (wall) |
314 | 01 | standard/wall[4] | 1 (standard) |
315 | 00 | standard/wall[5] | 0 (wall) |
316 | 00 | UT/local[0] | 0 (local) |
317 | 00 | UT/local[1] | 0 (local) |
318 | 00 | UT/local[2] | 0 (local) |
319 | 00 | UT/local[3] | 0 (local) |
320 | 01 | UT/local[4] | 1 (UT) |
321 | 00 | UT/local[5] | 0 (local) |
322 | 0a | NL | '\n' |
323 | 48 53 54 31 30 | TZ string | "HST10" |
328 | 0a | NL | '\n' |
To determine the local time in this time zone corresponding to 1933-05-04T12:00:00Z (UNIX time = -1156939200), the following procedure would be followed:¶
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:¶
The following TZif file has been truncated to end on 2004-06-161T00:00:00Z (the atoll was abandoned sometime on 2004-06-15).¶
In this example:¶
File Offset | Hexadecimal Octets | Record Name / Field Name | Field Value |
---|---|---|---|
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 00 | isutcnt | 0 |
024 | 00 00 00 00 | isstdcnt | 0 |
028 | 00 00 00 00 | leapcnt | 0 |
032 | 00 00 00 00 | timecnt | 0 |
036 | 00 00 00 01 | typecnt | 1 |
040 | 00 00 00 01 | charcnt | 1 |
localtimetype[0] | |||
044 | 00 00 00 00 | utoff | 0 (+00:00) |
048 | 00 | isdst | 0 (no) |
049 | 00 | desigidx | 0 |
050 | 00 | designations[0] | "\0" |
051 | 54 5a 69 66 | magic | "TZif" |
055 | 32 | version | '2' (2) |
056 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
071 | 00 00 00 00 | isutcnt | 0 |
075 | 00 00 00 00 | isstdcnt | 0 |
079 | 00 00 00 00 | leapcnt | 0 |
083 | 00 00 00 08 | timecnt | 8 |
087 | 00 00 00 07 | typecnt | 7 |
091 | 00 00 00 18 | charcnt | 24 |
095 | ff ff ff ff 74 e0 70 be | trans time[0] | -2334101314 (1896-01-13T22:31:26Z) |
103 | ff ff ff ff bb 05 43 48 | trans time[1] | -1157283000 (1933-04-30T12:30:00Z) |
111 | ff ff ff ff bb 21 71 58 | trans time[2] | -1155436200 (1933-05-21T21:30:00Z) |
119 | ff ff ff ff cb 89 3d c8 | trans time[3] | -880198200 (1942-02-09T12:30:00Z) |
127 | ff ff ff ff d2 23 f4 70 | trans time[4] | -769395600 (1945-08-14T23:00:00Z) |
135 | ff ff ff ff d2 61 49 38 | trans time[5] | -765376200 (1945-09-30T11:30:00Z) |
143 | ff ff ff ff d5 8d 73 48 | trans time[6] | -712150200 (1947-06-08T12:30:00Z) |
151 | 00 00 00 00 40 cf 8d 80 | trans time[7] | 1087344000 (2004-06-16T00:00:00Z) |
159 | 02 | trans type[0] | 2 |
160 | 03 | trans type[1] | 3 |
161 | 02 | trans type[2] | 2 |
162 | 04 | trans type[3] | 4 |
163 | 05 | trans type[4] | 5 |
164 | 02 | trans type[5] | 2 |
165 | 06 | trans type[6] | 6 |
166 | 01 | trans type[7] | 1 |
localtimetype[0] | |||
167 | ff ff 6c 02 | utoff | -37886 (-10:31:26) |
171 | 00 | isdst | 0 (no) |
172 | 04 | desigidx | 4 |
localtimetype[1] | |||
173 | 00 00 00 00 | utoff | 0 (+00:00) |
177 | 00 | isdst | 0 (no) |
178 | 00 | desigidx | 0 |
localtimetype[2] | |||
179 | ff ff 6c 58 | utoff | -37800 (-10:30) |
183 | 00 | isdst | 0 (no) |
184 | 08 | desigidx | 8 |
localtimetype[3] | |||
185 | ff ff 7a 68 | utoff | -34200 (-09:30) |
189 | 01 | isdst | 1 (yes) |
190 | 0c | desigidx | 12 |
localtimetype[4] | |||
191 | ff ff 7a 68 | utoff | -34200 (-09:30) |
195 | 01 | isdst | 1 (yes) |
196 | 10 | desigidx | 16 |
localtimetype[5] | |||
197 | ff ff 7a 68 | utoff | -34200 (-09:30) |
201 | 01 | isdst | 1 (yes) |
202 | 14 | desigidx | 20 |
localtimetype[6] | |||
203 | ff ff 73 60 | utoff | -36000 (-10:00) |
207 | 00 | isdst | 0 (no) |
208 | 08 | desigidx | 8 |
209 | 2d 30 30 00 | designations[0] | "-00\0" |
213 | 4c 4d 54 00 | designations[4] | "LMT\0" |
217 | 48 53 54 00 | designations[8] | "HST\0" |
221 | 48 44 54 00 | designations[12] | "HDT\0" |
225 | 48 57 54 00 | designations[16] | "HWT\0" |
229 | 48 50 54 00 | designations[20] | "HPT\0" |
233 | 0a | NL | '\n' |
234 | TZ string | "" | |
234 | 0a | NL | '\n' |
The following TZif file has been truncated to start on 2038-01-01T00:00:00Z.¶
In this example:¶
File Offset | Hexadecimal Octets | Record Name / Field Name | Field Value |
---|---|---|---|
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 | isutcnt | 0 |
024 | 00 00 00 00 | isstdcnt | 0 |
028 | 00 00 00 00 | leapcnt | 0 |
032 | 00 00 00 00 | timecnt | 0 |
036 | 00 00 00 01 | typecnt | 1 |
040 | 00 00 00 01 | charcnt | 1 |
localtimetype[0] | |||
044 | 00 00 00 00 | utoff | 0 (+00:00) |
048 | 00 | isdst | 0 (no) |
049 | 00 | desigidx | 0 |
050 | 00 | designations[0] | "\0" |
051 | 54 5a 69 66 | magic | "TZif" |
055 | 33 | version | '3' (3) |
056 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
071 | 00 00 00 00 | isutcnt | 0 |
075 | 00 00 00 00 | isstdcnt | 0 |
079 | 00 00 00 00 | leapcnt | 0 |
083 | 00 00 00 01 | timecnt | 1 |
087 | 00 00 00 02 | typecnt | 2 |
091 | 00 00 00 08 | charcnt | 8 |
095 | 00 00 00 00 7f e8 17 80 | trans time[0] | 2145916800 (2038-01-01T00:00:00Z) |
103 | 01 | trans type[0] | 1 |
localtimetype[0] | |||
104 | 00 00 00 00 | utoff | 0 (+00:00) |
108 | 00 | isdst | 0 (no) |
109 | 00 | desigidx | 0 |
localtimetype[1] | |||
110 | 00 00 1c 20 | utoff | 7200 (+02:00) |
114 | 00 | isdst | 0 (no) |
115 | 04 | desigidx | 4 |
116 | 2d 30 30 00 | designations[0] | "-00\0" |
120 | 49 53 54 00 | designations[4] | "IST\0" |
124 | 0a | NL | '\n' |
125 | 49 53 54 2d 32 49 44 54 2c 4d 33 2e 34 2e 34 2f 32 36 2c 4d 31 30 2e 35 2e 30 | TZ string | "IST-2IDT,M3.4.4/26,M10.5.0" |
151 | 0a | NL | '\n' |
The following TZif file has been truncated to start on 2022-01-01T00:00:00Z.¶
In this example:¶
File Offset | Hexadecimal Octets | Record Name / Field Name | Field Value |
---|---|---|---|
000 | 54 5a 69 66 | magic | "TZif" |
004 | 34 | version | '4' (4) |
005 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
020 | 00 00 00 00 | isutcnt | 0 |
024 | 00 00 00 00 | isstdcnt | 0 |
028 | 00 00 00 00 | leapcnt | 0 |
032 | 00 00 00 00 | timecnt | 0 |
036 | 00 00 00 01 | typecnt | 1 |
040 | 00 00 00 01 | charcnt | 1 |
localtimetype[0] | |||
044 | 00 00 00 00 | utoff | 0 (+00:00) |
048 | 00 | isdst | 0 (no) |
049 | 00 | desigidx | 0 |
050 | 00 | designations[0] | "\0" |
051 | 54 5a 69 66 | magic | "TZif" |
055 | 34 | version | '4' (4) |
056 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
071 | 00 00 00 00 | isutcnt | 0 |
075 | 00 00 00 00 | isstdcnt | 0 |
079 | 00 00 00 02 | leapcnt | 2 |
083 | 00 00 00 01 | timecnt | 1 |
087 | 00 00 00 02 | typecnt | 2 |
091 | 00 00 00 08 | charcnt | 8 |
095 | 00 00 00 00 61 cf 99 9b | trans time[0] | 1640995227 (2022-01-01T00:00:27Z) |
103 | 01 | trans type[0] | 1 |
localtimetype[0] | |||
104 | 00 00 00 00 | utoff | 0 (+00:00) |
108 | 00 | isdst | 0 (no) |
109 | 00 | desigidx | 0 |
localtimetype[1] | |||
110 | 00 00 00 00 | utoff | 0 (+00:00) |
114 | 00 | isdst | 0 (no) |
115 | 04 | desigidx | 4 |
116 | 2d 30 30 00 | designations[0] | "-00\0" |
120 | 47 4d 54 00 | designations[4] | "GMT\0" |
leapsecond[0] | |||
124 | 00 00 00 00 58 68 46 9a | occurrence | 1483228826 (2016-12-31T23:59:60Z) |
132 | 00 00 00 1b | correction | 27 |
leapsecond[1] | |||
136 | 00 00 00 00 66 7d fd 1b | occurrence | 1719532827 (2024-06-28T00:00:01Z) |
144 | 00 00 00 1b | correction | 27 |
148 | 0a | NL | '\n' |
149 | 47 4d 54 30 42 53 54 2c 4d 33 2e 35 2e 30 2f 31 2c 4d 31 30 2e 35 2e 30 | TZ string | "GMT0BST,M3.5.0/1,M10.5.0" |
173 | 0a | NL | '\n' |
This section is to be removed by RFC Editor before publication.¶
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, Alexey Melnikov, and Tim Parenti.¶