diff options
Diffstat (limited to 'theory.html')
| -rw-r--r-- | theory.html | 214 |
1 files changed, 143 insertions, 71 deletions
diff --git a/theory.html b/theory.html index 516d2a525111..d3573ede0dfb 100644 --- a/theory.html +++ b/theory.html @@ -89,13 +89,15 @@ The <code><abbr>tz</abbr></code> code is upwards compatible with <a href="https://en.wikipedia.org/wiki/POSIX">POSIX</a>, an international standard for <a href="https://en.wikipedia.org/wiki/Unix">UNIX</a>-like systems. -As of this writing, the current edition of POSIX is: <a +As of this writing, the current edition of POSIX is POSIX.1-2024, +which has been published but not yet in HTML form. +Unlike its predecessor POSIX.1-2017 (<a href="https://pubs.opengroup.org/onlinepubs/9699919799/"> The Open Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2017, 2018 -Edition. -Because the database's scope encompasses real-world changes to civil -timekeeping, its model for describing time is more complex than the -standard and daylight saving times supported by POSIX.1-2017. +Edition), POSIX.1-2024 requires support for the +<code><abbr>tz</abbr></code> database, which has a +model for describing civil time that is more complex than the +standard and daylight saving times required by POSIX.1-2017. A <code><abbr>tz</abbr></code> timezone corresponds to a ruleset that can have more than two changes per year, these changes need not merely flip back and forth between two alternatives, and the rules themselves @@ -159,7 +161,7 @@ among the following goals: </ul> <p> -Names normally have the form +Names normally have the format <var>AREA</var><code>/</code><var>LOCATION</var>, where <var>AREA</var> is a continent or ocean, and <var>LOCATION</var> is a specific location within the area. @@ -187,7 +189,7 @@ in decreasing order of importance: href="https://en.wikipedia.org/wiki/ASCII">ASCII</a> letters, '<code>.</code>', '<code>-</code>' and '<code>_</code>'. Do not use digits, as that might create an ambiguity with <a - href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX.1-2017 + href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX's proleptic <code>TZ</code> strings</a>. A file name component must not exceed 14 characters or start with '<code>-</code>'. @@ -378,7 +380,8 @@ nowadays distributions typically use it and no great weight should be attached to whether a link is defined in <code>backward</code> or in some other file. The source file <code>etcetera</code> defines names that may be useful -on platforms that do not support POSIX.1-2017-style <code>TZ</code> strings; +on platforms that do not support proleptic <code>TZ</code> strings +like <code><+08>-8</code>; no other source file other than <code>backward</code> contains links to its zones. One of <code>etcetera</code>'s names is <code>Etc/UTC</code>, @@ -425,8 +428,8 @@ in decreasing order of importance: In other words, in the C locale the POSIX extended regular expression <code>[-+[:alnum:]]{3,6}</code> should match the abbreviation. - This guarantees that all abbreviations could have been specified by a - POSIX.1-2017 <code>TZ</code> string. + This guarantees that all abbreviations could have been specified + explicitly by a POSIX proleptic <code>TZ</code> string. </p> </li> <li> @@ -578,6 +581,11 @@ in decreasing order of importance: some sense undefined; this notation is derived from <a href="https://datatracker.ietf.org/doc/html/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 + <abbr>RFC</abbr> 9557</a> uses for this concept + would violate the POSIX requirement + of at least three characters in an abbreviation.) </li> </ul> @@ -775,7 +783,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes the Western 06:00 to be 12:00. These practices are largely outside the scope of the <code><abbr>tz</abbr></code> code and data, which provide only limited support for date and time localization - such as that required by POSIX.1-2017. + such as that required by POSIX. If <abbr>DST</abbr> is not used a different time zone can often do the trick; for example, in Kenya a <code>TZ</code> setting like <code><-03>3</code> or <code>America/Cayenne</code> starts @@ -866,29 +874,62 @@ Code compatible with this package is already <a href="tz-link.html#tzdb">part of many platforms</a>, where the primary use of this package is to update obsolete time-related files. To do this, you may need to compile the time zone compiler -'<code>zic</code>' supplied with this package instead of using the -system '<code>zic</code>', since the format of <code>zic</code>'s +<code>zic</code> supplied with this package instead of using the +system <code>zic</code>, since the format of <code>zic</code>'s input is occasionally extended, and a platform may still be shipping an older <code>zic</code>. </p> -<h3 id="POSIX">POSIX.1-2017 properties and limitations</h3> +<p> +In POSIX, time display in a process is controlled by the +environment variable <code>TZ</code>, which can have two forms: +</p> <ul> <li> + A <dfn>proleptic <code>TZ</code></dfn> value + like <code>CET-1CEST,M3.5.0,M10.5.0/3</code> uses a complex + notation that specifies a single standard time along with daylight + saving rules that apply to all years past, present, and future. + </li> + <li> + A <dfn>geographical <code>TZ</code></dfn> value + like <code>Europe/Berlin</code> names a location that stands for + civil time near that location, which can have more than + one standard time and more than one set of daylight saving rules, + to record timekeeping practice more accurately. + These names are defined by the <code><abbr>tz</abbr></code> database. + </li> +</ul> + +<h3 id="POSIX.1-2017">POSIX.1-2017 properties and limitations</h3> +<p> +Some platforms support only the features required by POSIX.1-2017, +and have not yet upgraded to POSIX.1-2024. +Code intended to be portable to these platforms must deal +with problems that were fixed in later POSIX editions. +</p> + +<ul> + <li> + POSIX.1-2017 does not require support for geographical <code>TZ</code>, + and there is no convenient and efficient way to determine + the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary + timestamps, particularly for timezones + that do not fit into the POSIX model. + </li> + <li> <p> - In POSIX.1-2017, time display in a process is controlled by the - environment variable <code>TZ</code>. - Unfortunately, the POSIX.1-2017 - <code>TZ</code> string takes a form that is hard to describe and - is error-prone in practice. - Also, POSIX.1-2017 <code>TZ</code> strings cannot deal with daylight + The proleptic <code>TZ</code> string, + which is all that POSIX.1-2017 requires, + has a format that is hard to describe and is error-prone in practice. + Also, proleptic <code>TZ</code> strings cannot deal with daylight saving time rules not based on the Gregorian calendar (as in Morocco), or with situations where more than two time zone abbreviations or <abbr>UT</abbr> offsets are used in an area. </p> <p> - The POSIX.1-2017 <code>TZ</code> string takes the following form: + A proleptic <code>TZ</code> string has the following format: </p> <p> @@ -955,7 +996,7 @@ an older <code>zic</code>. </dl> <p> - Here is an example POSIX.1-2017 <code>TZ</code> string for New + Here is an example proleptic <code>TZ</code> string for New Zealand after 2007. It says that standard time (<abbr>NZST</abbr>) is 12 hours ahead of <abbr>UT</abbr>, and that daylight saving time @@ -966,26 +1007,46 @@ an older <code>zic</code>. <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre> <p> - This POSIX.1-2017 <code>TZ</code> string is hard to remember, and + This proleptic <code>TZ</code> string is hard to remember, and mishandles some timestamps before 2008. - With this package you can use this instead: + With this package you can use a geographical <code>TZ</code> instead: </p> <pre><code>TZ='Pacific/Auckland'</code></pre> </li> +</ul> + +<p> +POSIX.1-2017 also has the limitations of POSIX.1-2024, +discussed in the next section. +</p> + +<h3 id="POSIX.1-2024">POSIX.1-2024 properties and limitations</h3> +<p> +POSIX.1-2024 extends POSIX.1-2017 in the following significant ways: +</p> +<ul> <li> - POSIX does not define the <abbr>DST</abbr> transitions - for <code>TZ</code> values like - "<code>EST5EDT</code>". - Traditionally the current <abbr>US</abbr> <abbr>DST</abbr> rules - were used to interpret such values, but this meant that the - <abbr>US</abbr> <abbr>DST</abbr> rules were compiled into each - time conversion package, and when - <abbr>US</abbr> time conversion rules changed (as in the United - States in 1987 and again in 2007), all packages that - interpreted <code>TZ</code> values had to be updated - to ensure proper results. + POSIX.1-2024 requires support for geographical <code>TZ</code>. + Earlier POSIX editions require support only for proleptic <code>TZ</code>. + </li> + <li> + POSIX.1-2024 requires <code>struct tm</code> + to have a <abbr>UT</abbr> offset member <code>tm_gmtoff</code> + and a time zone abbreviation member <code>tm_zone</code>. + Earlier POSIX editions lack this requirement. + </li> + <li> + DST transition times can range from −167:59:59 + to 167:59:59 instead of merely from 00:00:00 to 24:59:59. + This allows for proleptic TZ strings + like <code>"<-02>2<-01>,M3.5.0/-1,M10.5.0/0"</code> + where the transition time −1:00 means 23:00 the previous day. </li> +</ul> +<p> +However POSIX.1-2024, like earlier POSIX editions, has some limitations: +<ul> <li> The <code>TZ</code> environment variable is process-global, which makes it hard to write efficient, thread-safe applications that @@ -1004,16 +1065,34 @@ an older <code>zic</code>. limit phone calls to off-peak hours. </li> <li> - POSIX.1-2017 provides no convenient and efficient way to determine - the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary - timestamps, particularly for timezones - that do not fit into the POSIX model. - </li> - <li> POSIX requires that <code>time_t</code> clock counts exclude leap seconds. </li> <li> + POSIX does not define the <abbr>DST</abbr> transitions + for <code>TZ</code> values like + "<code>EST5EDT</code>". + Traditionally the current <abbr>US</abbr> <abbr>DST</abbr> rules + were used to interpret such values, but this meant that the + <abbr>US</abbr> <abbr>DST</abbr> rules were compiled into each + time conversion package, and when + <abbr>US</abbr> time conversion rules changed (as in the United + States in 1987 and again in 2007), all packages that + interpreted <code>TZ</code> values had to be updated + to ensure proper results. + </li> +</ul> + +<h3 id="POSIX-extensions">Extensions to POSIX in the +<code><abbr>tz</abbr></code> code</h3> +<p> + The <code><abbr>tz</abbr></code> code defines some properties + left unspecified by POSIX, and attempts to support some + extensions to POSIX. +</p> + +<ul> + <li> The <code><abbr>tz</abbr></code> code attempts to support all the <code>time_t</code> implementations allowed by POSIX. The <code>time_t</code> type represents a nonnegative count of seconds @@ -1026,21 +1105,14 @@ an older <code>zic</code>. and 40-bit integers are also used occasionally. Although earlier POSIX versions allowed <code>time_t</code> to be a floating-point type, this was not supported by any practical system, - and POSIX.1-2013 and the <code><abbr>tz</abbr></code> code both + and POSIX.1-2013+ and the <code><abbr>tz</abbr></code> code both require <code>time_t</code> to be an integer type. </li> -</ul> - -<h3 id="POSIX-extensions">Extensions to POSIX.1-2017 in the -<code><abbr>tz</abbr></code> code</h3> -<ul> <li> <p> - The <code>TZ</code> environment variable is used in generating - the name of a file from which time-related information is read - (or is interpreted à la POSIX.1-2017); <code>TZ</code> is no longer - constrained to be a string containing abbreviations - and numeric data as described <a href="#POSIX">above</a>. + If the <code>TZ</code> environment variable uses the geographical format, + it is used in generating + 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 @@ -1053,10 +1125,11 @@ an older <code>zic</code>. abbreviations are used. </p> <p> - It was recognized that allowing the <code>TZ</code> environment + When the <code><abbr>tz</abbr></code> code was developed in the 1980s, + it was recognized that allowing the <code>TZ</code> environment variable to take on values such as '<code>America/New_York</code>' might cause "old" programs (that expect <code>TZ</code> to have a - certain form) to operate incorrectly; consideration was given to using + certain format) to operate incorrectly; consideration was given to using some other environment variable (for example, <code>TIMEZONE</code>) to hold the string used to generate the <abbr>TZif</abbr> file's name. In the end, however, it was decided to continue using @@ -1070,15 +1143,6 @@ an older <code>zic</code>. </p> </li> <li> - The code supports platforms with a <abbr>UT</abbr> offset member - in <code>struct tm</code>, e.g., <code>tm_gmtoff</code>, - or with a time zone abbreviation member in - <code>struct tm</code>, e.g., <code>tm_zone</code>. As noted - in <a href="https://austingroupbugs.net/view.php?id=1533">Austin - Group defect 1533</a>, a future version of POSIX is planned to - require <code>tm_gmtoff</code> and <code>tm_zone</code>. - </li> - <li> Functions <code>tzalloc</code>, <code>tzfree</code>, <code>localtime_rz</code>, and <code>mktime_z</code> for more-efficient thread-safe applications that need to use multiple @@ -1088,7 +1152,7 @@ an older <code>zic</code>. and <code>localtime_rz</code> and <code>mktime_z</code> are like <code>localtime_r</code> and <code>mktime</code> with an extra <code>timezone_t</code> argument. - The functions were inspired by <a href="https://netbsd.org/">NetBSD</a>. + The functions were inspired by <a href="https://netbsd.org">NetBSD</a>. </li> <li> Negative <code>time_t</code> values are supported, on systems @@ -1116,6 +1180,7 @@ The vestigial <abbr>API</abbr>s are: <li> The POSIX <code>tzname</code> variable does not suffice and is no longer needed. + It is planned to be removed in a future edition of POSIX. To get a timestamp's time zone abbreviation, consult the <code>tm_zone</code> member if available; otherwise, use <code>strftime</code>'s <code>"%Z"</code> conversion @@ -1124,6 +1189,7 @@ The vestigial <abbr>API</abbr>s are: <li> The POSIX <code>daylight</code> and <code>timezone</code> variables do not suffice and are no longer needed. + They are planned to be removed in a future edition of POSIX. To get a timestamp's <abbr>UT</abbr> offset, consult the <code>tm_gmtoff</code> member if available; otherwise, subtract values returned by <code>localtime</code> @@ -1278,13 +1344,13 @@ between now and the future time. <p> Leap seconds were introduced in 1972 to accommodate the difference between atomic time and the less regular rotation of the earth. -Unfortunately they caused so many problems with civil -timekeeping that they -are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned -to be discontinued by 2035</a>, with some as-yet-undetermined -mechanism replacing them, perhaps after the year 2135. -Despite their impending obsolescence, a record of leap seconds is still -needed to resolve timestamps from 1972 through 2035. +Unfortunately they have caused so many problems with civil +timekeeping that there are +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">plans +to discontinue them by 2035</a>. +Even if these plans come to fruition, a record of leap seconds will still be +needed to resolve timestamps from 1972 through 2035, +and there may also be a need to record whatever mechanism replaces them. </p> <p> @@ -1374,6 +1440,12 @@ href='https://www.esa.int/Applications/Navigation/Telling_time_on_the_Moon'>cons the establishment of a reference timescale for the Moon, which has days roughly equivalent to 29.5 Earth days, and where relativistic effects cause clocks to tick slightly faster than on Earth. +Also, <abbr title="National Aeronautics and Space Administration">NASA</abbr> +has been <a +href='https://www.whitehouse.gov/wp-content/uploads/2024/04/Celestial-Time-Standardization-Policy.pdf'>ordered</a> +to consider the establishment of Coordinated Lunar Time (<abbr>LTC</abbr>). +It is not yet known whether the US and European efforts will result in +multiple timescales on the Moon. </p> <p> |