[PATCH 1/2] Switch from RFC 8536 to 9636 for documentation

RFC 9636 is now published, and it obsoletes RFC 8536 for the Time Zone information format (TZif). --- Makefile | 2 +- NEWS | 4 ++++ localtime.c | 2 +- theory.html | 4 ++-- tz-link.html | 4 ++-- tzfile.5 | 12 ++++++------ tzfile.h | 2 +- zic.c | 4 ++-- 8 files changed, 19 insertions(+), 15 deletions(-) diff --git a/Makefile b/Makefile index 57d1d672..6e623eb0 100644 --- a/Makefile +++ b/Makefile @@ -137,7 +137,7 @@ TIME_T_ALTERNATIVES_TAIL = int_least32_t.ck uint_least32_t.ck \ uint_least64_t.ck # What kind of TZif data files to generate. (TZif is the binary time -# zone data format that zic generates; see Internet RFC 8536.) +# zone data format that zic generates; see Internet RFC 9636.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only diff --git a/NEWS b/NEWS index adaa4b60..8c315643 100644 --- a/NEWS +++ b/NEWS @@ -24,6 +24,10 @@ Unreleased, experimental changes 1977, and May and July 1990; and removing incorrect transitions in March and September 1978. + Changes to documentation + + Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format. + Release 2024b - 2024-09-04 12:27:47 -0700 diff --git a/localtime.c b/localtime.c index 7ae9ce5e..f331473e 100644 --- a/localtime.c +++ b/localtime.c @@ -583,7 +583,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, correction must differ from the previous one's by 1 second or less, except that the first correction can be any value; these requirements are more generous than - RFC 8536, to allow future RFC extensions. */ + RFC 9636, to allow future RFC extensions. */ if (! (i == 0 || (prevcorr < corr ? corr == prevcorr + 1 diff --git a/theory.html b/theory.html index b1717e7d..4d72ee2e 100644 --- a/theory.html +++ b/theory.html @@ -1115,8 +1115,8 @@ However POSIX.1-2024, like earlier POSIX editions, has some limitations: the name of a file from which time-related information is read. The file's format is <dfn><abbr>TZif</abbr></dfn>, a timezone information format that contains binary data; see - <a href="https://datatracker.ietf.org/doc/html/8536">Internet - <abbr>RFC</abbr> 8536</a>. + <a href="https://datatracker.ietf.org/doc/html/9636">Internet + <abbr>RFC</abbr> 9636</a>. The daylight saving time rules to be used for a particular timezone are encoded in the <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, diff --git a/tz-link.html b/tz-link.html index be2aae54..0853bd7d 100644 --- a/tz-link.html +++ b/tz-link.html @@ -194,9 +194,9 @@ After obtaining the code and data files, see the The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files are in a special format specified by -<a href="https://datatracker.ietf.org/doc/html/8536">The +<a href="https://datatracker.ietf.org/doc/html/9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> -(Internet <abbr title="Request For Comments">RFC</abbr> 8536). +(Internet <abbr title="Request For Comments">RFC</abbr> 9636). The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> diff --git a/tzfile.5 b/tzfile.5 index f2529b01..b699bd26 100644 --- a/tzfile.5 +++ b/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), @@ -380,7 +380,7 @@ 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 end in expiration times. .IP \(bu Some readers ignore the footer, and instead predict future @@ -514,9 +514,9 @@ of one hour, or of 15 minutes, or of 1 minute. .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 +.UR https://\:datatracker.ietf.org/\:doc/\:html/\: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 . diff --git a/tzfile.h b/tzfile.h index b1541466..f8c6c8c5 100644 --- a/tzfile.h +++ b/tzfile.h @@ -26,7 +26,7 @@ #endif /* !defined TZDEFRULES */ -/* See Internet RFC 8536 for more details about the following format. */ +/* See Internet RFC 9636 for more details about the following format. */ /* ** Each file begins with. . . diff --git a/zic.c b/zic.c index cf8e79df..6da35270 100644 --- a/zic.c +++ b/zic.c @@ -2761,7 +2761,7 @@ writezone(const char *const name, const char *const string, char version, if (thisleapexpiry) { /* Append a no-op leap correction indicating when the leap second table expires. Although this does not conform to - Internet RFC 8536, most clients seem to accept this and + Internet RFC 9636, most clients seem to accept this and the plan is to amend the RFC to allow this in version 4 TZif files. */ puttzcodepass(leapexpires, fp, pass); @@ -3007,7 +3007,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) result[0] = '\0'; - /* Internet RFC 8536 section 5.1 says to use an empty TZ string if + /* Internet RFC 9636 section 6.1 says to use an empty TZ string if future timestamps are truncated. */ if (hi_time < max_time) return -1; -- 2.43.0

In documentation, prefer URLs like <https://www.rfc-editor.org/rfc/rfc3339> to URLs like <https://datatracker.ietf.org/doc/html/rfc3339>, as they’re shorter and more commonly used elsewhere. I think I used the longer form back when the shorter form was dicey with http: but nowadays https: works fine. --- theory.html | 6 +++--- tz-link.html | 24 ++++++++++++------------ tzfile.5 | 4 ++-- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/theory.html b/theory.html index 4d72ee2e..f4b3dfa3 100644 --- a/theory.html +++ b/theory.html @@ -579,10 +579,10 @@ in decreasing order of importance: locations while uninhabited. The leading '<code>-</code>' is a flag that the <abbr>UT</abbr> offset is in some sense undefined; this notation is derived - from <a href="https://datatracker.ietf.org/doc/html/rfc3339">Internet + from <a href="https://www.rfc-editor.org/rfc/rfc3339">Internet <abbr title="Request For Comments">RFC</abbr> 3339</a>. (The abbreviation 'Z' that - <a href="https://datatracker.ietf.org/doc/html/rfc9557">Internet + <a href="https://www.rfc-editor.org/rfc/rfc9557">Internet <abbr>RFC</abbr> 9557</a> uses for this concept would violate the POSIX requirement of at least three characters in an abbreviation.) @@ -1115,7 +1115,7 @@ However POSIX.1-2024, like earlier POSIX editions, has some limitations: the name of a file from which time-related information is read. The file's format is <dfn><abbr>TZif</abbr></dfn>, a timezone information format that contains binary data; see - <a href="https://datatracker.ietf.org/doc/html/9636">Internet + <a href="https://www.rfc-editor.org/rfc/9636">Internet <abbr>RFC</abbr> 9636</a>. The daylight saving time rules to be used for a particular timezone are encoded in the diff --git a/tz-link.html b/tz-link.html index 0853bd7d..bb16bd4e 100644 --- a/tz-link.html +++ b/tz-link.html @@ -194,7 +194,7 @@ After obtaining the code and data files, see the The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files are in a special format specified by -<a href="https://datatracker.ietf.org/doc/html/9636">The +<a href="https://www.rfc-editor.org/rfc/9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> (Internet <abbr title="Request For Comments">RFC</abbr> 9636). The code also lets @@ -260,7 +260,7 @@ Studio Code</a>. </p> <p> For further information about updates, please see -<a href="https://datatracker.ietf.org/doc/html/rfc6557">Procedures for +<a href="https://www.rfc-editor.org/rfc/rfc6557">Procedures for Maintaining the Time Zone Database</a> (Internet <abbr>RFC</abbr> 6557). More detail can be found in <a href="theory.html">Theory and pragmatics of the @@ -379,26 +379,26 @@ calculates the current time difference between locations.</li> <li>The <a href="https://www.ietf.org">Internet Engineering Task Force</a>'s <a href="https://datatracker.ietf.org/wg/tzdist/charter/">Time Zone Data Distribution Service (tzdist) working group</a> defined <a -href="https://datatracker.ietf.org/doc/html/rfc7808">TZDIST</a> +href="https://www.rfc-editor.org/rfc/rfc7808">TZDIST</a> (Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, -along with <a href="https://datatracker.ietf.org/doc/html/rfc7809">CalDAV</a> +along with <a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. <a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST implementations</a> are available. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis mailing list</a> discusses possible extensions.</li> -<li>The <a href="https://datatracker.ietf.org/doc/html/rfc5545"> +<li>The <a href="https://www.rfc-editor.org/rfc/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) covers time zone data; see its VTIMEZONE calendar component. The iCalendar format requires specialized parsers and generators; a -variant <a href="https://datatracker.ietf.org/doc/html/rfc6321">xCal</a> +variant <a href="https://www.rfc-editor.org/rfc/rfc6321">xCal</a> (Internet <abbr>RFC</abbr> 6321) uses <a href="https://www.w3.org/XML/"><abbr title="Extensible Markup Language">XML</abbr></a> format, and a variant -<a href="https://datatracker.ietf.org/doc/html/rfc7265">jCal</a> +<a href="https://www.rfc-editor.org/rfc/rfc7265">jCal</a> (Internet <abbr>RFC</abbr> 7265) uses <a href="https://www.json.org/json-en.html"><abbr title="JavaScript Object Notation">JSON</abbr></a> format.</li> @@ -1023,7 +1023,7 @@ title="Institute of Electrical and Electronics Engineers">IEEE</abbr> 1588) can achieve submicrosecond clock accuracy on a local area network with special-purpose hardware.</li> <li><a -href="https://datatracker.ietf.org/doc/html/rfc4833">Timezone +href="https://www.rfc-editor.org/rfc/rfc4833">Timezone Options for <abbr title="Dynamic Host Configuration Protocol">DHCP</abbr></a> (Internet <abbr>RFC</abbr> 4833) specifies a <a @@ -1105,7 +1105,7 @@ the abovementioned <abbr>NTP</abbr> implementations, <a href="https://github.com/google/unsmear">supports</a> conversion between <abbr>UTC</abbr> and smeared <abbr>POSIX</abbr> timestamps, and is used by major cloud service providers. However, according to -<a href="https://datatracker.ietf.org/doc/html/rfc8633#section-3.7.1">§3.7.1 of +<a href="https://www.rfc-editor.org/rfc/rfc8633#section-3.7.1">§3.7.1 of Network Time Protocol Best Current Practices</a> (Internet <abbr>RFC</abbr> 8633), leap smearing is not suitable for applications requiring accurate <abbr>UTC</abbr> or civil time, @@ -1165,16 +1165,16 @@ interchange – Part 1: Basic rules</em></a>.</li> <a href="https://www.w3.org/TR/xmlschema/#dateTime"><abbr>XML</abbr> Schema: Datatypes – dateTime</a> specifies a format inspired by <abbr>ISO</abbr> 8601 that is in common use in <abbr>XML</abbr> data.</li> -<li><a href="https://datatracker.ietf.org/doc/html/rfc5322#section-3.3">§3.3 of +<li><a href="https://www.rfc-editor.org/rfc/rfc5322#section-3.3">§3.3 of Internet Message Format</a> (Internet <abbr>RFC</abbr> 5322) specifies the time notation used in email and <a href="https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol"><abbr>HTTP</abbr></a> headers.</li> <li> -<a href="https://datatracker.ietf.org/doc/html/rfc3339">Date and Time +<a href="https://www.rfc-editor.org/rfc/rfc3339">Date and Time on the Internet: Timestamps</a> (Internet <abbr>RFC</abbr> 3339) specifies an <abbr>ISO</abbr> 8601 profile for use in new Internet protocols. -An extension, <a href="https://datatracker.ietf.org/doc/html/rfc9557">Date +An extension, <a href="https://www.rfc-editor.org/rfc/rfc9557">Date and Time on the Internet: Timestamps with Additional Information</a> (Internet <abbr>RFC</abbr> 9557) extends this profile to let you specify the <code><abbr>tzdb</abbr></code> timezone of a timestamp diff --git a/tzfile.5 b/tzfile.5 index b699bd26..34b994cc 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -513,8 +513,8 @@ 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/\:rfc9636 +October 2024. +.UR https://\:www.rfc-editor.org/\:rfc/\:rfc9636 Internet RFC 9636 .UE .UR https://\:doi.org/\:10.17487/\:RFC9636 -- 2.43.0
participants (1)
-
Paul Eggert