< draft-murchison-tzdist-tzif-15.txt   draft-murchison-tzdist-tzif-16.txt >
Independent Submission A. Olson Independent Submission A. Olson
Internet-Draft Internet-Draft
Intended status: Standards Track P. Eggert Intended status: Standards Track P. Eggert
Expires: April 21, 2019 UCLA Expires: June 8, 2019 UCLA
K. Murchison K. Murchison
FastMail FastMail
October 18, 2018 December 5, 2018
The Time Zone Information Format (TZif) The Time Zone Information Format (TZif)
draft-murchison-tzdist-tzif-15 draft-murchison-tzdist-tzif-16
Abstract Abstract
This document defines the Time Zone Information Format (TZif) for This document specifies the Time Zone Information Format (TZif) for
representing and exchanging time zone information, independent of any representing and exchanging time zone information, independent of any
particular service or protocol. Two MIME media types for this format particular service or protocol. Two MIME media types for this format
are also defined. are also defined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2019. This Internet-Draft will expire on June 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Time Zone Information Format (TZif) . . . . . . . . . . . 5 3. The Time Zone Information Format (TZif) . . . . . . . . . . . 5
3.1. TZif Header . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. TZif Header . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. TZif Data Block . . . . . . . . . . . . . . . . . . . . . 8 3.2. TZif Data Block . . . . . . . . . . . . . . . . . . . . . 8
3.3. TZif Footer . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. TZif Footer . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. TZ String Extensions . . . . . . . . . . . . . . . . 12 3.3.1. TZ String Extensions . . . . . . . . . . . . . . . . 12
4. Interoperability Considerations . . . . . . . . . . . . . . . 13 4. Interoperability Considerations . . . . . . . . . . . . . . . 13
5. Use with the Time Zone Data Distribution Service . . . . . . 14 5. Use with the Time Zone Data Distribution Service . . . . . . 14
5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 14 5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 14
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Example TZDIST Request for TZif Data . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. application/tzif . . . . . . . . . . . . . . . . . . . . 17 8.1. application/tzif . . . . . . . . . . . . . . . . . . . . 17
8.2. application/tzif-leap . . . . . . . . . . . . . . . . . . 18 8.2. application/tzif-leap . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Common Interoperability Issues . . . . . . . . . . . 21 Appendix A. Common Interoperability Issues . . . . . . . . . . . 21
Appendix B. Change History (To be removed by RFC Editor before Appendix B. Example TZif Files . . . . . . . . . . . . . . . . . 24
publication) . . . . . . . . . . . . . . . . . . . . 23 B.1. Version 1 File Representing UTC (with Leap Seconds) . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 B.2. Version 2 File Representing Pacific/Honolulu . . . . . . 28
B.3. Truncated Version 3 File Representing Asia/Jerusalem . . 32
Appendix C. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Time zone data typically consists of offsets from Universal Time Time zone data typically consists of offsets from Universal Time
(UT), daylight saving transition rules, one or more local time (UT), daylight saving transition rules, one or more local time
designations (acronyms or abbreviations), and optional leap second designations (acronyms or abbreviations), and optional leap second
adjustments. One such format for conveying this information is adjustments. One such format for conveying this information is
iCalendar [RFC5545]. It is a text-based format used by calendaring iCalendar [RFC5545]. It is a text-based format used by calendaring
and scheduling systems. and scheduling systems.
This document defines the Time Zone Information Format (TZif). It is This document specifies the widely deployed Time Zone Information
a binary format used by most UNIX systems to calculate local time. 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 [tz-link] capable There is a wide variety of interoperable software [tz-link] capable
of generating and reading files in this format. of generating and reading files in this format.
This specification does not define the source of the data assembled This specification does not define the source of the data assembled
into a TZif file. One such source is the IANA-hosted time zone into a TZif file. One such source is the IANA-hosted time zone
database [RFC6557]. database [RFC6557].
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 11 skipping to change at page 5, line 11
time. time.
Wall Time: Another name for local time; short for "wall clock time". Wall Time: Another name for local time; short for "wall clock time".
3. The Time Zone Information Format (TZif) 3. The Time Zone Information Format (TZif)
The time zone information format begins with a fixed 44-octet version The time zone information format begins with a fixed 44-octet version
1 header (Section 3.1) containing a field that specifies the 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 of the file's format. Readers designed for version N can read
version N+1 files without too much trouble; data specific to version version N+1 files without too much trouble; data specific to version
N+1 either typically appears after version N data so that earlier- N+1 either appears after version N data so that earlier-version
version readers can easily ignore later-version data they are not readers can easily ignore later-version data they are not designed
designed for, or it appears as a minor extension to version N that for, or it appears as a minor extension to version N that version N
version N readers are likely to tolerate well. readers are likely to tolerate well.
The version 1 header is followed by a variable-length version 1 data The version 1 header is followed by a variable-length version 1 data
block (Section 3.2) containing four-octet (32-bit) transition times block (Section 3.2) containing four-octet (32-bit) transition times
and leap second occurrences. These 32-bit values are limited to 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 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 03:14:07 UT, and the version 1 header and data block are present only
for backward compatibility with obsolescent readers as discussed in for backward compatibility with obsolescent readers as discussed in
Common Interoperability Issues (Appendix A). Common Interoperability Issues (Appendix A).
Version 1 files terminate after the version 1 data block. Version 2 Version 1 files terminate after the version 1 data block. Version 2
skipping to change at page 6, line 27 skipping to change at page 6, line 27
| Data Block | | Data Block |
+-------------+ +-------------+
| Footer | | Footer |
+-------------+ +-------------+
General Format of TZif Files General Format of TZif Files
3.1. TZif Header 3.1. TZif Header
A TZif header is structured as follows (the lengths of multi-octet A TZif header is structured as follows (the lengths of multi-octet
fields are shown in parenthesis): fields are shown in parentheses):
+---------------+---+ +---------------+---+
| magic (4) |ver| | magic (4) |ver|
+---------------+---+---------------------------------------+ +---------------+---+---------------------------------------+
| [unused - reserved for future use] (15) | | [unused - reserved for future use] (15) |
+---------------+---------------+---------------+-----------+ +---------------+---------------+---------------+-----------+
| isutcnt (4) | isstdcnt (4) | leapcnt (4) | | isutcnt (4) | isstdcnt (4) | leapcnt (4) |
+---------------+---------------+---------------+ +---------------+---------------+---------------+
| timecnt (4) | typecnt (4) | charcnt (4) | | timecnt (4) | typecnt (4) | charcnt (4) |
+---------------+---------------+---------------+ +---------------+---------------+---------------+
skipping to change at page 8, line 8 skipping to change at page 8, line 8
trailing NUL (0x00) octet at the end of the last time zone trailing NUL (0x00) octet at the end of the last time zone
designation. designation.
Although the version 1 and 2+ headers have the same format with the Although the version 1 and 2+ headers have the same format with the
same magic number and version fields, their count fields may differ same magic number and version fields, their count fields may differ
because the version 1 data can be a subset of the version 2+ data. because the version 1 data can be a subset of the version 2+ data.
3.2. TZif Data Block 3.2. TZif Data Block
A TZif data block consists of seven variable-length elements, each of A TZif data block consists of seven variable-length elements, each of
which is series of zero or more items. The number of items in each which is a series of items. The number of items in each series is
series is determined by the corresponding count field in the header. determined by the corresponding count field in the header. The total
The total length of each element is calculated by multiplying the length of each element is calculated by multiplying the number of
number of items by the size of each item. Therefore, implementations items by the size of each item. Therefore, implementations that do
that do not wish to parse or use the version 1 data block can not wish to parse or use the version 1 data block can calculate its
calculate its total length and skip directly to the header of the total length and skip directly to the header of the version 2+ data
verrsion 2+ data block. block.
In the version 1 data block, time values are 32-bit (TIME_SIZE = 4 In the version 1 data block, time values are 32-bit (TIME_SIZE = 4
octets). In the version 2+ data block, present only in version 2 and octets). In the version 2+ data block, present only in version 2 and
3 files, time values are 64-bit (TIME_SIZE = 8 octets). 3 files, time values are 64-bit (TIME_SIZE = 8 octets).
The data block is structured as follows (the lengths of multi-octet The data block is structured as follows (the lengths of multi-octet
fields are shown in parenthesis): fields are shown in parentheses):
+---------------------------------------------------------+ +---------------------------------------------------------+
| transition times (timecnt x TIME_SIZE) | | transition times (timecnt x TIME_SIZE) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| transition types (timecnt) | | transition types (timecnt) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| local time type records (typecnt x 6) | | local time type records (typecnt x 6) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| time zone designations (charcnt) | | time zone designations (charcnt) |
+---------------------------------------------------------+ +---------------------------------------------------------+
skipping to change at page 9, line 7 skipping to change at page 9, line 7
values sorted in strictly ascending order. Each value is used as values sorted in strictly ascending order. Each value is used as
a transition time at which the rules for computing local time may a transition time at which the rules for computing local time may
change. The number of time values is specified by the 'timecnt' change. The number of time values is specified by the 'timecnt'
field in the header. Each time value SHOULD be at least -2**59. 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 (-2**59 is the greatest negated power of 2 that predates the Big
Bang, and avoiding earlier timestamps works around known TZif Bang, and avoiding earlier timestamps works around known TZif
reader bugs relating to outlandlishly negative timestamps.) reader bugs relating to outlandlishly negative timestamps.)
transition types: A series of one-octet unsigned integers specifying transition types: A series of one-octet unsigned integers specifying
the type of local time of the corresponding transition time. the type of local time of the corresponding transition time.
These values serve as indices into the array of local time type These values serve as zero-based indices into the array of local
records. The number of type indices is specified by the 'timecnt' time type records. The number of type indices is specified by the
field in the header. Each type index MUST be in the range [0, 'timecnt' field in the header. Each type index MUST be in the
'typecnt' -1]. range [0, 'typecnt' - 1].
local time type records: A series of six-octet records specifying a local time type records: A series of six-octet records specifying a
local time type. The number of records is specified by the local time type. The number of records is specified by the
'typecnt' field in the header. Each record has the following 'typecnt' field in the header. Each record has the following
format (the lengths of multi-octet fields are shown in format (the lengths of multi-octet fields are shown in
parenthesis): parentheses):
+---------------+-+-+---+ +---------------+---+---+
| utoff (4) |dst|idx| | utoff (4) |dst|idx|
+---------------+---+---+ +---------------+---+---+
utoff: A four-octet signed integer specifying the number of utoff: A four-octet signed integer specifying the number of
seconds to be added to UT in order to determine local time. 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 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 [-89999, 93599] (i.e., its value SHOULD be more than -25 hours
and less than 26 hours). (Avoiding -2**31 allows 32-bit and less than 26 hours). (Avoiding -2**31 allows 32-bit
clients to negate the value without overflow. Restricting it clients to negate the value without overflow. Restricting it
to [-89999, 93599] allows easy support by implementations that to [-89999, 93599] allows easy support by implementations that
already support the the POSIX-required range [-24:59:59, already support the the POSIX-required range [-24:59:59,
25:59:59].) 25:59:59].)
(is)dst: A one-octet value indicating whether local time should (is)dst: A one-octet value indicating whether local time should
be considered Daylight Savings Time (DST). The value MUST be 0 be considered Daylight Saving Time (DST). The value MUST be 0
or 1. A value of one (1) indicates that this type time is DST. or 1. A value of one (1) indicates that this type time is DST.
A value of zero (0) indicates that this time type is standard A value of zero (0) indicates that this time type is standard
time. time.
(desig)idx: A one-octet unsigned integer specifying an index into (desig)idx: A one-octet unsigned integer specifying a zero-based
the series of time zone designation octets, thereby selecting a index into the series of time zone designation octets, thereby
particular designation string. Each index MUST be in the range selecting a particular designation string. Each index MUST be
[0, 'charcnt' -1], and designates the NUL-terminated string of in the range [0, 'charcnt' - 1], and designates the NUL-
octets starting at position 'idx' in the time zone terminated string of octets starting at position 'idx' in the
designations. (This string MAY be empty.) A NUL octet MUST time zone designations. (This string MAY be empty.) A NUL
exist in the time zone designations at or after position 'idx'. octet MUST exist in the time zone designations at or after
position 'idx'.
time zone designations: A series of octets constituting an array of time zone designations: A series of octets constituting an array of
NUL-terminated (0x00) time zone designation strings. The total NUL-terminated (0x00) time zone designation strings. The total
number of octets is specified by the 'charcnt' field in the number of octets is specified by the 'charcnt' field in the
header. Note that two designations MAY overlap if one is a suffix header. Note that two designations MAY overlap if one is a suffix
of the other. The character encoding of time zone designation of the other. The character encoding of time zone designation
strings is not specified; however, see Section 4 of this document. strings is not specified; however, see Section 4 of this document.
leap second records: A series of eight- or twelve-octet records leap second records: A series of eight- or twelve-octet records
specifying the corrections that need to be applied to UTC in order specifying the corrections that need to be applied to UTC in order
to determine TAI. The records are sorted by the occurrence time to determine TAI. The records are sorted by the occurrence time
in strictly ascending order. The number of records is specified in strictly ascending order. The number of records is specified
by the 'leapcnt' field in the header. Each record has one of the by the 'leapcnt' field in the header. Each record has one of the
following structures (the lengths of multi-octet fields are shown following structures (the lengths of multi-octet fields are shown
in parenthesis): in parentheses):
Version 1 Data Block: Version 1 Data Block:
+---------------+---------------+ +---------------+---------------+
| occur (4) | corr (4) | | occur (4) | corr (4) |
+---------------+---------------+ +---------------+---------------+
version 2+ Data Block: version 2+ Data Block:
+---------------+---------------+---------------+ +---------------+---------------+---------------+
skipping to change at page 11, line 41 skipping to change at page 11, line 41
such as "AKST9AKDT"). such as "AKST9AKDT").
In order to eliminate unused space in a TZif file, every nonzero In order to eliminate unused space in a TZif file, every nonzero
local time type index SHOULD appear at least once in the transition local time type index SHOULD appear at least once in the transition
type array. Likewise, every octet in the time zone designations type array. Likewise, every octet in the time zone designations
array SHOULD be used by at least one time type record. array SHOULD be used by at least one time type record.
3.3. TZif Footer 3.3. TZif Footer
The TZif footer is structured as follows (the lengths of multi-octet The TZif footer is structured as follows (the lengths of multi-octet
fields are shown in parenthesis): fields are shown in parentheses):
+---+--------------------+---+ +---+--------------------+---+
| NL| TZ string (0...) |NL | | NL| TZ string (0...) |NL |
+---+--------------------+---+ +---+--------------------+---+
TZif Footer TZif Footer
The elements of the footer are defined as follows: The elements of the footer are defined as follows:
NL: An ASCII new line character (0x0A). NL: An ASCII new line character (0x0A).
skipping to change at page 13, line 7 skipping to change at page 13, line 7
at 00:00 and ends December 31 at 24:00 plus the difference between at 00:00 and ends December 31 at 24:00 plus the difference between
daylight saving and standard time, leaving no room for standard daylight saving and standard time, leaving no room for standard
time in the calendar. time in the calendar.
Example: EST5EDT,0/0,J365/25 Example: EST5EDT,0/0,J365/25
This represents a time zone that observes daylight saving time This represents a time zone that observes daylight saving time
all year. It is 4 hours west of UT and is abbreviated "EDT". all year. It is 4 hours west of UT and is abbreviated "EDT".
4. Interoperability Considerations 4. Interoperability Considerations
These recommended practices should be followed in order to assure The following practices help ensure interoperability of TZif
interoperability of TZif applications. applications.
o Version 1 files are considered a legacy format and SHOULD NOT be o Version 1 files are considered a legacy format and SHOULD NOT be
generated, as they do not support transition times after the year generated, as they do not support transition times after the year
2038. 2038.
o Implementations that only understand Version 1 MUST ignore any o Implementations that only understand Version 1 MUST ignore any
data that extends beyond the calculated end of the version 1 data data that extends beyond the calculated end of the version 1 data
block. block.
o Implementations SHOULD generate a version 3 file if TZ string o Implementations SHOULD generate a version 3 file if TZ string
skipping to change at page 15, line 12 skipping to change at page 15, line 12
untruncated TZif files with empty TZ strings, a truncated TZif file untruncated TZif files with empty TZ strings, a truncated TZif file
does not indicate local time after the last transition. does not indicate local time after the last transition.
All represented information that falls inside the truncation range All represented information that falls inside the truncation range
MUST be the same as that represented by a corresponding untruncated MUST be the same as that represented by a corresponding untruncated
TZif file. TZif file.
TZDIST clients SHOULD NOT use a truncated TZif file (as described TZDIST clients SHOULD NOT use a truncated TZif file (as described
above) to interpret timestamps outside the truncation time range. above) to interpret timestamps outside the truncation time range.
5.2. Example 5.2. Example TZDIST Request for TZif Data
In this example, the client checks the server for the available In this example, the client checks the server for the available
formats and then requests that the time zone with a specific time formats and then requests that the time zone with a specific time
zone identifier be returned in Time Zone Information Format. zone identifier be returned in Time Zone Information Format.
Note that this example presumes that the time zone context path has Note that this example presumes that the time zone context path has
been discovered (see [RFC7808] Section 4.2.1) to be "/tzdist". been discovered (see [RFC7808] Section 4.2.1) to be "/tzdist".
>> Request << >> Request <<
skipping to change at page 17, line 27 skipping to change at page 17, line 27
protection. Since time zone information is used in many critical protection. Since time zone information is used in many critical
applications, integrity protection may be required, and must be applications, integrity protection may be required, and must be
provided externally. provided externally.
7. Privacy Considerations 7. Privacy Considerations
The Time Zone Information Format contains publicly available data and The Time Zone Information Format contains publicly available data and
the format does not define any extensible areas that could be used to the format does not define any extensible areas that could be used to
store private data. store private data.
As discussed in Section 9 of [RFC7808], transmission of time zone
data over an insecure communications channel could leak the past,
current, or future location of a device or user. As such, TZif data
transmitted over a public communications channel MUST be protected
with a confidentiality layer such as that provided by Transport Layer
Security (TLS) [RFC8446].
8. IANA Considerations 8. IANA Considerations
This document defines two MIME [RFC6838] media types for the exchange This document defines two MIME [RFC6838] media types for the exchange
of data utilizing the Time Zone Information Format. of data utilizing the Time Zone Information Format.
8.1. application/tzif 8.1. application/tzif
Type name: application Type name: application
Subtype name: tzif Subtype name: tzif
skipping to change at page 20, line 40 skipping to change at page 20, line 48
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009, RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>. <https://www.rfc-editor.org/info/rfc5545>.
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
Time Zone Database", BCP 175, RFC 6557, Time Zone Database", BCP 175, RFC 6557,
DOI 10.17487/RFC6557, February 2012, DOI 10.17487/RFC6557, February 2012,
<https://www.rfc-editor.org/info/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, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and
Daylight Saving Time Data", 2018, Daylight Saving Time Data", 2018,
<https://www.iana.org/time-zones/repository/tz-link.html>. <https://www.iana.org/time-zones/repository/tz-link.html>.
10.3. URIs 10.3. URIs
[1] https://tools.ietf.org/html/bcp14 [1] https://tools.ietf.org/html/bcp14
[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/
time.html time.html
skipping to change at page 23, line 44 skipping to change at page 24, line 12
range of -12 through +12 hours, and so do not support locations range of -12 through +12 hours, and so do not support locations
like Kiritimati that are outside this range. like Kiritimati that are outside this range.
o Some readers mishandle UT offsets in the range [-3599, -1] seconds o Some readers mishandle UT offsets in the range [-3599, -1] seconds
from UT, because they integer-divide the offset by 3600 to get 0 from UT, because they integer-divide the offset by 3600 to get 0
and then display the hour part as "+00". and then display the hour part as "+00".
o Some readers mishandle UT offsets that are not a multiple of one o Some readers mishandle UT offsets that are not a multiple of one
hour, or of 15 minutes, or of 1 minute. hour, or of 15 minutes, or of 1 minute.
Appendix B. Change History (To be removed by RFC Editor before Appendix B. Example TZif Files
The following sections contain annotated hexadecimal dumps of example
TZif files.
Note that these examples should only be considered informative.
Although the example data entries are current as of the publication
date of this document, the data will likely change in the future as
leap seconds are added and changes are made to civil time.
B.1. Version 1 File Representing UTC (with Leap Seconds)
+-------+---------------+------------------+------------------------+
| File | Data Octets | Record Name / | Field Value |
| Offse | (hexadecimal) | Field Name | |
| t | | | |
+-------+---------------+------------------+------------------------+
| 000 | 54 5a 69 66 | magic | "TZif" |
| 004 | 00 | version | 0 (1) |
| 005 | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 | | |
| 020 | 00 00 00 01 | isutccnt | 1 |
| 024 | 00 00 00 01 | isstdcnt | 1 |
| 028 | 00 00 00 1b | isleapcnt | 27 |
| 032 | 00 00 00 00 | timecnt | 0 |
| 036 | 00 00 00 01 | typecnt | 1 |
| 040 | 00 00 00 04 | charcnt | 4 |
| | | | |
| | | localtimetype[0] | |
| 044 | 00 00 00 00 | utcoff | 00:00 |
| 048 | 00 | isdst | 0 (no) |
| 049 | 00 | desigidx | 0 |
| | | | |
| 050 | 55 54 43 00 | designations[0] | "UTC" |
| | | | |
| | | leapsecond[0] | |
| 054 | 04 b2 58 00 | occurrence | 78796800 |
| | | | (1972-06-30T23:59:60Z) |
| 058 | 00 00 00 01 | correction | 1 |
| | | | |
| | | leapsecond[1] | |
| 062 | 05 a4 ec 01 | occurrence | 94694401 |
| | | | (1972-12-31T23:59:60Z) |
| 066 | 00 00 00 02 | correction | 2 |
| | | | |
| | | leapsecond[2] | |
| 070 | 07 86 1f 82 | occurrence | 126230402 |
| | | | (1973-12-31T23:59:60Z) |
| 074 | 00 00 00 03 | correction | 3 |
| | | | |
| | | leapsecond[3] | |
| 078 | 09 67 53 03 | occurrence | 157766403 |
| | | | (1974-12-31T23:59:60Z) |
| 082 | 00 00 00 04 | correction | 4 |
| | | | |
| | | 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 | UT/local[0] | 0 (local) |
| | | | |
| 271 | 00 | standard/wall[0] | 0 (wall) |
+-------+---------------+------------------+------------------------+
To determine TAI corresponding to 2000-01-01T00:00:00Z (UNIX time =
946684800), the following procedure would be followed:
1. Find the 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
+--------+--------------+------------------+------------------------+
| File | Hexadecimal | Record Name / | Field Value |
| Offset | Octets | Field Name | |
+--------+--------------+------------------+------------------------+
| 000 | 54 5a 69 66 | magic | "TZif" |
| 004 | 32 | version | '2' (2) |
| 005 | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 | | |
| 020 | 00 00 00 06 | isutccnt | 6 |
| 024 | 00 00 00 06 | isstdcnt | 6 |
| 028 | 00 00 00 00 | isleapcnt | 0 |
| 032 | 00 00 00 07 | timecnt | 7 |
| 036 | 00 00 00 06 | typecnt | 6 |
| 040 | 00 00 00 14 | charcnt | 20 |
| | | | |
| 044 | 80 00 00 00 | trans time[0] | -2147483648 |
| | | | (1901-12-13T20:45:52Z) |
| 048 | bb 05 43 48 | trans time[1] | -1157283000 |
| | | | (1933-04-30T12:30:00Z) |
| 052 | bb 21 71 58 | trans time[2] | -1155436200 |
| | | | (1933-05-21T21:30:00Z) |
| 056 | cb 89 3d c8 | trans time[3] | -880198200 |
| | | | (1942-02-09T12:30:00Z) |
| 060 | d2 23 f4 70 | trans time[4] | -769395600 |
| | | | (1945-08-14T23:00:00Z) |
| 064 | d2 61 49 38 | trans time[5] | -765376200 |
| | | | (1945-09-30T11:30:00Z) |
| 068 | d5 8d 73 48 | trans time[6] | -712150200 |
| | | | (1947-06-08T12:30:00Z) |
| | | | |
| 072 | 01 | trans type[0] | 1 |
| 073 | 02 | trans type[1] | 2 |
| 074 | 01 | trans type[2] | 1 |
| 075 | 03 | trans type[3] | 3 |
| 076 | 04 | trans type[4] | 4 |
| 077 | 01 | trans type[5] | 1 |
| 078 | 05 | trans type[6] | 5 |
| | | | |
| | | localtimetype[0] | |
| 079 | ff ff 6c 02 | utcoff | -37886 (-10:21:26) |
| 083 | 00 | isdst | 0 (no) |
| 084 | 00 | desigidx | 0 |
| | | | |
| | | localtimetype[1] | |
| 085 | ff ff 6c 58 | utcoff | -37800 (-10:30) |
| 089 | 00 | isdst | 0 (no) |
| 090 | 04 | desigidx | 4 |
| | | | |
| | | localtimetype[2] | |
| 091 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 095 | 01 | isdst | 1 (yes) |
| 096 | 08 | desigidx | 8 |
| | | | |
| | | localtimetype[3] | |
| 097 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 101 | 01 | isdst | 1 (yes) |
| 102 | 0c | desigidx | 12 |
| | | | |
| | | localtimetype[4] | |
| 103 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 107 | 01 | isdst | 1 (yes) |
| 108 | 10 | desigidx | 16 |
| | | | |
| | | localtimetype[5] | |
| 109 | ff ff 73 60 | utcoff | -36000 (-10:00) |
| 113 | 00 | isdst | 0 (no) |
| 114 | 04 | desigidx | 4 |
| | | | |
| 115 | 4c 4d 54 00 | designations[0] | "LMT" |
| 119 | 48 53 54 00 | designations[4] | "HST" |
| 123 | 48 44 54 00 | designations[8] | "HDT" |
| 127 | 48 57 54 00 | designations[12] | "HWT" |
| 131 | 48 50 54 00 | designations[16] | "HPT" |
| | | | |
| 135 | 00 | UT/local[0] | 1 (UT) |
| 136 | 00 | UT/local[1] | 0 (local) |
| 137 | 00 | UT/local[2] | 0 (local) |
| 138 | 00 | UT/local[3] | 0 (local) |
| 139 | 01 | UT/local[4] | 1 (UT) |
| 140 | 00 | UT/local[5] | 0 (local) |
| | | | |
| 141 | 00 | standard/wall[0] | 1 (standard) |
| 142 | 00 | standard/wall[1] | 0 (wall) |
| 143 | 00 | standard/wall[2] | 0 (wall) |
| 144 | 00 | standard/wall[3] | 0 (wall) |
| 145 | 01 | standard/wall[4] | 1 (standard) |
| 146 | 00 | standard/wall[5] | 0 (wall) |
| | | | |
| 147 | 54 5a 69 66 | magic | "TZif" |
| 151 | 32 | version | '2' (2) |
| 152 | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 | | |
| 167 | 00 00 00 06 | isutccnt | 6 |
| 171 | 00 00 00 06 | isstdcnt | 6 |
| 175 | 00 00 00 00 | isleapcnt | 0 |
| 179 | 00 00 00 07 | timecnt | 7 |
| 183 | 00 00 00 06 | typecnt | 6 |
| 187 | 00 00 00 14 | charcnt | 20 |
| | | | |
| 191 | ff ff ff ff | trans time[0] | -2334101314 |
| | 74 e0 70 be | | (1896-01-13T22:31:26Z) |
| 199 | ff ff ff ff | trans time[1] | -1157283000 |
| | bb 05 43 48 | | (1933-04-30T12:30:00Z) |
| 207 | ff ff ff ff | trans time[2] | -1155436200 |
| | bb 21 71 58 | | (1933-05-21T21:30:00Z) |
| 215 | ff ff ff ff | trans time[3] | -880198200 |
| | cb 89 3d c8 | | (1942-02-09T12:30:00Z) |
| 223 | ff ff ff ff | trans time[4] | -769395600 |
| | d2 23 f4 70 | | (1945-08-14T23:00:00Z) |
| 231 | ff ff ff ff | trans time[5] | -765376200 |
| | d2 61 49 38 | | (1945-09-30T11:30:00Z) |
| 239 | ff ff ff ff | trans time[6] | -712150200 |
| | d5 8d 73 48 | | (1947-06-08T12:30:00Z) |
| | | | |
| 247 | 01 | trans type[0] | 1 |
| 248 | 02 | trans type[1] | 2 |
| 249 | 01 | trans type[2] | 1 |
| 250 | 03 | trans type[3] | 3 |
| 251 | 04 | trans type[4] | 4 |
| 252 | 01 | trans type[5] | 1 |
| 253 | 05 | trans type[6] | 5 |
| | | | |
| | | localtimetype[0] | |
| 254 | ff ff 6c 02 | utcoff | -37886 (-10:21:26) |
| 258 | 00 | isdst | 0 (no) |
| 259 | 00 | desigidx | 0 |
| | | | |
| | | localtimetype[1] | |
| 260 | ff ff 6c 58 | utcoff | -37800 (-10:30) |
| 264 | 00 | isdst | 0 (no) |
| 265 | 04 | desigidx | 4 |
| | | | |
| | | localtimetype[2] | |
| 266 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 270 | 01 | isdst | 1 (yes) |
| 271 | 08 | desigidx | 8 |
| | | | |
| | | localtimetype[3] | |
| 272 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 276 | 01 | isdst | 1 (yes) |
| 277 | 0c | desigidx | 12 |
| | | | |
| | | localtimetype[4] | |
| 278 | ff ff 7a 68 | utcoff | -34200 (-09:30) |
| 282 | 01 | isdst | 1 (yes) |
| 283 | 10 | desigidx | 16 |
| | | | |
| | | localtimetype[5] | |
| 284 | ff ff 73 60 | utcoff | -36000 (-10:00) |
| 288 | 00 | isdst | 0 (no) |
| 289 | 04 | desigidx | 4 |
| | | | |
| 290 | 4c 4d 54 00 | designations[0] | "LMT" |
| 294 | 48 53 54 00 | designations[4] | "HST" |
| 298 | 48 44 54 00 | designations[8] | "HDT" |
| 302 | 48 57 54 00 | designations[12] | "HWT" |
| 306 | 48 50 54 00 | designations[16] | "HPT" |
| | | | |
| 310 | 00 | UT/local[0] | 0 (local) |
| 311 | 00 | UT/local[1] | 0 (local) |
| 312 | 00 | UT/local[2] | 0 (local) |
| 313 | 00 | UT/local[3] | 0 (local) |
| 314 | 01 | UT/local[4] | 1 (UT) |
| 315 | 00 | UT/local[5] | 0 (local) |
| | | | |
| 316 | 00 | standard/wall[0] | 0 (wall) |
| 317 | 00 | standard/wall[1] | 0 (wall) |
| 318 | 00 | standard/wall[2] | 0 (wall) |
| 319 | 00 | standard/wall[3] | 0 (wall) |
| 320 | 01 | standard/wall[4] | 1 (standard) |
| 321 | 00 | standard/wall[5] | 0 (wall) |
| | | | |
| 322 | 0a | NL | '\n' |
| 323 | 48 53 54 31 | TZ string | "HST10" |
| | 30 | | |
| 328 | 0a | NL | '\n' |
+--------+--------------+------------------+------------------------+
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 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. Lookup 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 the latest time transition prior to the time of interest
(there is no such transition).
2. Lookup 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 3 File Representing Asia/Jerusalem
The following TZif file has been truncated to start on
2038-01-01T00:00:00Z.
+--------+--------------+------------------+------------------------+
| File | Hexadecimal | Record Name / | Field Value |
| Offset | Octets | Field Name | |
+--------+--------------+------------------+------------------------+
| 000 | 54 5a 69 66 | magic | "TZif" |
| 004 | 33 | version | '3' (3) |
| 005 | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 | | |
| 020 | 00 00 00 00 | isutccnt | 0 |
| 024 | 00 00 00 00 | isstdcnt | 0 |
| 028 | 00 00 00 00 | isleapcnt | 0 |
| 032 | 00 00 00 00 | timecnt | 0 |
| 036 | 00 00 00 00 | typecnt | 0 |
| 040 | 00 00 00 00 | charcnt | 0 |
| | | | |
| 044 | 54 5a 69 66 | magic | "TZif" |
| 048 | 33 | version | '3' (3) |
| 049 | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 00 | | |
| | 00 00 00 | | |
| 064 | 00 00 00 03 | isutccnt | 1 |
| 068 | 00 00 00 03 | isstdcnt | 1 |
| 072 | 00 00 00 00 | isleapcnt | 0 |
| 076 | 00 00 00 03 | timecnt | 1 |
| 080 | 00 00 00 03 | typecnt | 1 |
| 084 | 00 00 00 08 | charcnt | 4 |
| | | | |
| 088 | 00 00 00 00 | trans time[0] | 2145916800 |
| | 7f e8 17 80 | | (2038-01-01T00:00:00Z) |
| | | | |
| 096 | 00 | trans type[0] | 0 |
| | | | |
| | | localtimetype[0] | |
| 097 | 00 00 1c 20 | utcoff | 7200 (+02:00) |
| 101 | 00 | isdst | 0 (no) |
| 102 | 00 | desigidx | 0 |
| | | | |
| 103 | 49 53 54 00 | designations[0] | "IST" |
| | | | |
| 107 | 01 | UT/local[0] | 1 (UT) |
| | | | |
| 108 | 01 | standard/wall[0] | 1 (standard) |
| | | | |
| 109 | 0a | NL | '\n' |
| 110 | 49 53 54 2d | TZ string | "IST-2IDT, |
| | 32 49 44 54 | | M3.4.4/26,M10.5.0" |
| | 2c 4d 33 2e | | |
| | 34 2e 34 2f | | |
| | 32 36 2c 4d | | |
| | 31 30 2e 35 | | |
| | 2e 30 | | |
| 136 | 0a | NL | '\n' |
+--------+--------------+------------------+------------------------+
Appendix C. Change History (To be removed by RFC Editor before
publication) publication)
Changes since -15:
o Addressed IESG comments from Ben Campbell.
o Addressed IESG comments from Spencer Dawkins.
o Addressed IESG comments from Benjamin Kaduk.
o Added annotated example files.
o Minor editorial changes.
Changes since -14: Changes since -14:
o Addressed last call comments from Tom Petch. o Addressed last call comments from Tom Petch.
o Addressed last call comments from Qin Wu. o Addressed last call comments from Qin Wu.
o Addressed last call comments from Dale Worley. o Addressed last call comments from Dale Worley.
Changes since -13: Changes since -13:
 End of changes. 26 change blocks. 
45 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/