update from upstream https://github.com/eggert/tz/blob/main/tzfile.5: Internet RFC 8536 -> 9636 and refs; POSIX.1-2017 -> POSIX.1-2024 et al; prefix non-... should be hyphenated and add commas between clauses for easier reading for international audience; add proleptic before TZ or POSIX TZ; try to merge upstream and man-pages styles Signed-off-by: Brian Inglis <Brian.Inglis@xxxxxxxxxxxxxxxxxx> --- man/man5/tzfile.5 | 78 ++++++++++++++++++++++++++++------------------- 1 file changed, 46 insertions(+), 32 deletions(-) diff --git a/man/man5/tzfile.5 b/man/man5/tzfile.5 index 4aa3f6c28c15..8682ac118bdb 100644 --- a/man/man5/tzfile.5 +++ b/man/man5/tzfile.5 @@ -17,7 +17,7 @@ The timezone information files used by .BR tzset (3) are typically found under a directory with a name like .IR /usr/share/zoneinfo . -These files use the format described in Internet RFC 8536. +These files use the format described in Internet RFC 9636. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), @@ -86,7 +86,7 @@ described in the file is associated with the time period starting with the same-indexed transition time and continuing up to but not including the next transition time. (The last time type is present only for consistency checking with the -POSIX.1-2017-style TZ string described below.) +proleptic POSIX.1-2024-style TZ string described below.) These values serve as indices into the next field. .IP \(bu .B tzh_typecnt @@ -146,7 +146,7 @@ The encoding of these strings is not specified. .IP \(bu .B tzh_leapcnt pairs of four-byte values, written in network byte order; -the first value of each pair gives the nonnegative time +the first value of each pair gives the non-negative time (as returned by .BR time (2)) at which a leap second occurs or at which the leap second table expires; @@ -159,7 +159,7 @@ Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. -The first leap second has a nonnegative occurrence time, +The first leap second has a non-negative occurrence time, and is a positive leap second if and only if its correction is positive; the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, @@ -187,12 +187,12 @@ must also be set. The standard/wall and UT/local indicators were designed for transforming a TZif file's transition times into transitions appropriate for another time zone specified via -a POSIX.1-2017-style TZ string that lacks rules. +a proleptic POSIX.1-2024-style TZ string that lacks rules. For example, when TZ="EET\*-2EEST" and there is no TZif file "EET\*-2EEST", the idea was to adapt the transition times from a TZif file with the well-known name "posixrules" that is present only for this purpose and is a copy of the file "Europe/Brussels", a file with a different UT offset. -POSIX does not specify this obsolete transformational behavior, +POSIX does not specify the details of this obsolete transformational behavior, the default rules are installation-dependent, and no implementation is known to support this feature for timestamps past 2037, so users desiring (say) Greek time should instead specify @@ -217,13 +217,13 @@ identical in format except that eight bytes are used for each transition time or leap second time. (Leap second counts remain four bytes.) After the second header and data comes a newline-enclosed string -in the style of the contents of a POSIX.1-2017 TZ environment variable, +in the style of the contents of a proleptic TZ, for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The TZ string is empty (i.e., nothing between the newlines) -if there is no POSIX.1-2017-style representation for such instants. -If nonempty, the TZ string must agree with the local time +if there is no proleptic representation for such instants. +If non-empty, the TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string .q "WET0WEST,M3.5.0/1,M10.5.0" @@ -235,13 +235,14 @@ Also, if there is at least one transition, time type 0 is associated with the time period from the indefinite past up to but not including the earliest transition time. .SS Version 3 format -For version-3-format timezone files, the TZ string may -use two minor extensions to the POSIX.1-2017 TZ format, as described in -.BR newtzset (3). -First, the hours part of its transition times may be signed and range from -\-167 through 167 instead of the POSIX-required unsigned values +For version-3-format timezone files, a TZ string (see +.BR newtzset (3)) +may use the following POSIX.1-2024 extensions to POSIX.1-2017: +First, as in TZ="<\-02>2<\-01>,M3.5.0/\-1,M10.5.0/0", +the hours part of its transition times may be signed and range from +\-167 through 167 instead of being limited to the POSIX.1-2024-required unsigned values from 0 through 24. -Second, DST is in effect all year if it starts +Second, as in TZ="XXX3EDT4,0/0,J365/23", DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .SS Version 4 format @@ -317,16 +318,16 @@ through 60 instead of the usual 59; the UTC offset is unaffected. This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by older readers. -The goals of this section are: +The goals of this section are to help: .RS 2 .IP \(bu 3 -to help TZif writers output files that avoid common +TZif writers output files that avoid common pitfalls in older or buggy TZif readers, .IP \(bu -to help TZif readers avoid common pitfalls when reading +TZif readers avoid common pitfalls when reading files generated by future TZif writers, and .IP \(bu -to help any future specification authors see what sort of +any future specification authors see what sort of problems arise when the TZif format is changed. .RE .PP @@ -337,9 +338,9 @@ reader was designed for. When complete compatibility was not achieved, an attempt was made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate -new-version data useful even for older-version readers. +newer-version data useful even for older-version readers. This section attempts to document these compatibility issues and -workarounds, as well as to document other common bugs in +workarounds as well as documenting other common bugs in readers. .PP Interoperability problems with TZif include the following: @@ -354,7 +355,8 @@ version 2+ data even if the reader's native timestamps have only .IP \(bu Some readers designed for version 2 might mishandle timestamps after a version 3 or higher file's last transition, because -they cannot parse extensions to POSIX.1-2017 in the TZ-like string. +they cannot parse the POSIX.1-2024 extensions to POSIX.1-2017 +in the proleptic TZ string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers. @@ -371,14 +373,14 @@ for two time zones east, e.g., for a time zone with a never-used standard time (XXX, \-03) and negative daylight saving time (EDT, \-04) all year. Alternatively, -as a partial workaround a writer can substitute standard time +as a partial workaround, a writer can substitute standard time for the next time zone east \(en e.g., .q "AST4" for permanent Atlantic Standard Time (\-04). .IP \(bu Some readers designed for version 2 or 3, and that require strict -conformance to RFC 8536, reject version 4 files whose leap second +conformance to RFC 9636, reject version 4 files whose leap second tables are truncated at the start or that end in expiration times. .IP \(bu Some readers ignore the footer, and instead predict future @@ -386,6 +388,18 @@ timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions than necessary. .IP \(bu +Some stripped-down readers ignore everything but the footer, +and use its proleptic TZ string to calculate all timestamps. +Although this approach often works for current and future timestamps, +it obviously has problems with past timestamps, +and even for current timestamps it can fail for settings like +TZ="Africa/Casablanca". This corresponds to a TZif file +containing explicit transitions through the year 2087, +followed by a footer containing the TZ string +.q <+01>\-1 , +which should be used only for timestamps after the last +explicit transition. +.IP \(bu Some readers do not use time type 0 for timestamps before the first transition, in that they infer a time type using a heuristic that does not always select time type 0. @@ -393,7 +407,7 @@ As a partial workaround, a writer can output a dummy (no-op) first transition at an early time. .IP \(bu Some readers mishandle timestamps before the first -transition that has a timestamp not less than \-2**31. +transition that has a timestamp that is not less than \-2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 @@ -405,7 +419,7 @@ Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. Timestamps less than \-2**59 are not recommended. .IP \(bu -Some readers mishandle TZ strings that +Some readers mishandle proleptic TZ strings that contain .q "<" or @@ -466,7 +480,7 @@ Developers of distributed applications should keep this in mind if they need to deal with pre-1970 data. .IP \(bu Some readers mishandle timestamps before the first -transition that has a nonnegative timestamp. +transition that has a non-negative timestamp. Readers that do not support negative timestamps are likely to be more prone to this problem. .IP \(bu @@ -499,10 +513,10 @@ of one hour, or of 15 minutes, or of 1 minute. .BR zic (8). .PP Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). -2019 Feb. -.UR https://\:datatracker.ietf.org/\:doc/\:html/\:rfc8536 -Internet RFC 8536 +October 2024. +.UR https://\:www.rfc-editor.org/\:rfc/\:rfc9636 +Internet RFC 9636 .UE -.UR https://\:doi.org/\:10.17487/\:RFC8536 -doi:10.17487/RFC8536 +.UR https://\:doi.org/\:10.17487/\:RFC9636 +doi:10.17487/RFC9636 .UE . -- 2.45.1
