Movatterモバイル変換

[0]ホーム
URL:

RFC 9636TZifOctober 2024
Olson, et al.Standards Track[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9636
Obsoletes:
8536
Category:
Standards Track
Published:
ISSN:
2070-1721
Authors:
A. Olson
P. Eggert
UCLA
K. Murchison
Fastmail

RFC 9636

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.

This document replaces and obsoletes RFC 8536.

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 athttps://www.rfc-editor.org/info/rfc9636.

Copyright Notice

Copyright (c) 2024 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.

▲

Table of Contents

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 isiCalendar [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[RFC8536], providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of[RFC8536]. Additionally, a new version of the format is defined. The changes from[RFC8536] are summarized inAppendix C.

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"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.
Leap Second:
A one-second adjustment to keep UTC close to mean solar time at the prime meridian (see[ITU-R-TF.460]). Each inserted or deleted leap second occurs at the end of a UTC month, that is, a month using the Gregorian calendar and the UTC timescale.
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:
TheTime 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.
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-octetversion 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-lengthversion 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-lengthfooter (Section 3.3). These 64-bit values can represent times approximately 292 billion years into the past or future.

NOTE: All multi-octet integer valuesMUST be stored in network octet order format (high-order octet first, otherwise known as big-endian), with all bits significant. Signed integer valuesMUST 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    |                  +-------------+
Figure 1: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) |+---------------+---------------+---------------+
Figure 2:TZif Header

The fields of the header are defined as follows:

magic:
The four-octetASCII [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 valueMUST be one of the following:

  • NUL (0x00) Version 1 - The file contains only the version 1 header and data block. Version 1 filesMUST NOT contain a version 2+ header, data block, or footer.

  • '2' (0x32) Version 2 - The fileMUST contain the version 1 header and data block, a version 2+ header and data block, and a footer. The TZ string in thefooter (Section 3.3), if non-empty,MUST strictly adhere to the requirements for the TZ environment variable as defined in Section 8.3 of the "Base Definitions" volume of[POSIX] andMUST encode the POSIX portable character set as ASCII. The leap-second recordsMUST NOT betruncated at the start (Section 6.1) andMUST NOT contain an expiration time.

  • '3' (0x33) Version 3 - The fileMUST conform to all version 2 requirements, except that any TZ string in thefooter (Section 3.3)MAY use the TZ string extensiondescribed below (Section 3.3.2).

  • '4' (0x34) Version 4 - The fileMUST conform to all version 3 requirements, except that the leap-second recordsMAY be truncated at the start andMAY 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 non-empty 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)                    |+---------------------------------------------------------+
Figure 3: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 valueSHOULD be at least -259. (-259 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 indexMUST 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 valueMUST NOT be -231 andSHOULD be in the range [-89999, 93599] (i.e., its valueSHOULD be more than -25 hours and less than 26 hours). Avoiding -231 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 valueMUST 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 indexMUST 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 stringMAY be empty.) A NUL octetMUST 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 designationsMAY overlap if one is a suffix of the other. The character encoding of time zone designation strings is not specified; however, seeSection 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 non-negative, and each leap secondMUST 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. If "leapcnt" is nonzero, 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 filestruncated at the start (Section 6.1)).

The first leap second is a positive leap second if and only if its correction is positive. Each correction after the firstMUST 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 recordsMAY 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 cannot 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 when the next leap second will occur.

If leap seconds become permanently discontinued, as requested by theGeneral Conference on Weights and Measures [CGPM-2022-R4], leap-second tables published after the discontinuation timeSHOULD 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 valueMUST be 0 or 1. A value of one (1) indicates standard time. The valueMUST 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 valueMUST be 0 or 1. A value of one (1) indicates UT, and the corresponding standard/wall indicatorMUST 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 thefooter (Section 3.3) if present and non-empty; 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 non-empty; 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 valueMUST 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 indexSHOULD appear at least once in the transition type array. Likewise, every octet in the time zone designations arraySHOULD 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 |+---+--------------------+---+
Figure 4: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 theextension 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 non-empty and one or more transitions appear in the version 2+ data, the stringMUST 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 stringMUST NOT contain NUL octets or be NUL‑terminated, and itSHOULD 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.

3.3.1.All-Year Daylight Saving Time

DST is considered to be in effect all year if its UT offset is less than (i.e., west of) that of standard time, and it starts January 1 at 00:00 and ends December 31 at 24:00 minus the difference between standard and daylight saving time, leaving no room for standard time in the calendar.[POSIX] implies but does not explicitly state this, so it is spelled out here for clarity.

Example: XXX3EDT4,0/0,J365/23
This represents a time zone that is perpetually 4 hours west of UT and is abbreviated "EDT". The "XXX" is ignored.

3.3.2.TZ String Extension

The TZ string in a version 3 or higher TZif fileMAY use the following extension to POSIX TZ strings. This extension is described using the terminology of Section 8.3 of the "Base Definitions" volume of[POSIX].

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

A TZif file that uses the above extensionMUST be designated as version 3 (or higher), even if a future version of POSIX adopts this extension.

4.Interoperability Considerations

The following practices help ensure the interoperability of TZif applications.

5.Internationalization Considerations

TZif time zone designations contain only ASCII alphanumerics, "-", and "+". Commonly used designations include numeric strings like "-10" and "+0530" for UT offsets and English language abbreviations like "CEST" for Central European Summer Time and "GMT" for Greenwich Mean Time. It is the TZif reader's responsibility to substitute different abbreviations when needed for internationalization, such as substituting "HNC" (l'heure normale du Centre) for "CST" (Central Standard Time) in French-speaking regions. This substitution can be problematic, as abbreviations can be ambiguous; for example, "CST" commonly stands for China Standard Time and Cuba Standard Time as well as Central Standard Time. One approach for addressing this issue can be found in the time zone charts of theUnicode Common Locale Data Repository (CLDR) Project [CLDR].

Although the original TZif design allowed for any nonzero octets in time zone designations, and it was common practice until the mid-1990s for designations to contain ASCII spaces, designations are now limited to ASCII alphanumerics, "-", and "+" to avoid confusion and to encourage portability to a wide variety of locales.

6.Use with the Time Zone Data Distribution Service

TheTime 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 serviceMAY supply time zone data to clients in the Time Zone Information Format. Such a serviceMUST indicate that it supports this format by including the media type"application/tzif" (Section 9.1) in its "capabilities" response (Section 5.1 of [RFC7808]). A TZDIST serviceMAY also include the media type"application/tzif-leap" (Section 9.2) in its "capabilities" response if it is able to generate TZif files containing leap-second records. A TZDIST serviceMUST NOT advertise the "application/tzif-leap" media type without also advertising "application/tzif".

TZDIST clientsMUST 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.

6.1.Truncating TZif Files

As described inSection 3.9 of [RFC7808], a TZDIST serviceMAY 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 serviceMUST 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 0MUST be a placeholder indicating that local time is unspecified, so that the reader is unambiguously informed of truncation at the start.

When truncating the start of a TZif file containing leap-second records, the serviceMUST 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 non-empty, its first recordMUST have a positive correction if and only if it represents a positive leap second.

When truncating the end of a TZif file, the serviceMUST supply in the version 2+ data a last transition time that is the end point of the truncation range andMUST 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 transitionMUST be a placeholder indicating that local time is unspecified.

All represented information that falls inside the truncation rangeMUST be the same as that represented by a corresponding untruncated TZif file.

TZDIST clientsSHOULD NOT use a truncated TZif file (as described above) to interpret timestamps outside the truncation time range.

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

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.1Host: tz.example.com>> Response <<HTTP/1.1 200 OKDate: Fri, 01 Jun 2018 14:52:23 GMTContent-Type: application/jsonContent-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.1Host: tz.example.comAccept: application/tzif>> Response <<HTTP/1.1 200 OKDate: Fri, 01 Jun 2018 14:52:24 GMTContent-Type: application/tzifContent-Length: xxxxETag: "123456789-000-111"TZif2...[binary data without leap-second records]...EST5EDT,M3.2.0,M11.1.0

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

As discussed inSection 8 of [RFC7808], transmission of time zone data over an insecure communication channel could result in tampered data, harming calendaring and scheduling operations. As such, TZif data transmitted over a public communications channelMUST be protected with a security layer such as that provided byTransport Layer Security (TLS) [RFC8446].

8.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 inSection 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 channelMUST be protected with a confidentiality layer such as that provided byTransport Layer Security (TLS) [RFC8446].

9.IANA Considerations

IANA has updated the"Media Types" registry as follows.

This document defines two media types[RFC6838] for the exchange of data utilizing the Time Zone Information Format.

9.1.application/tzif

Type name:
application
Subtype name:
tzif
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary
Security considerations:
SeeSection 7 of RFC 9636.
Interoperability considerations:
SeeSection 4 of RFC 9636.
Published specification:
RFC 9636.
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 relative to UNIX time, such as theTime Zone Information Compiler (zic) [ZIC] and theGNU C Library [GNU-C]. TheTime 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 9636.
Change controller:
IETF

9.2.application/tzif-leap

Type name:
application
Subtype name:
tzif-leap
Required parameters:
none
Optional parameters:
none
Encoding considerations:
binary
Security considerations:
SeeSection 7 of RFC 9636.
Interoperability considerations:
SeeSection 4 of RFC 9636.
Published specification:
RFC 9636.
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 relative to UNIX leap time, such as theTime Zone Information Compiler (zic) [ZIC] and theGNU C Library [GNU-C]. TheTime 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 9636.
Change controller:
IETF

10.References

10.1.Normative References

[GNU-C]
Free Software Foundation,"The GNU C Library",<https://www.gnu.org/software/libc/>.
[ITU-R-TF.460]
International Telecommunication Union,"Standard-frequency and time-signal emissions",ITU-R Recommendation TF.460,,<https://www.itu.int/rec/R-REC-TF.460/en>.
[POSIX]
IEEE,"IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7",POSIX.1-2017,IEEE Std 1003.1-2017,DOI 10.1109/IEEESTD.2018.8277153,,<https://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC20]
Cerf, V.,"ASCII format for network interchange",STD 80,RFC 20,DOI 10.17487/RFC0020,,<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,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC6838]
Freed, N.,Klensin, J., andT. Hansen,"Media Type Specifications and Registration Procedures",BCP 13,RFC 6838,DOI 10.17487/RFC6838,,<https://www.rfc-editor.org/info/rfc6838>.
[RFC7808]
Douglass, M. andC. Daboo,"Time Zone Data Distribution Service",RFC 7808,DOI 10.17487/RFC7808,,<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,,<https://www.rfc-editor.org/info/rfc8174>.
[RFC9110]
Fielding, R., Ed.,Nottingham, M., Ed., andJ. Reschke, Ed.,"HTTP Semantics",STD 97,RFC 9110,DOI 10.17487/RFC9110,,<https://www.rfc-editor.org/info/rfc9110>.
[ZIC]
Kerrisk, M.,"zic(8) - Linux manual page",<http://man7.org/linux/man-pages/man8/zic.8.html>.

10.2.Informative References

[CGPM-2022-R4]
General Conference on Weights and Measures,"Resolution 4 of the 27th CGPM (2022)",DOI 10.59161/CGPM2022RES4E,,<https://www.bipm.org/en/cgpm-2022/resolution-4>.
[CLDR]
Unicode, Inc.,"Unicode CLDR Project",<https://cldr.unicode.org/>.
[EGGERT-TZ]
"History for tz",commit b5318b5,,<https://github.com/eggert/tz/commits/main/tzfile.5>.
[Err6426]
RFC Errata,"Erratum ID 6426",RFC 8536,<https://www.rfc-editor.org/errata/eid6426>.
[Err6435]
RFC Errata,"Erratum ID 6435",RFC 8536,<https://www.rfc-editor.org/errata/eid6435>.
[Err6757]
RFC Errata,"Erratum ID 6757",RFC 8536,<https://www.rfc-editor.org/errata/eid6757>.
[Err7681]
RFC Errata,"Erratum ID 7681",RFC 8536,<https://www.rfc-editor.org/errata/eid7681>.
[RFC5545]
Desruisseaux, B., Ed.,"Internet Calendaring and Scheduling Core Object Specification (iCalendar)",RFC 5545,DOI 10.17487/RFC5545,,<https://www.rfc-editor.org/info/rfc5545>.
[RFC6557]
Lear, E. andP. Eggert,"Procedures for Maintaining the Time Zone Database",BCP 175,RFC 6557,DOI 10.17487/RFC6557,,<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,,<https://www.rfc-editor.org/info/rfc8446>.
[RFC8536]
Olson, A.,Eggert, P., andK. Murchison,"The Time Zone Information Format (TZif)",RFC 8536,DOI 10.17487/RFC8536,,<https://www.rfc-editor.org/info/rfc8536>.
[tz-link]
Eggert, P. andA. Olson,"Time zone and daylight saving time data",<https://www.iana.org/time-zones/repository/tz-link.html>.

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 topredecessors of this specification [EGGERT-TZ]. The goals of this section are to help:

  1. TZif writers output files that avoid common pitfalls in older or buggy TZif readers,
  2. TZif readers avoid common pitfalls when reading files generated by future TZif writers, and
  3. 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 newer-version data useful even for older-version readers. This section attempts to document these compatibility issues and workarounds as well as 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.

Appendix B.Example TZif Files

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.

B.1.Version 1 File Representing UTC (with Leap Seconds)

Table 1
File OffsetHexadecimal OctetsRecord Name / Field NameField Value
00054 5a 69 66magic"TZif"
00400version0 (1)
00500 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000 00 00 01isutcnt1
02400 00 00 01isstdcnt1
02800 00 00 1bleapcnt27
03200 00 00 00timecnt0
03600 00 00 01typecnt1
04000 00 00 04charcnt4
localtimetype[0]
04400 00 00 00utoff0 (+00:00)
04800isdst0 (no)
04900desigidx0
05055 54 43 00designations[0]"UTC\0"
leapsecond[0]
05404 b2 58 00occurrence78796800 (1972-06-30T23:59:60Z)
05800 00 00 01correction1
leapsecond[1]
06205 a4 ec 01occurrence94694401 (1972-12-31T23:59:60Z)
06600 00 00 02correction2
leapsecond[2]
07007 86 1f 82occurrence126230402 (1973-12-31T23:59:60Z)
07400 00 00 03correction3
leapsecond[3]
07809 67 53 03occurrence157766403 (1974-12-31T23:59:60Z)
08200 00 00 04correction4
leapsecond[4]
0860b 48 86 84occurrence189302404 (1975-12-31T23:59:60Z)
09000 00 00 05correction5
leapsecond[5]
0940d 2b 0b 85occurrence220924805 (1976-12-31T23:59:60Z)
09800 00 00 06correction6
leapsecond[6]
1020f 0c 3f 06occurrence252460806 (1977-12-31T23:59:60Z)
10600 00 00 07correction7
leapsecond[7]
11010 ed 72 87occurrence283996807 (1978-12-31T23:59:60Z)
11400 00 00 08correction8
leapsecond[8]
11812 ce a6 08occurrence315532808 (1979-12-31T23:59:60Z)
12200 00 00 09correction9
leapsecond[9]
12615 9f ca 89occurrence362793609 (1981-06-30T23:59:60Z)
13000 00 00 0acorrection10
leapsecond[10]
13417 80 fe 0aoccurrence394329610 (1982-06-30T23:59:60Z)
13800 00 00 0bcorrection11
leapsecond[11]
14219 62 31 8boccurrence425865611 (1983-06-30T23:59:60Z)
14600 00 00 0ccorrection12
leapsecond[12]
1501d 25 ea 0coccurrence489024012 (1985-06-30T23:59:60Z)
15400 00 00 0dcorrection13
leapsecond[13]
15821 da e5 0doccurrence567993613 (1987-12-31T23:59:60Z)
16200 00 00 0ecorrection14
leapsecond[14]
16625 9e 9d 8eoccurrence631152014 (1989-12-31T23:59:60Z)
17000 00 00 0fcorrection15
leapsecond[15]
17427 7f d1 0foccurrence662688015 (1990-12-31T23:59:60Z)
17800 00 00 10correction16
leapsecond[16]
1822a 50 f5 90occurrence709948816 (1992-06-30T23:59:60Z)
18600 00 00 11correction17
leapsecond[17]
1902c 32 29 11occurrence741484817 (1993-06-30T23:59:60Z)
19400 00 00 12correction18
leapsecond[18]
1982e 13 5c 92occurrence773020818 (1994-06-30T23:59:60Z)
20200 00 00 13correction19
leapsecond[19]
20630 e7 24 13occurrence820454419 (1995-12-31T23:59:60Z)
21000 00 00 14correction20
leapsecond[20]
21433 b8 48 94occurrence867715220 (1997-06-30T23:59:60Z)
21800 00 00 15correction21
leapsecond[21]
22236 8c 10 15occurrence915148821 (1998-12-31T23:59:60Z)
22600 00 00 16correction22
leapsecond[22]
23043 b7 1b 96occurrence1136073622 (2005-12-31T23:59:60Z)
23400 00 00 17correction23
leapsecond[23]
23849 5c 07 97occurrence1230768023 (2008-12-31T23:59:60Z)
24200 00 00 18correction24
leapsecond[24]
2464f ef 93 18occurrence1341100824 (2012-06-30T23:59:60Z)
25000 00 00 19correction25
leapsecond[25]
25455 93 2d 99occurrence1435708825 (2015-06-30T23:59:60Z)
25800 00 00 1acorrection26
leapsecond[26]
26258 68 46 9aoccurrence1483228826 (2016-12-31T23:59:60Z)
26600 00 00 1bcorrection27
27000standard/wall[0]0 (wall)
27100UT/local[0]0 (local)

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.

B.2.Version 2 File Representing Pacific/Honolulu

Table 2
File OffsetHexadecimal OctetsRecord Name / Field NameField Value
00054 5a 69 66magic"TZif"
00432version'2' (2)
00500 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000 00 00 06isutcnt6
02400 00 00 06isstdcnt6
02800 00 00 00leapcnt0
03200 00 00 07timecnt7
03600 00 00 06typecnt6
04000 00 00 14charcnt20
04480 00 00 00trans time[0]-2147483648 (1901-12-13T20:45:52Z)
048bb 05 43 48trans time[1]-1157283000 (1933-04-30T12:30:00Z)
052bb 21 71 58trans time[2]-1155436200 (1933-05-21T21:30:00Z)
056cb 89 3d c8trans time[3]-880198200 (1942-02-09T12:30:00Z)
060d2 23 f4 70trans time[4]-769395600 (1945-08-14T23:00:00Z)
064d2 61 49 38trans time[5]-765376200 (1945-09-30T11:30:00Z)
068d5 8d 73 48trans time[6]-712150200 (1947-06-08T12:30:00Z)
07201trans type[0]1
07302trans type[1]2
07401trans type[2]1
07503trans type[3]3
07604trans type[4]4
07701trans type[5]1
07805trans type[6]5
localtimetype[0]
079ff ff 6c 02utoff-37886 (-10:31:26)
08300isdst0 (no)
08400desigidx0
localtimetype[1]
085ff ff 6c 58utoff-37800 (-10:30)
08900isdst0 (no)
09004desigidx4
localtimetype[2]
091ff ff 7a 68utoff-34200 (-09:30)
09501isdst1 (yes)
09608desigidx8
localtimetype[3]
097ff ff 7a 68utoff-34200 (-09:30)
10101isdst1 (yes)
1020cdesigidx12
localtimetype[4]
103ff ff 7a 68utoff-34200 (-09:30)
10701isdst1 (yes)
10810desigidx16
localtimetype[5]
109ff ff 73 60utoff-36000 (-10:00)
11300isdst0 (no)
11404desigidx4
1154c 4d 54 00designations[0]"LMT\0"
11948 53 54 00designations[4]"HST\0"
12348 44 54 00designations[8]"HDT\0"
12748 57 54 00designations[12]"HWT\0"
13148 50 54 00designations[16]"HPT\0"
13500standard/wall[0]0 (wall)
13600standard/wall[1]0 (wall)
13700standard/wall[2]0 (wall)
13800standard/wall[3]0 (wall)
13901standard/wall[4]1 (standard)
14000standard/wall[5]0 (wall)
14100UT/local[0]0 (local)
14200UT/local[1]0 (local)
14300UT/local[2]0 (local)
14400UT/local[3]0 (local)
14501UT/local[4]1 (UT)
14600UT/local[5]0 (local)
14754 5a 69 66magic"TZif"
15132version'2' (2)
15200 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16700 00 00 06isutcnt6
17100 00 00 06isstdcnt6
17500 00 00 00leapcnt0
17900 00 00 07timecnt7
18300 00 00 06typecnt6
18700 00 00 14charcnt20
191ff ff ff ff 74 e0 70 betrans time[0]-2334101314 (1896-01-13T22:31:26Z)
199ff ff ff ff bb 05 43 48trans time[1]-1157283000 (1933-04-30T12:30:00Z)
207ff ff ff ff bb 21 71 58trans time[2]-1155436200 (1933-05-21T21:30:00Z)
215ff ff ff ff cb 89 3d c8trans time[3]-880198200 (1942-02-09T12:30:00Z)
223ff ff ff ff d2 23 f4 70trans time[4]-769395600 (1945-08-14T23:00:00Z)
231ff ff ff ff d2 61 49 38trans time[5]-765376200 (1945-09-30T11:30:00Z)
239ff ff ff ff d5 8d 73 48trans time[6]-712150200 (1947-06-08T12:30:00Z)
24701trans type[0]1
24802trans type[1]2
24901trans type[2]1
25003trans type[3]3
25104trans type[4]4
25201trans type[5]1
25305trans type[6]5
localtimetype[0]
254ff ff 6c 02utoff-37886 (-10:31:26)
25800isdst0 (no)
25900desigidx0
localtimetype[1]
260ff ff 6c 58utoff-37800 (-10:30)
26400isdst0 (no)
26504desigidx4
localtimetype[2]
266ff ff 7a 68utoff-34200 (-09:30)
27001isdst1 (yes)
27108desigidx8
localtimetype[3]
272ff ff 7a 68utoff-34200 (-09:30)
27601isdst1 (yes)
2770cdesigidx12
localtimetype[4]
278ff ff 7a 68utoff-34200 (-09:30)
28201isdst1 (yes)
28310desigidx16
localtimetype[5]
284ff ff 73 60utoff-36000 (-10:00)
28800isdst0 (no)
28904desigidx4
2904c 4d 54 00designations[0]"LMT\0"
29448 53 54 00designations[4]"HST\0"
29848 44 54 00designations[8]"HDT\0"
30248 57 54 00designations[12]"HWT\0"
30648 50 54 00designations[16]"HPT\0"
31000standard/wall[0]0 (wall)
31100standard/wall[1]0 (wall)
31200standard/wall[2]0 (wall)
31300standard/wall[3]0 (wall)
31401standard/wall[4]1 (standard)
31500standard/wall[5]0 (wall)
31600UT/local[0]0 (local)
31700UT/local[1]0 (local)
31800UT/local[2]0 (local)
31900UT/local[3]0 (local)
32001UT/local[4]1 (UT)
32100UT/local[5]0 (local)
3220aNL'\n'
32348 53 54 31 30TZ string"HST10"
3280aNL'\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:

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

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 inSection 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.
Table 3
File OffsetHexadecimal OctetsRecord Name / Field NameField Value
00054 5a 69 66magic"TZif"
00432version'2' (2)
00500 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000 00 00 00isutcnt0
02400 00 00 00isstdcnt0
02800 00 00 00leapcnt0
03200 00 00 00timecnt0
03600 00 00 01typecnt1
04000 00 00 01charcnt1
localtimetype[0]
04400 00 00 00utoff0 (+00:00)
04800isdst0 (no)
04900desigidx0
05000designations[0]"\0"
05154 5a 69 66magic"TZif"
05532version'2' (2)
05600 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07100 00 00 00isutcnt0
07500 00 00 00isstdcnt0
07900 00 00 00leapcnt0
08300 00 00 08timecnt8
08700 00 00 07typecnt7
09100 00 00 18charcnt24
095ff ff ff ff 74 e0 70 betrans time[0]-2334101314 (1896-01-13T22:31:26Z)
103ff ff ff ff bb 05 43 48trans time[1]-1157283000 (1933-04-30T12:30:00Z)
111ff ff ff ff bb 21 71 58trans time[2]-1155436200 (1933-05-21T21:30:00Z)
119ff ff ff ff cb 89 3d c8trans time[3]-880198200 (1942-02-09T12:30:00Z)
127ff ff ff ff d2 23 f4 70trans time[4]-769395600 (1945-08-14T23:00:00Z)
135ff ff ff ff d2 61 49 38trans time[5]-765376200 (1945-09-30T11:30:00Z)
143ff ff ff ff d5 8d 73 48trans time[6]-712150200 (1947-06-08T12:30:00Z)
15100 00 00 00 40 cf 8d 80trans time[7]1087344000 (2004-06-16T00:00:00Z)
15902trans type[0]2
16003trans type[1]3
16102trans type[2]2
16204trans type[3]4
16305trans type[4]5
16402trans type[5]2
16506trans type[6]6
16601trans type[7]1
localtimetype[0]
167ff ff 6c 02utoff-37886 (-10:31:26)
17100isdst0 (no)
17204desigidx4
localtimetype[1]
17300 00 00 00utoff0 (+00:00)
17700isdst0 (no)
17800desigidx0
localtimetype[2]
179ff ff 6c 58utoff-37800 (-10:30)
18300isdst0 (no)
18408desigidx8
localtimetype[3]
185ff ff 7a 68utoff-34200 (-09:30)
18901isdst1 (yes)
1900cdesigidx12
localtimetype[4]
191ff ff 7a 68utoff-34200 (-09:30)
19501isdst1 (yes)
19610desigidx16
localtimetype[5]
197ff ff 7a 68utoff-34200 (-09:30)
20101isdst1 (yes)
20214desigidx20
localtimetype[6]
203ff ff 73 60utoff-36000 (-10:00)
20700isdst0 (no)
20808desigidx8
2092d 30 30 00designations[0]"-00\0"
2134c 4d 54 00designations[4]"LMT\0"
21748 53 54 00designations[8]"HST\0"
22148 44 54 00designations[12]"HDT\0"
22548 57 54 00designations[16]"HWT\0"
22948 50 54 00designations[20]"HPT\0"
2330aNL'\n'
234TZ string""
2340aNL'\n'

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 cannot 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 inSection 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.
Table 4
File OffsetHexadecimal OctetsRecord Name / Field NameField Value
00054 5a 69 66magic"TZif"
00433version'3' (3)
00500 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000 00 00 00isutcnt0
02400 00 00 00isstdcnt0
02800 00 00 00leapcnt0
03200 00 00 00timecnt0
03600 00 00 01typecnt1
04000 00 00 01charcnt1
localtimetype[0]
04400 00 00 00utoff0 (+00:00)
04800isdst0 (no)
04900desigidx0
05000designations[0]"\0"
05154 5a 69 66magic"TZif"
05533version'3' (3)
05600 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07100 00 00 00isutcnt0
07500 00 00 00isstdcnt0
07900 00 00 00leapcnt0
08300 00 00 01timecnt1
08700 00 00 02typecnt2
09100 00 00 08charcnt8
09500 00 00 00 7f e8 17 80trans time[0]2145916800 (2038-01-01T00:00:00Z)
10301trans type[0]1
localtimetype[0]
10400 00 00 00utoff0 (+00:00)
10800isdst0 (no)
10900desigidx0
localtimetype[1]
11000 00 1c 20utoff7200 (+02:00)
11400isdst0 (no)
11504desigidx4
1162d 30 30 00designations[0]"-00\0"
12049 53 54 00designations[4]"IST\0"
1240aNL'\n'
12549 53 54 2d 32 49 44 54 2c 4d 33 2e 34 2e 34 2f 32 36 2c 4d 31 30 2e 35 2e 30TZ string"IST-2IDT,M3.4.4/26,M10.5.0"
1510aNL'\n'

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 inSection 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.
Table 5
File OffsetHexadecimal OctetsRecord Name / Field NameField Value
00054 5a 69 66magic"TZif"
00434version'4' (4)
00500 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000 00 00 00isutcnt0
02400 00 00 00isstdcnt0
02800 00 00 00leapcnt0
03200 00 00 00timecnt0
03600 00 00 01typecnt1
04000 00 00 01charcnt1
localtimetype[0]
04400 00 00 00utoff0 (+00:00)
04800isdst0 (no)
04900desigidx0
05000designations[0]"\0"
05154 5a 69 66magic"TZif"
05534version'4' (4)
05600 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07100 00 00 00isutcnt0
07500 00 00 00isstdcnt0
07900 00 00 02leapcnt2
08300 00 00 01timecnt1
08700 00 00 02typecnt2
09100 00 00 08charcnt8
09500 00 00 00 61 cf 99 9btrans time[0]1640995227 (2022-01-01T00:00:27Z)
10301trans type[0]1
localtimetype[0]
10400 00 00 00utoff0 (+00:00)
10800isdst0 (no)
10900desigidx0
localtimetype[1]
11000 00 00 00utoff0 (+00:00)
11400isdst0 (no)
11504desigidx4
1162d 30 30 00designations[0]"-00\0"
12047 4d 54 00designations[4]"GMT\0"
leapsecond[0]
12400 00 00 00 58 68 46 9aoccurrence1483228826 (2016-12-31T23:59:60Z)
13200 00 00 1bcorrection27
leapsecond[1]
13600 00 00 00 66 7d fd 1boccurrence1719532827 (2024-06-28T00:00:01Z)
14400 00 00 1bcorrection27
1480aNL'\n'
14947 4d 54 30 42 53 54 2c 4d 33 2e 35 2e 30 2f 31 2c 4d 31 30 2e 35 2e 30TZ string"GMT0BST,M3.5.0/1,M10.5.0"
1730aNL'\n'

Appendix C.Changes from RFC 8536

Acknowledgments

The authors thank the following individuals for contributing their ideas and support for writing this specification:Michael Douglass,Ned Freed,Guy Harris,Eliot Lear,Alexey Melnikov, andTim Parenti.

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
[8]ページ先頭
©2009-2025 Movatter.jp