Hi Brian, On Sun, Jan 26, 2025 at 01:10:44PM -0700, Brian Inglis wrote: > 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 AFAIR, this page was pristine from upstream. Did you need to do any changes? I think I would prefer importing the page pristine, so that we don't need to worry about the differences. Have a lovely day! Alex > > 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 > -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
