draft-murchison-rfc8536bis-06.txt		draft-murchison-rfc8536bis.txt
	Internet Engineering Task Force (IETF) A.D. Olson		Internet Engineering Task Force (IETF) A.D. Olson
	Internet-Draft		Internet-Draft
	Obsoletes: 8536 (if approved) P. Eggert		Obsoletes: 8536 (if approved) P. Eggert
	Intended status: Standards Track UCLA		Intended status: Standards Track UCLA
	Expires: 8 September 2023 K. Murchison		Expires: 9 September 2023 K. Murchison
	Fastmail		Fastmail
	7 March 2023		8 March 2023
	The Time Zone Information Format (TZif)		The Time Zone Information Format (TZif)
	draft-murchison-rfc8536bis-06		draft-murchison-rfc8536bis-07
	Abstract		Abstract
	This document specifies 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 media types for this format are		particular service or protocol. Two media types for this format are
	also defined.		also defined.
	Skipping		Skipping
	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 8 September 2023.		This Internet-Draft will expire on 9 September 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	Skipping		Skipping
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . . 12		3.3. TZif Footer . . . . . . . . . . . . . . . . . . . . . . . 12
			3.3.1. All-Year Daylight Saving Time . . . . . . . . . . . . 13
	3.3.1. TZ String Extensions . . . . . . . . . . . . . . . . 13		3.3.2. TZ String Extension . . . . . . . . . . . . . . . . . 13
	4. Interoperability Considerations . . . . . . . . . . . . . . . 13		4. Interoperability Considerations . . . . . . . . . . . . . . . 14
	5. Use with the Time Zone Data Distribution Service . . . . . . 15		5. Use with the Time Zone Data Distribution Service . . . . . . 15
	5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 15		5.1. Truncating TZif Files . . . . . . . . . . . . . . . . . . 16
	5.2. Example TZDIST Request for TZif Data . . . . . . . . . . 16		5.2. Example TZDIST Request for TZif Data . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8.1. application/tzif . . . . . . . . . . . . . . . . . . . . 18		8.1. application/tzif . . . . . . . . . . . . . . . . . . . . 18
	8.2. application/tzif-leap . . . . . . . . . . . . . . . . . . 19		8.2. application/tzif-leap . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . 21		9.1. Normative References . . . . . . . . . . . . . . . . . . 21
	Skipping		Skipping
	Appendix A. Common Interoperability Issues . . . . . . . . . . . 23		Appendix A. Common Interoperability Issues . . . . . . . . . . . 23
	Appendix B. Example TZif Files . . . . . . . . . . . . . . . . . 26		Appendix B. Example TZif Files . . . . . . . . . . . . . . . . . 26
	B.1. Version 1 File Representing UTC (with Leap Seconds) . . . 26		B.1. Version 1 File Representing UTC (with Leap Seconds) . . . 26
	B.2. Version 2 File Representing Pacific/Honolulu . . . . . . 32		B.2. Version 2 File Representing Pacific/Honolulu . . . . . . 32
	B.3. Truncated Version 3 File Representing Asia/Jerusalem . . 39		B.3. Truncated Version 3 File Representing Asia/Jerusalem . . 39
	B.4. Truncated Version 4 File Representing America/New_York . 41		B.4. Truncated Version 4 File Representing America/New_York . 41
	Appendix C. Changes from RFC 8536 . . . . . . . . . . . . . . . 44		Appendix C. Changes from RFC 8536 . . . . . . . . . . . . . . . 44
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 45		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 45
	D.1. Since rfc8536bis-05 . . . . . . . . . . . . . . . . . . . 45		D.1. Since rfc8536bis-06 . . . . . . . . . . . . . . . . . . . 45
	D.2. Since rfc8536bis-04 . . . . . . . . . . . . . . . . . . . 45		D.2. Since rfc8536bis-05 . . . . . . . . . . . . . . . . . . . 45
	D.3. Since rfc8536bis-03 . . . . . . . . . . . . . . . . . . . 45		D.3. Since rfc8536bis-04 . . . . . . . . . . . . . . . . . . . 45
	D.4. Since rfc8536bis-02 . . . . . . . . . . . . . . . . . . . 45		D.4. Since rfc8536bis-03 . . . . . . . . . . . . . . . . . . . 45
	D.5. Since rfc8536bis-01 . . . . . . . . . . . . . . . . . . . 45		D.5. Since rfc8536bis-02 . . . . . . . . . . . . . . . . . . . 45
	D.6. Since rfc8536bis-00 . . . . . . . . . . . . . . . . . . . 45		D.6. Since rfc8536bis-01 . . . . . . . . . . . . . . . . . . . 45
			D.7. Since rfc8536bis-00 . . . . . . . . . . . . . . . . . . . 46
	D.7. Since RFC 8536 . . . . . . . . . . . . . . . . . . . . . 45		D.8. Since RFC 8536 . . . . . . . . . . . . . . . . . . . . . 46
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	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
	Skipping		Skipping
	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",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The following terms are used in this document (see "Sources for Time		The following terms are used in this document (see "Time zone and
	Zone and Daylight Saving Time Data" [tz-link] for more detailed		daylight saving time data" [tz-link] for more detailed information
	information about civil timekeeping data and practice):		about civil timekeeping data and practice):
	Coordinated Universal Time (UTC): The basis for civil time since		Coordinated Universal Time (UTC): The basis for civil time since
	1960. It is approximately equal to mean solar time at the prime		1960. It is approximately equal to mean solar time at the prime
	meridian (0 degrees longitude).		meridian (0 degrees longitude).
	Daylight Saving Time (DST): The time according to a location's law		Daylight Saving Time (DST): The time according to a location's law
	or practice, when adjusted as necessary from standard time. The		or practice, when adjusted as necessary from standard time. The
	adjustment may be positive or negative, and the amount of		adjustment may be positive or negative, and the amount of
	Skipping		Skipping
	environment variable as defined in Section 8.3 of the "Base		environment variable as defined in Section 8.3 of the "Base
	Definitions" volume of [POSIX] and MUST encode the POSIX		Definitions" volume of [POSIX] and MUST encode the POSIX
	portable character set as ASCII. The leap second table MUST		portable character set as ASCII. The leap second table MUST
	NOT be truncated at the start (Section 5.1), and MUST NOT		NOT be truncated at the start (Section 5.1), and MUST NOT
	contain an expiration time.		contain an expiration time.
	'3' (0x33) Version 3 - The file MUST conform to all version 2		'3' (0x33) Version 3 - The file MUST conform to all version 2
	requirements, except that any TZ string in the footer		requirements, except that any TZ string in the footer
	(Section 3.3) MAY use the TZ string extensions described below		(Section 3.3) MAY use the TZ string extension described below
	(Section 3.3.1).		(Section 3.3.2).
	'4' (0x34) Version 4 - The file MUST conform to all version 3		'4' (0x34) Version 4 - The file MUST conform to all version 3
	requirements, except that the leap second table MAY be		requirements, except that the leap second table MAY be
	truncated at the start, and MAY contain an expiration time.		truncated at the start, and MAY contain an expiration time.
	isutcnt: A four-octet unsigned integer specifying the number of UT/		isutcnt: A four-octet unsigned integer specifying the number of UT/
	local indicators contained in the data block -- MUST either be		local indicators contained in the data block -- MUST either be
	zero or equal to "typecnt".		zero or equal to "typecnt".
	Skipping		Skipping
	its correction is positive. Each correction after the first		its correction is positive. Each correction after the first
	MUST differ from the previous correction by either one (1) for		MUST differ from the previous correction by either one (1) for
	a positive leap second or minus one (-1) for a negative leap		a positive leap second or minus one (-1) for a negative leap
	second, except that if there are two or more leap-second		second, except that if there are two or more leap-second
	records the correction value of the last record MAY be the same		records the correction value of the last record MAY be the same
	as the second-to-last record, with the last record indicating		as the second-to-last record, with the last record indicating
	the expiration time of the leap-second table.		the expiration time of the leap-second table.
			Note that if leap seconds become permanently discontinued, as
			requested by the General Conference on Weights and Measures
			[CGPM-2022-R4], the leap second table SHOULD NOT expire since
			it will not be updated in the foreseeable future.
	standard/wall indicators: A series of one-octet values indicating		standard/wall indicators: A series of one-octet values indicating
	whether the transition times associated with local time types were		whether the transition times associated with local time types were
	specified as standard time or wall-clock time. Each value MUST be		specified as standard time or wall-clock time. Each value MUST be
	0 or 1. A value of one (1) indicates standard time. The value		0 or 1. A value of one (1) indicates standard time. The value
	MUST be set to one (1) if the corresponding UT/local indicator is		MUST be set to one (1) if the corresponding UT/local indicator is
	set to one (1). A value of zero (0) indicates wall time. The		set to one (1). A value of zero (0) indicates wall time. The
	number of values is specified by the "isstdcnt" field in the		number of values is specified by the "isstdcnt" field in the
	header. If "isstdcnt" is zero (0), all transition times		header. If "isstdcnt" is zero (0), all transition times
	Skipping		Skipping
	the transition times associated with local time types were		the transition times associated with local time types were
	specified as UT or local time. Each value MUST be 0 or 1. A		specified as UT or local time. Each value MUST be 0 or 1. A
	value of one (1) indicates UT, and the corresponding standard/wall		value of one (1) indicates UT, and the corresponding standard/wall
	indicator MUST also be set to one (1). A value of zero (0)		indicator MUST also be set to one (1). A value of zero (0)
	indicates local time. The number of values is specified by the		indicates local time. The number of values is specified by the
	"isutcnt" field in the header. If "isutcnt" is zero (0), all		"isutcnt" field in the header. If "isutcnt" is zero (0), all
	transition times associated with local time types are assumed to		transition times associated with local time types are assumed to
	be specified as local time.		be specified as local time.
	The type corresponding to a transition time specifies local time for		The type corresponding to a transition time specifies local time for
	timestamps starting at the given transition time and continuing up		timestamps starting at the given transition time and continuing up
	to, but not including, the next transition time. Local time for		to, but not including, the next transition time. Local time for
	timestamps before the first transition is specified by the first time		timestamps before the first transition is specified by the first time
	type (time type 0). Local time for timestamps on or after the last		type (time type 0). Local time for timestamps on or after the last
	transition is specified by the TZ string in the footer (Section 3.3)		transition is specified by the TZ string in the footer (Section 3.3)
	if present and nonempty; otherwise, it is unspecified. If there are		if present and nonempty; otherwise, it is unspecified. If there are
	no transitions, local time for all timestamps is specified by the TZ		no transitions, local time for all timestamps is specified by the TZ
	Skipping		Skipping
	| NL| TZ string (0...) |NL |		| NL| TZ string (0...) |NL |
	+---+--------------------+---+		+---+--------------------+---+
	Figure 4: TZif Footer		Figure 4: 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).
	TZ string: A rule for computing local time changes after the last		TZ string: A rule for computing local time changes after the last
	transition time stored in the version 2+ data block. The string		transition time stored in the version 2+ data block. The string
	is either empty or uses the expanded format of the "TZ"		is either empty or uses the expanded format of the "TZ"
	environment variable as defined in Section 8.3 of the "Base		environment variable as defined in Section 8.3 of the "Base
	Definitions" volume of [POSIX] with ASCII encoding, possibly		Definitions" volume of [POSIX] with ASCII encoding, possibly
	utilizing extensions described below (Section 3.3.1) in version 3		utilizing extension described below (Section 3.3.2) in version 3
	and higher files. If the string is empty, the corresponding		and higher files. If the string is empty, the corresponding
	information is not available. If the string is nonempty and one		information is not available. If the string is nonempty and one
	or more transitions appear in the version 2+ data, the string MUST		or more transitions appear in the version 2+ data, the string MUST
	be consistent with the last version 2+ transition. In other		be consistent with the last version 2+ transition. In other
	words, evaluating the TZ string at the time of the last transition		words, evaluating the TZ string at the time of the last transition
	should yield the same time type as was specified in the last		should yield the same time type as was specified in the last
	transition. The string MUST NOT contain NUL octets or be		transition. The string MUST NOT contain NUL octets or be
	NUL-terminated, and it SHOULD NOT begin with the ':' (colon)		NUL-terminated, and it SHOULD NOT begin with the ':' (colon)
	character.		character.
	The TZif footer is present only in version 2 and higher files, as the		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		obsolescent version 1 format was designed before the need for a
	footer was apparent.		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.1. TZ String Extensions		3.3.2. TZ String Extension
	The TZ string in a version 3 or higher TZif file MAY use the		The TZ string in a version 3 or higher TZif file MAY use the
	following extensions to POSIX TZ strings. These extensions are		following extension to POSIX TZ strings. This extension is described
	described using the terminology of Section 8.3 of the "Base		using the terminology of Section 8.3 of the "Base Definitions" volume
	Definitions" volume of [POSIX].		of [POSIX].
	* The hours part of the transition times may be signed and range		* The hours part of the transition times may be signed and range
	from -167 through 167 (-167 <= hh <= 167) instead of the POSIX-		from -167 through 167 (-167 <= hh <= 167) instead of the POSIX-
	required unsigned values from 0 through 24.		required unsigned values from 0 through 24.
	Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1		Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1
	This represents a time zone that observes daylight saving time		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		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		the day before October's last Sunday. Standard time is 3 hours
	west of UT and is abbreviated "-03"; daylight saving time is 2		west of UT and is abbreviated "-03"; daylight saving time is 2
	hours west of UT and is abbreviated "-02".		hours west of UT and is abbreviated "-02".
	* DST is considered to be in effect all year if its UT offset is		Note that a TZif file that uses the above extension is always
	less than (i.e., west of) that of standard time, and it starts		REQUIRED to be designated as version 3 (or higher), even if a future
	January 1 at 00:00 and ends December 31 at 24:00 minus the		version of POSIX adopts this extension.
	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 observes daylight saving time
	all year. It is 4 hours west of UT and is abbreviated "EDT".
	The "XXX" is ignored.
	4. Interoperability Considerations		4. Interoperability Considerations
	The following practices help ensure the interoperability of TZif		The following practices help ensure the interoperability of TZif
	applications.		applications.
	* Version 1 files are considered a legacy format and SHOULD NOT be		* 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.
	* Readers that understand only version 1 MUST ignore any data that		* Readers that understand only version 1 MUST ignore any data that
	extends beyond the calculated end of the version 1 data block.		extends beyond the calculated end of the version 1 data block.
	* Other than version 1, writers should generate the lowest version		* Other than version 1, writers should generate the lowest version
	Skipping		Skipping
	version 2+ header and data block, and by the footer. This		version 2+ header and data block, and by the footer. This
	guideline helps obsolescent version 1 readers agree with current		guideline helps obsolescent version 1 readers agree with current
	readers about timestamps within the contiguous sub-sequence.		readers about timestamps within the contiguous sub-sequence.
	* When a TZif file contains a leap second table expiration time,		* When a TZif file contains a leap second table expiration time,
	TZif readers SHOULD either refuse to process post-expiration		TZif readers SHOULD either refuse to process post-expiration
	timestamps, or process them as if the expiration time did not		timestamps, or process them as if the expiration time did not
	exist (possibly with an error indication).		exist (possibly with an error indication).
	* Time zone designations SHOULD consist of at least three (3) and no		* Time zone designations SHOULD consist of at least three (3) and no
	more than six (6) ASCII characters from the set of alphanumerics,		more than six (6) ASCII characters from the set of alphanumerics,
	'-', and '+'. This is for compatibility with POSIX requirements		'-', and '+'. This is for compatibility with POSIX requirements
	for time zone abbreviations.		for time zone abbreviations.
	* When reading a version 2 or higher file, readers SHOULD ignore the		* When reading a version 2 or higher file, readers SHOULD ignore the
	version 1 header and data block except for the purpose of skipping		version 1 header and data block except for the purpose of skipping
	over them.		over them.
	* Readers SHOULD calculate the total lengths of the headers and data		* Readers SHOULD calculate the total lengths of the headers and data
	blocks and check that they all fit within the actual file size, as		blocks and check that they all fit within the actual file size, as
	part of a validity check for the file.		part of a validity check for the file.
	* When a TZif file is used in a MIME message entity, it SHOULD be		* When a TZif file is used in a MIME message entity, it SHOULD be
	indicated by one of the following media types:		indicated by one of the following media types:
	- "application/tzif-leap" (Section 8.2) to indicate that leap-		- "application/tzif-leap" (Section 8.2) to indicate that leap-
	second records are included in the TZif data as necessary (none		second records are included in the TZif data as necessary (none
	are necessary if the file is truncated to a range that precedes		are necessary if the file is truncated to a range that precedes
	the first leap second).		the first leap second).
	- "application/tzif" (Section 8.1) to indicate that leap-second		- "application/tzif" (Section 8.1) to indicate that leap-second
	records are not included in the TZif data; "leapcnt" in the		records are not included in the TZif data; "leapcnt" in the
	header(s) MUST be zero (0).		header(s) MUST be zero (0).
	Skipping		Skipping
	"application/tzif-leap" (Section 8.2) in its "capabilities" response		"application/tzif-leap" (Section 8.2) in its "capabilities" response
	if it is able to generate TZif files containing leap-second records.		if it is able to generate TZif files containing leap-second records.
	A TZDIST service MUST NOT advertise the "application/tzif-leap" media		A TZDIST service MUST NOT advertise the "application/tzif-leap" media
	type without also advertising "application/tzif".		type without also advertising "application/tzif".
	TZDIST clients MUST use the HTTP "Accept" [RFC7231] header field to		TZDIST clients MUST use the HTTP "Accept" [RFC7231] header field to
	indicate their preference to receive data in the "application/tzif"		indicate their preference to receive data in the "application/tzif"
	and/or "application/tzif-leap" formats.		and/or "application/tzif-leap" formats.
	5.1. Truncating TZif Files		5.1. Truncating TZif Files
	As described in Section 3.9 of [RFC7808], a TZDIST service MAY		As described in Section 3.9 of [RFC7808], a TZDIST service MAY
	truncate time zone transition data. A truncated TZif file is valid		truncate time zone transition data. A truncated TZif file is valid
	from its first and up to, but not including, its last version 2+		from its first and up to, but not including, its last version 2+
	transition time, if present.		transition time, if present.
	When truncating the start of a TZif file, the service MUST supply in		When truncating the start of a TZif file, the service MUST supply in
	the version 2+ data a first transition time that is the start point		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		of the truncation range. As with untruncated TZif files, time type 0
	indicates local time immediately before the start point, and the time		indicates local time immediately before the start point, and the time
	type of the first transition indicates local time thereafter. Time		type of the first transition indicates local time thereafter. Time
	type 0 SHOULD be a placeholder indicating that local time is		type 0 SHOULD be a placeholder indicating that local time is
	unspecified.		unspecified.
	When truncating the start of a TZif file containing leap-second		When truncating the start of a TZif file containing leap-second
	records, the service MUST keep all leap-second records governing		records, the service MUST keep all leap-second records governing
	timestamps within the truncation range, even if the first such record		timestamps within the truncation range, even if the first such record
	precedes the start point of the truncation range. If the truncated		precedes the start point of the truncation range. If the truncated
	leap second table is nonempty, its first record MUST have a positive		leap second table is nonempty, its first record MUST have a positive
	correction if and only if it represents a positive leap second.		correction if and only if it represents a positive leap second.
	When truncating the end of a TZif file, the service MUST supply in		When truncating the end of a TZif file, the service MUST supply in
	Skipping		Skipping
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[ZIC] Kerrisk, M., "ZIC(8)", man-pages release 4.16, 25 February		[ZIC] Kerrisk, M., "ZIC(8)", man-pages release 4.16, 25 February
	2010, <http://man7.org/linux/man-pages/man8/zic.8.html>.		2010, <http://man7.org/linux/man-pages/man8/zic.8.html>.
	9.2. Informative References		9.2. Informative References
			[CGPM-2022-R4]
			General Conference on Weights and Measures, "Resolution 4
			of the 27th CGPM (2022)", November 2022,
			<https://www.bipm.org/en/cgpm-2022/resolution-4>.
	[EGGERT-TZ]		[EGGERT-TZ]
	"History for tz", March 2021,		"History for tz", March 2021,
	<https://github.com/eggert/tz/commits/main/tzfile.5>.		<https://github.com/eggert/tz/commits/main/tzfile.5>.
	[Err6426] RFC Errata, "Erratum ID 6426", RFC 8536,		[Err6426] RFC Errata, "Erratum ID 6426", RFC 8536,
	<https://www.rfc-editor.org/errata/eid6426>.		<https://www.rfc-editor.org/errata/eid6426>.
	[Err6435] RFC Errata, "Erratum ID 6435", RFC 8536,		[Err6435] RFC Errata, "Erratum ID 6435", RFC 8536,
	Skipping		Skipping
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8536] Olson, A., Eggert, P., and K. Murchison, "The Time Zone		[RFC8536] Olson, A., Eggert, P., and K. Murchison, "The Time Zone
	Information Format (TZif)", RFC 8536,		Information Format (TZif)", RFC 8536,
	DOI 10.17487/RFC8536, February 2019,		DOI 10.17487/RFC8536, February 2019,
	<https://www.rfc-editor.org/info/rfc8536>.		<https://www.rfc-editor.org/info/rfc8536>.
	[tz-link] Eggert, P. and A.D. Olson, "Sources for Time Zone and		[tz-link] Eggert, P. and A.D. Olson, "Time zone and daylight saving
	Daylight Saving Time Data", 2018,		time data", 2022,
	<https://www.iana.org/time-zones/repository/tz-link.html>.		<https://www.iana.org/time-zones/tz-link.html>.
	Appendix A. Common Interoperability Issues		Appendix A. Common Interoperability Issues
	This section documents common problems in implementing this		This section documents common problems in implementing this
	specification. Most of these are problems in generating TZif files		specification. Most of these are problems in generating TZif files
	for use by readers conforming to predecessors of this specification		for use by readers conforming to predecessors of this specification
	[EGGERT-TZ]. The goals of this section are:		[EGGERT-TZ]. The goals of this section are:
	1. to help TZif writers output files that avoid common pitfalls in		1. to help TZif writers output files that avoid common pitfalls in
	Skipping		Skipping
	* Many readers mishandle time zone abbreviations that contain non-		* Many readers mishandle time zone abbreviations that contain non-
	ASCII characters. These characters are not recommended.		ASCII characters. These characters are not recommended.
	* Some readers may mishandle time zone abbreviations that contain		* Some readers may mishandle time zone abbreviations that contain
	fewer than 3 or more than 6 characters, or that contain ASCII		fewer than 3 or more than 6 characters, or that contain ASCII
	characters other than alphanumerics, '-', and '+'. These		characters other than alphanumerics, '-', and '+'. These
	abbreviations are not recommended.		abbreviations are not recommended.
	* This specification does not dictate how readers should deal with		* This specification does not dictate how readers should deal with
	timestamps when local time is unspecified. Common practice is for		timestamps when local time is unspecified. Common practice is for
	readers to report UT with designation string "-00". A reader		readers to report UT with designation string "-00". A reader
	could return an error indication instead.		could return an error indication instead.
	* Some readers mishandle TZif files that specify daylight saving		* Some readers mishandle TZif files that specify daylight saving
	time UT offsets that are less than the UT offsets for the		time UT offsets that are less than the UT offsets for the
	corresponding standard time. These readers do not support		corresponding standard time. These readers do not support
	locations like Ireland, which uses the equivalent of the POSIX TZ		locations like Ireland, which uses the equivalent of the POSIX TZ
	string "IST-1GMT0,M10.5.0,M3.5.0/1", observing standard time (IST,		string "IST-1GMT0,M10.5.0,M3.5.0/1", observing standard time (IST,
	+01) in summer and daylight saving time (GMT, +00) in winter. As		+01) in summer and daylight saving time (GMT, +00) in winter. As
	a partial workaround, a writer can output data for the equivalent		a partial workaround, a writer can output data for the equivalent
	of the POSIX TZ string "GMT0IST,M3.5.0/1,M10.5.0", thus swapping		of the POSIX TZ string "GMT0IST,M3.5.0/1,M10.5.0", thus swapping
	Skipping		Skipping
	timestamps are likely to be more prone to this problem.		timestamps are likely to be more prone to this problem.
	* Some readers mishandle time zone abbreviations like "-08" that		* Some readers mishandle time zone abbreviations like "-08" that
	contain '+', '-', or digits.		contain '+', '-', or digits.
	* Some readers mishandle UT offsets that are out of the traditional		* Some readers mishandle UT offsets that are out of the traditional
	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.
	* Some readers mishandle UT offsets in the range [-3599, -1] seconds		* 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".
	* Some readers mishandle UT offsets that are not a multiple of one		* Some readers mishandle UT offsets that are not a multiple of one
	hour, 15 minutes, or 1 minute.		hour, 15 minutes, or 1 minute.
	Appendix B. Example TZif Files		Appendix B. Example TZif Files
	The following sections contain annotated hexadecimal dumps of example		The following sections contain annotated hexadecimal dumps of example
	TZif files.		TZif files.
	Note that these examples should only be considered informative.		Note that these examples should only be considered informative.
	Although the example data entries are current as of the publication		Although the example data entries are current as of the publication
	date of this document, the data will likely change in the future as		date of this document, the data will likely change in the future as
	Skipping		Skipping
	Table 1		Table 1
	To determine TAI corresponding to 2000-01-01T00:00:00Z		To determine TAI corresponding to 2000-01-01T00:00:00Z
	(UNIX time = 946684800), the following procedure would be followed:		(UNIX time = 946684800), the following procedure would be followed:
	1. Find the latest leap-second occurrence prior to the time of		1. Find the latest leap-second occurrence prior to the time of
	interest (leapsecond[21]) and note the correction value		interest (leapsecond[21]) and note the correction value
	(LEAPCORR = 22).		(LEAPCORR = 22).
	2. Add LEAPCORR + 10 to the time of interest to yield TAI of		2. Add LEAPCORR + 10 to the time of interest to yield TAI of
	2000-01-01T00:00:32.		2000-01-01T00:00:32.
	B.2. Version 2 File Representing Pacific/Honolulu		B.2. Version 2 File Representing Pacific/Honolulu
	+========+=============+==================+========================+		+========+=============+==================+========================+
	| File | Hexadecimal | Record Name / | Field Value |		| File | Hexadecimal | Record Name / | Field Value |
	| Offset | Octets | Field Name | |		| Offset | Octets | Field Name | |
	+========+=============+==================+========================+		+========+=============+==================+========================+
	| 000 | 54 5a 69 66 | magic | "TZif" |		| 000 | 54 5a 69 66 | magic | "TZif" |
	+--------+-------------+------------------+------------------------+		+--------+-------------+------------------+------------------------+
	Skipping		Skipping
	3. Reference the corresponding local time type (localtimetype[2]) to		3. Reference the corresponding local time type (localtimetype[2]) to
	determine the offset from UTC (-09:30), the daylight saving		determine the offset from UTC (-09:30), the daylight saving
	indicator (1 = yes), and the index into the time zone designation		indicator (1 = yes), and the index into the time zone designation
	strings (8).		strings (8).
	4. Look up the corresponding time zone designation string		4. Look up the corresponding time zone designation string
	(designations[8] = "HDT").		(designations[8] = "HDT").
	5. Add the UTC offset to the time of interest to yield a local		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).		daylight saving time of 1933-05-04T02:30:00-09:30 (HDT).
	To determine the local time in this time zone corresponding to		To determine the local time in this time zone corresponding to
	2019-01-01T00:00:00Z (UNIX time = 1546300800), the following		2019-01-01T00:00:00Z (UNIX time = 1546300800), the following
	procedure would be followed:		procedure would be followed:
	1. Find the latest time transition prior to the time of interest		1. Find the latest time transition prior to the time of interest
	(there is no such transition).		(there is no such transition).
	2. Look up the TZ string in the footer ("HST10"), which indicates		2. Look up the TZ string in the footer ("HST10"), which indicates
	Skipping		Skipping
	The following TZif file has been truncated to start on		The following TZif file has been truncated to start on
	2022-01-01T00:00:00Z.		2022-01-01T00:00:00Z.
	In this example:		In this example:
	* The version 1 header contains only the required minimum data,		* The version 1 header contains only the required minimum data,
	which will be ignored by readers.		which will be ignored by readers.
	* The version 4 header leverages the fact that by specifying		* The version 4 header leverages the fact that by specifying
	'isutcnt' and 'isstdcnt' as zero, all transition times associated		'isutcnt' and 'isstdcnt' as zero, all transition times associated
	with local time types are assumed to be specified as local wall-		with local time types are assumed to be specified as local wall-
	clock time (see the definitions of UT/local indicators and		clock time (see the definitions of UT/local indicators and
	standard/wall indicators in Section 3.2).		standard/wall indicators in Section 3.2).
	* The first leap second occurrence is the most recent one prior to		* The first leap second occurrence is the most recent one prior to
	the truncation time.		the truncation time.
	* The last leap second correction matches the second-to-last leap		* The last leap second correction matches the second-to-last leap
	second correction, indicating the expiration time of the leap		second correction, indicating the expiration time of the leap
	second table.		second table.
	* The TZ string value has been line-wrapped for presentation		* The TZ string value has been line-wrapped for presentation
	Skipping		Skipping
	* Applied erratum [Err6435].		* Applied erratum [Err6435].
	* Addressed errata [Err6426] and [Err6757] as well as several other		* Addressed errata [Err6426] and [Err6757] as well as several other
	errors in the examples.		errors in the examples.
	* Clarified the all-year daylight saving time TZ string		* Clarified the all-year daylight saving time TZ string
	(Section 3.3.1) example and added a similar example with negative		(Section 3.3.1) example and added a similar example with negative
	DST.		DST.
	* Added informational notes to Appendix B.3.		* Added informational notes to Appendix B.3.
	* Miscellaneous editorial changes.		* Miscellaneous editorial changes.
	Appendix D. Change Log		Appendix D. Change Log
	This section is to be removed by RFC Editor before publication.		This section is to be removed by RFC Editor before publication.
	D.1. Since rfc8536bis-05		D.1. Since rfc8536bis-06
			* Moved the specification of an all-year daylight saving time TZ
			string (Section 3.3.1), to its own section as it is NOT an
			extension.
			* Noted that should leap seconds to become discontinued that leap
			second tables SHOULD NOT expire.
			* Updated "tz-link" title and reference.
			D.2. Since rfc8536bis-05
	* Clarified the specification of an all-year daylight saving time TZ		* Clarified the specification of an all-year daylight saving time TZ
	string (Section 3.3.1), and removed the EST5EDT example.		string (Section 3.3.1), and changed the example to use negative
			DST.
	D.2. Since rfc8536bis-04		D.3. Since rfc8536bis-04
	* None.		* None.
	D.3. Since rfc8536bis-03		D.4. Since rfc8536bis-03
	* Noted that erratum [Err6757] has been addressed.		* Noted that erratum [Err6757] has been addressed.
	* Added a definition of Leap-Second, including UTC month.		* Added a definition of Leap-Second, including UTC month.
	D.4. Since rfc8536bis-02		D.5. Since rfc8536bis-02
	* Documented "-00" as meaning unspecified local time.		* Documented "-00" as meaning unspecified local time.
	* Recommended that "-00" be used for timestamps that are unspecified		* Recommended that "-00" be used for timestamps that are unspecified
	due to TZif file truncation.		due to TZif file truncation.
	D.5. Since rfc8536bis-01		D.6. Since rfc8536bis-01
	* Converted source from xml2rfc v2 to v3.		* Converted source from xml2rfc v2 to v3.
	* Properly line-wrapped long TZ string values in examples (with no		* Properly line-wrapped long TZ string values in examples (with no
	added space).		added space).
	* No other substantive changes.		* No other substantive changes.
	D.6. Since rfc8536bis-00		D.7. Since rfc8536bis-00
	* Added specification of the version 4 format and the optional leap		* Added specification of the version 4 format and the optional leap
	second table truncation and expiration, along with an example and		second table truncation and expiration, along with an example and
	relevant interoperability considerations.		relevant interoperability considerations.
	* Specified column widths in example tables.		* Specified column widths in example tables.
	* Noted that long TZ string values in examples are line-wrapped for		* Noted that long TZ string values in examples are line-wrapped for
	presentation purposes only.		presentation purposes only.
	D.7. Since RFC 8536		D.8. Since RFC 8536
	* Applied erratum [Err6435].		* Applied erratum [Err6435].
	* Addressed erratum [Err6426] and several other errors in the		* Addressed erratum [Err6426] and several other errors in the
	examples.		examples.
	* Clarified the specification of an all-year daylight saving time TZ		* Clarified the specification of an all-year daylight saving time TZ
	string (Section 3.3.1), and changed the example to use negative		string (Section 3.3.1), and changed the example to use negative
	DST.		DST.
	Skipping		Skipping
	contributing their ideas and support for writing this specification:		contributing their ideas and support for writing this specification:
	Michael Douglass, Ned Freed, Guy Harris, Eliot Lear, Alexey Melnikov,		Michael Douglass, Ned Freed, Guy Harris, Eliot Lear, Alexey Melnikov,
	and Tim Parenti.		and Tim Parenti.
	Authors' Addresses		Authors' Addresses
	Arthur David Olson		Arthur David Olson
	Email: arthurdavidolson@gmail.com		Email: arthurdavidolson@gmail.com
	Paul Eggert		Paul Eggert
	University of California, Los Angeles		University of California, Los Angeles
	Email: eggert@cs.ucla.edu		Email: eggert@cs.ucla.edu
	Kenneth Murchison		Kenneth Murchison
	Fastmail US LLC		Fastmail US LLC
	Email: murch@fastmailteam.com		Email: murch@fastmailteam.com