The Time Zone Information Format (TZif)

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) |
+---------------+---------------+---------------+

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

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. The leap-second records MUST NOT be truncated at the start (Section 5.1), and MUST NOT contain an expiration time.¶

'3' (0x33)

Version 3 - The file MUST conform to all version 2 requirements, except that any TZ string in the footer (Section 3.3) MAY use the TZ string extension described below (Section 3.3.2).¶

'4' (0x34)

Version 4 - The file MUST conform to all version 3 requirements, except that the leap-second records MAY be truncated at the start, and MAY contain an expiration time.¶

isutcnt:

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

isstdcnt:

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

leapcnt:

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

timecnt:

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

typecnt:

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

charcnt:

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

Although the version 1 and 2+ headers have the same format, 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 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:¶

transition times:

A series of four- or eight-octet UNIX leap time values sorted in strictly ascending order. Each value is used as a transition time at which the rules for computing local time may change. The number of time values is specified by the "timecnt" field in the header. Each time value SHOULD be at least -2**59. (-2**59 is the greatest negated power of 2 that predates the Big Bang, and avoiding earlier timestamps works around known TZif reader bugs relating to 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". If the designation string is "-00", the time type is a placeholder indicating that local time is unspecified.¶

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. 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, 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):¶

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 or at which the leap-second table expires. The first value, if present, MUST be nonnegative, and each leap second MUST occur at the end of a UTC month.¶

corr(ection):

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

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

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 |
+---+--------------------+---+

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 the extension described below (Section 3.3.2) in version 3 and higher 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 higher files, as the obsolescent version 1 format was designed before the need for a footer was apparent.¶

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

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 XXXX.¶

Interoperability considerations:

See Section 4 of RFC XXXX.¶

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 XXXX.¶

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 XXXX.¶

Interoperability considerations:

See Section 4 of RFC XXXX.¶

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 XXXX.¶

Change controller:

IETF¶

B.3. Truncated Version 2 File Representing Pacific/Johnston

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:¶

• The version 1 header contains only the required minimum data, which will be ignored by readers.¶
• The version 2 header leverages the fact that by specifying 'isutcnt' and 'isstdcnt' as zero, all transition times associated with local time types are assumed to be specified as local wall-clock time (see the definitions of UT/local indicators and standard/wall indicators in Section 3.2).¶
• The time type of the last transition has designation "-00", indicating that local time is unspecified.¶
• The TZ string is empty, indicating that there are no known future transitions.¶

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

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

In this example:¶

• The start time value can not be represented using 32 bits, so the version 1 header contains only the required minimum data, which will be ignored by readers.¶
• The version 3 header leverages the fact that by specifying 'isutcnt' and 'isstdcnt' as zero, all transition times associated with local time types are assumed to be specified as local wall-clock time (see the definitions of UT/local indicators and standard/wall indicators in Section 3.2).¶
• Time type 0 has designation "-00", indicating that local time is unspecified prior to the truncation time.¶
• The TZ string value has been line-wrapped for presentation purposes only.¶

B.5. Truncated Version 4 File Representing Europe/London

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

In this example:¶

• The version 1 header contains only the required minimum data, which will be ignored by readers.¶
• The version 4 header leverages the fact that by specifying 'isutcnt' and 'isstdcnt' as zero, all transition times associated with local time types are assumed to be specified as local wall-clock time (see the definitions of UT/local indicators and standard/wall indicators in Section 3.2).¶
• Time type 0 has designation "-00", indicating that local time is unspecified prior to the truncation time.¶
• The first leap-second occurrence is the most recent one prior to the truncation time.¶
• The last leap-second correction matches the second-to-last leap-second correction, indicating the expiration time of the leap-second table.¶
• The TZ string value has been line-wrapped for presentation purposes only.¶