aboutsummaryrefslogtreecommitdiffstats
path: root/theory.html
diff options
context:
space:
mode:
authorPhilip Paeps <philip@FreeBSD.org>2018-05-04 10:10:21 +0000
committerPhilip Paeps <philip@FreeBSD.org>2018-05-04 10:10:21 +0000
commite5646a62c8c533e263b4f576f7d153a484b1d6a5 (patch)
treeaedd9d9c1d5c6acaf0b5c8641747fab13d99ac2b /theory.html
parent52b750c8aece7970ea49bc24b613e73c83b41b24 (diff)
downloadsrc-e5646a62c8c533e263b4f576f7d153a484b1d6a5.tar.gz
src-e5646a62c8c533e263b4f576f7d153a484b1d6a5.zip
Import tzdata 2018evendor/tzdata/tzdata2018e
Notes
Notes: svn path=/vendor/tzdata/dist/; revision=333245 svn path=/vendor/tzdata/tzdata2018e/; revision=333246; tag=vendor/tzdata/tzdata2018e
Diffstat (limited to 'theory.html')
-rw-r--r--theory.html117
1 files changed, 67 insertions, 50 deletions
diff --git a/theory.html b/theory.html
index 4d8726d5a39e..fc2102b3e3c9 100644
--- a/theory.html
+++ b/theory.html
@@ -32,7 +32,7 @@ all computer-based clocks that track civil time.
It organizes <a href="tz-link.html">time zone and daylight saving time
data</a> by partitioning the world into <a
href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones">regions</a>
-whose clocks all agree about timestamps that occur after the of the <a
+whose clocks all agree about timestamps that occur after the <a
href="https://en.wikipedia.org/wiki/Unix_time">POSIX Epoch</a>
(1970-01-01 00:00:00 <a
href="https://en.wikipedia.org/wiki/Coordinated_Universal_Time"><abbr
@@ -53,7 +53,7 @@ However, the database is not designed for and does not suffice for
applications requiring accurate handling of all past times everywhere,
as it would take far too much effort and guesswork to record all
details of pre-1970 civil timekeeping.
-Athough some information outside the scope of the database is
+Although some information outside the scope of the database is
collected in a file <code>backzone</code> that is distributed along
with the database proper, this file is less reliable and does not
necessarily follow database guidelines.
@@ -68,7 +68,7 @@ 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
href="http://pubs.opengroup.org/onlinepubs/9699919799/"> The Open
-Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2008, 2016
+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
@@ -79,7 +79,7 @@ flip back and forth between two alternatives, and the rules themselves
can change at times.
Whether and when a <code><abbr>tz</abbr></code> region changes its
clock, and even the region's notional base offset from UTC, are variable.
-It doesn't even really make sense to talk about a region's
+It does not always make sense to talk about a region's
"base offset", since it is not necessarily a single number.
</p>
@@ -92,8 +92,8 @@ Each <code><abbr>tz</abbr></code> region has a unique name that
corresponds to a set of time zone rules.
Inexperienced users are not expected to select these names unaided.
Distributors should provide documentation and/or a simple selection
-interface that explains the names; for one example, see the 'tzselect'
-program in the <code><abbr>tz</abbr></code> code.
+interface that explains the names; for one example, see the
+<code>tzselect</code> program in the <code><abbr>tz</abbr></code> code.
The <a href="http://cldr.unicode.org/">Unicode Common Locale Data
Repository</a> contains data that may be useful for other selection
interfaces.
@@ -137,6 +137,9 @@ region.
North and South America share the same area, '<code>America</code>'.
Typical names are '<code>Africa/Cairo</code>',
'<code>America/New_York</code>', and '<code>Pacific/Honolulu</code>'.
+Some names are further qualified to help avoid confusion; for example,
+'<code>America/Indiana/Petersburg</code>' distinguishes Petersburg,
+Indiana from other Petersburgs in America.
</p>
<p>
@@ -159,7 +162,8 @@ in decreasing order of importance:
<code>TZ</code> strings</a>.
A file name component must not exceed 14 characters or start with
'<code>-</code>'.
- E.g., prefer '<code>Brunei</code>' to '<code>Bandar_Seri_Begawan</code>'.
+ E.g., prefer <code>Asia/Brunei</code> to
+ <code>Asia/Bandar_Seri_Begawan</code>.
Exceptions: see the discussion of legacy names below.
</li>
<li>
@@ -177,8 +181,8 @@ in decreasing order of importance:
name <var>AB</var> (ignoring case), then <var>B</var> must not
start with '<code>/</code>', as a regular file cannot have the
same name as a directory in POSIX.
- For example, '<code>America/New_York</code>' precludes
- '<code>America/New_York/Bronx</code>'.
+ For example, <code>America/New_York</code> precludes
+ <code>America/New_York/Bronx</code>.
</li>
<li>
Uninhabited regions like the North Pole and Bouvet Island
@@ -193,50 +197,56 @@ in decreasing order of importance:
</li>
<li>
If all the clocks in a region have agreed since 1970,
- don't bother to include more than one location
+ do not bother to include more than one location
even if subregions' clocks disagreed before 1970.
Otherwise these tables would become annoyingly large.
</li>
<li>
If a name is ambiguous, use a less ambiguous alternative;
e.g., many cities are named San José and Georgetown, so
- prefer '<code>Costa_Rica</code>' to '<code>San_Jose</code>' and
- '<code>Guyana</code>' to '<code>Georgetown</code>'.
+ prefer <code>America/Costa_Rica</code> to
+ <code>America/San_Jose</code> and <code>America/Guyana</code>
+ to <code>America/Georgetown</code>.
</li>
<li>
Keep locations compact.
Use cities or small islands, not countries or regions, so that any
future changes do not split individual locations into different
<code><abbr>tz</abbr></code> regions.
- E.g., prefer '<code>Paris</code>' to '<code>France</code>', since
+ E.g., prefer <code>Europe/Paris</code> to <code>Europe/France</code>,
+ since
<a href="https://en.wikipedia.org/wiki/Time_in_France#History">France
has had multiple time zones</a>.
</li>
<li>
- Use mainstream English spelling, e.g., prefer '<code>Rome</code>'
- to '<code>Roma</code>', and prefer '<code>Athens</code>' to the
- Greek '<code>Αθήνα</code>' or the Romanized '<code>Athína</code>'.
+ Use mainstream English spelling, e.g., prefer
+ <code>Europe/Rome</code> to <code>Europe/Roma</code>, and
+ prefer <code>Europe/Athens</code> to the Greek
+ <code>Europe/Αθήνα</code> or the Romanized
+ <code>Europe/Athína</code>.
The POSIX file name restrictions encourage this guideline.
</li>
<li>
Use the most populous among locations in a region,
- e.g., prefer '<code>Shanghai</code>' to
- '<code>Beijing</code>'.
+ e.g., prefer <code>Asia/Shanghai</code> to
+ <code>Asia/Beijing</code>.
Among locations with similar populations, pick the best-known
- location, e.g., prefer '<code>Rome</code>' to
- '<code>Milan</code>'.
+ location, e.g., prefer <code>Europe/Rome</code> to
+ <code>Europe/Milan</code>.
</li>
<li>
- Use the singular form, e.g., prefer '<code>Canary</code>' to
- '<code>Canaries</code>'.
+ Use the singular form, e.g., prefer <code>Atlantic/Canary</code> to
+ <code>Atlantic/Canaries</code>.
</li>
<li>
Omit common suffixes like '<code>_Islands</code>' and
'<code>_City</code>', unless that would lead to ambiguity.
- E.g., prefer '<code>Cayman</code>' to
- '<code>Cayman_Islands</code>' and '<code>Guatemala</code>' to
- '<code>Guatemala_City</code>', but prefer
- '<code>Mexico_City</code>' to '<code>Mexico</code>'
+ E.g., prefer <code>America/Cayman</code> to
+ <code>America/Cayman_Islands</code> and
+ <code>America/Guatemala</code> to
+ <code>America/Guatemala_City</code>, but prefer
+ <code>America/Mexico_City</code> to
+ <code>America/Mexico</code>
because <a href="https://en.wikipedia.org/wiki/Time_in_Mexico">the
country of Mexico has several time zones</a>.
</li>
@@ -245,13 +255,14 @@ in decreasing order of importance:
</li>
<li>
Omit '<code>.</code>' from abbreviations in names.
- E.g., prefer '<code>St_Helena</code>' to '<code>St._Helena</code>'.
+ E.g., prefer <code>Atlantic/St_Helena</code> to
+ <code>Atlantic/St._Helena</code>.
</li>
<li>
Do not change established names if they only marginally violate
the above guidelines.
- For example, don't change the existing name '<code>Rome</code>' to
- '<code>Milan</code>' merely because Milan's population has grown
+ For example, do not change the existing name <code>Europe/Rome</code> to
+ <code>Europe/Milan</code> merely because Milan's population has grown
to be somewhat greater than Rome's.
</li>
<li>
@@ -318,8 +329,10 @@ in decreasing order of importance:
Use three to six characters that are ASCII alphanumerics or
'<code>+</code>' or '<code>-</code>'.
Previous editions of this database also used characters like
- '<code> </code>' and '<code>?</code>', but these characters have a
- special meaning to the shell and cause commands like
+ space and '<code>?</code>', but these characters have a
+ special meaning to the
+ <a href="https://en.wikipedia.org/wiki/Unix_shell">UNIX shell</a>
+ and cause commands like
'<code><a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set">set</a>
`<a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html">date</a>`</code>'
to have unexpected effects.
@@ -688,7 +701,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes
subsecond accuracy is needed.
</li>
<li>
- Civil time was not based on atomic time before 1972, and we don't
+ Civil time was not based on atomic time before 1972, and we do not
know the history of
<a href="https://en.wikipedia.org/wiki/Earth's_rotation">earth's
rotation</a> accurately enough to map <a
@@ -720,7 +733,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes
Ideally it would contain information about when data entries are
incomplete or dicey.
Partial temporal knowledge is a field of active research, though,
- and it's not clear how to apply it here.
+ and it is not clear how to apply it here.
</li>
</ul>
@@ -764,7 +777,7 @@ an older <code>zic</code>.
Unfortunately, the POSIX
<code>TZ</code> string takes a form that is hard to describe and
is error-prone in practice.
- Also, POSIX <code>TZ</code> strings can't deal with daylight
+ Also, POSIX <code>TZ</code> strings cannot deal with daylight
saving time rules not based on the Gregorian calendar (as in
Iran), or with situations where more than two time zone
abbreviations or <abbr>UT</abbr> offsets are used in an area.
@@ -874,7 +887,7 @@ an older <code>zic</code>.
need access to multiple time zone rulesets.
</li>
<li>
- In POSIX, there's no tamper-proof way for a process to learn the
+ 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
used only at certain times &ndash; without regard to whether the
@@ -973,14 +986,16 @@ an older <code>zic</code>.
by subsequent calls to <code>localtime</code>.
Source code for portable applications that "must" run on local wall
clock time should call <code>tzsetwall</code>;
- if such code is moved to "old" systems that don't
- provide <code>tzsetwall</code>, you won't be able to generate an
+ if such code is moved to "old" systems that do not
+ provide <code>tzsetwall</code>, you will not be able to generate an
executable program.
(These functions also arrange for local wall clock time to
be used if <code>tzset</code> is called &ndash; directly or
- indirectly &ndash; and there's no <code>TZ</code> environment
+ indirectly &ndash; and there is no <code>TZ</code> environment
variable; portable applications should not, however, rely on this
- behavior since it's not the way SVR2 systems behave.)
+ behavior since it is not the way <a
+ href="https://en.wikipedia.org/wiki/UNIX_System_V#SVR2"><abbr>SVR2</abbr></a>
+ systems behave.)
</li>
<li>
Negative <code>time_t</code> values are supported, on systems
@@ -1040,7 +1055,7 @@ The vestigial <abbr>API</abbr>s are:
<li>
The <a href="https://en.wikipedia.org/wiki/Version_7_Unix">7th Edition
UNIX</a> <code>timezone</code> function is not present in this
- package; it's impossible to reliably map <code>timezone</code>'s
+ package; it is impossible to reliably map <code>timezone</code>'s
arguments (a "minutes west of <abbr>GMT</abbr>" value and a
"daylight saving time in effect" flag) to a time zone
abbreviation, and we refuse to guess.
@@ -1052,7 +1067,9 @@ The vestigial <abbr>API</abbr>s are:
zone abbreviation to use.
</li>
<li>
- The <abbr>4.2BSD</abbr> <code>gettimeofday</code> function is not
+ The <a
+ href="https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#4.2BSD"><abbr>4.2BSD</abbr></a>
+ <code>gettimeofday</code> function is not
used in this package.
This formerly let users obtain the current <abbr>UTC</abbr> offset
and <abbr>DST</abbr> flag, but this functionality was removed in
@@ -1061,7 +1078,7 @@ The vestigial <abbr>API</abbr>s are:
<li>
In <abbr>SVR2</abbr>, time conversion fails for near-minimum or
near-maximum <code>time_t</code> values when doing conversions
- for places that don't use <abbr>UT</abbr>.
+ for places that do not use <abbr>UT</abbr>.
This package takes care to do these conversions correctly.
A comment in the source code tells how to get compatibly wrong
results.
@@ -1155,10 +1172,10 @@ based on guesswork and these guesses may be corrected or improved.
Calendrical issues are a bit out of scope for a time zone database,
but they indicate the sort of problems that we would run into if we
extended the time zone database further into the past.
-An excellent resource in this area is Nachum Dershowitz and Edward M.
-Reingold, <cite><a
-href="https://www.cs.tau.ac.il/~nachum/calendar-book/third-edition/">Calendrical
-Calculations: Third Edition</a></cite>, Cambridge University Press (2008).
+An excellent resource in this area is Edward M. Reingold
+and Nachum Dershowitz, <cite><a
+href="https://www.cambridge.org/fr/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition">Calendrical
+Calculations: The Ultimate Edition</a></cite>, Cambridge University Press (2018).
Other information and sources are given in the file '<code>calendars</code>'
in the <code><abbr>tz</abbr></code> distribution.
They sometimes disagree.
@@ -1170,11 +1187,11 @@ They sometimes disagree.
<p>
Some people's work schedules
use <a href="https://en.wikipedia.org/wiki/Timekeeping on Mars">Mars time</a>.
-Jet Propulsion Laboratory (JPL) coordinators have kept Mars time on
-and off at least since 1997 for the
+Jet Propulsion Laboratory (JPL) coordinators kept Mars time on
+and off during the
<a href="https://en.wikipedia.org/wiki/Mars_Pathfinder#End_of_mission">Mars
Pathfinder</a> mission.
-Some of their family members have also adapted to Mars time.
+Some of their family members also adapted to Mars time.
Dozens of special Mars watches were built for JPL workers who kept
Mars time during the Mars Exploration Rovers mission (2004).
These timepieces look like normal Seikos and Citizens but use Mars
@@ -1262,7 +1279,7 @@ Sources for time on other planets:
Jia-Rui Chong,
"<a href="http://articles.latimes.com/2004/jan/14/science/sci-marstime14">Workdays
Fit for a Martian</a>", <cite>Los Angeles Times</cite>
- (2004-01-14), pp A1, A20-A21.
+ (2004-01-14), pp A1, A20&ndash;A21.
</li>
<li>
Tom Chmielewski,