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