Permalink
Browse files

Clarify that EST5EDT is problematic in POSIX

* theory.html: Don’t imply that EST5EDT is an OK POSIX TZ string,
as POSIX does not specify the DST transitions in this case.
Use past tense to describe the typical pre-POSIX behavior.
Minor copyediting.
  • Loading branch information...
eggert committed May 21, 2018
1 parent 33e4575 commit f7cef15920aa7ef2094dfd742c7fd54564046c8a
Showing with 15 additions and 15 deletions.
  1. +15 −15 theory.html
View
@@ -874,15 +874,15 @@ <h3 id="POSIX">POSIX properties and limitations</h3>
<pre><code>TZ='Pacific/Auckland'</code></pre>
</li>
<li>
- POSIX does not define the exact meaning of <code>TZ</code> values like
+ POSIX does not define the <abbr>DST</abbr> transitions
+ for <code>TZ</code> values like
"<code>EST5EDT</code>".
- Typically the current <abbr>US</abbr> <abbr>DST</abbr> rules
- are used to interpret such values, but this means that the
- <abbr>US</abbr> <abbr>DST</abbr> rules are compiled into each
- program that does time conversion.
- This means that when
- <abbr>US</abbr> time conversion rules change (as in the United
- States in 1987), all programs that do time conversion must be
+ 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
+ program that did time conversion. This meant that when
+ <abbr>US</abbr> time conversion rules changed (as in the United
+ States in 1987), all programs that did time conversion had to be
recompiled to ensure proper results.
</li>
<li>
@@ -893,14 +893,14 @@ <h3 id="POSIX">POSIX properties and limitations</h3>
<li>
In POSIX, there is no tamper-proof way for a process to learn the
system's best idea of local wall clock.
- (This is important for applications that an administrator wants
+ This is important for applications that an administrator wants
used only at certain times &ndash; without regard to whether the
user has fiddled the
<code>TZ</code> environment variable.
While an administrator can "do everything in <abbr>UT</abbr>" to
get around the problem, doing so is inconvenient and precludes
- handling daylight saving time shifts - as might be required to
- limit phone calls to off-peak hours.)
+ handling daylight saving time shifts &ndash; as might be required to
+ limit phone calls to off-peak hours.
</li>
<li>
POSIX provides no convenient and efficient way to determine
@@ -923,7 +923,7 @@ <h3 id="POSIX">POSIX properties and limitations</h3>
Unsigned 32-bit integers are used on one or two platforms, and 36-bit
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 systems,
+ floating-point type, this was not supported by any practical system,
and POSIX.1-2013 and the <code><abbr>tz</abbr></code> code both
require <code>time_t</code> to be an integer type.
</li>
@@ -960,9 +960,9 @@ <h3 id="POSIX-extensions">Extensions to POSIX in the
separately maintaining both <code>TZ</code>
and <code>TIMEZONE</code> seemed a nuisance; and systems where
"new" forms of <code>TZ</code> might cause problems can simply
- use <code>TZ</code> values such as "<code>EST5EDT</code>" which
- can be used both by "new" programs (à la POSIX) and "old"
- programs (as zone names and offsets).
+ use legacy <code>TZ</code> values such as "<code>EST5EDT</code>" which
+ can be used by "new" programs as well as by "old" programs that
+ assume pre-POSIX <code>TZ</code> values.
</p>
</li>
<li>

0 comments on commit f7cef15

Please sign in to comment.