pike.git / lib / modules / Calendar.pmod / tzdata / theory.html

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:25:   <section>    <h2 id="scope">Scope of the <code><abbr>tz</abbr></code> database</h2>   <p>   The <a   href="https://www.iana.org/time-zones"><code><abbr>tz</abbr></code>   database</a> attempts to record the history and predicted future of   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   title="Coordinated Universal Time">UTC</abbr></a>).   The database labels each such region with a notable location and   records all known clock transitions for that location.   Although 1970 is a somewhat-arbitrary cutoff, there are significant   challenges to moving the cutoff earlier even by a decade or two, due   to the wide variety of local practices before computer timekeeping   became prevalent.   </p>      <p>   Clock transitions before 1970 are recorded for each such location,   because most systems support timestamps before 1970 and could   misbehave if data entries were omitted for pre-1970 transitions.   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.   </p>      <p>   As described below, reference source code for using the   <code><abbr>tz</abbr></code> database is also available.   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   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   standard and daylight saving times supported by POSIX.   A <code><abbr>tz</abbr></code> region 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   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>      </section>      <section>    <h2 id="naming">Names of time zone rulesets</h2>   <p>   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.   </p>      <p>   The naming conventions attempt to strike a balance   among the following goals:   </p>   
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:130:      <p>   Names normally have the form   <var>AREA</var><code>/</code><var>LOCATION</var>, where   <var>AREA</var> is the name of a continent or ocean, and   <var>LOCATION</var> is the name of a specific location within that   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>   Here are the general guidelines used for   choosing <code><abbr>tz</abbr></code> region names,   in decreasing order of importance:   </p>      <ul>    <li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:152:    Do not use the file name components '<code>.</code>' and    '<code>..</code>'.    Within a file name component, use only <a    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="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX    <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>    A name must not be empty, or contain '<code>//</code>', or    start or end with '<code>/</code>'.    </li>    <li>    Do not use names that differ only in case.    Although the reference implementation is case-sensitive, some    other implementations are not, and they would mishandle names    differing only in case.    </li>    <li>    If one name <var>A</var> is an initial prefix of another    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    do not need locations, since local time is not defined there.    </li>    <li>    There should typically be at least one name for each <a    href="https://en.wikipedia.org/wiki/ISO_3166-1"><abbr    title="International Organization for Standardization">ISO</abbr>    3166-1</a> officially assigned two-letter code for an inhabited    country or territory.    </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>    <li>    Use '<code>_</code>' to represent a space.    </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>    If a name is changed, put its old spelling in the    '<code>backward</code>' file.    This means old spellings will continue to work.    </li>   </ul>      <p>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:311:   like '<code>EST</code>' to be compatible with human tradition and POSIX.   Here are the general guidelines used for choosing time zone abbreviations,   in decreasing order of importance:   </p>      <ul>    <li>    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.    Previous editions of this guideline required upper-case letters, but the    Congressman who introduced    <a href="https://en.wikipedia.org/wiki/Chamorro_Time_Zone">Chamorro    Standard Time</a> preferred "ChST", so lower-case letters are now    allowed.    Also, POSIX from 2001 on relaxed the rule to allow '<code>-</code>',    '<code>+</code>', and alphanumeric characters from the portable
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:681:    Although <abbr>UT</abbr> equals <abbr>UTC</abbr> for modern    timestamps, <abbr>UTC</abbr> was not defined until 1960, so    commentary uses the more-general abbreviation <abbr>UT</abbr> for    timestamps that might predate 1960.    Since <abbr>UT</abbr>, <abbr>UT1</abbr>, etc. disagree slightly,    and since pre-1972 <abbr>UTC</abbr> seconds varied in length,    interpretation of older timestamps can be problematic when    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    href="https://en.wikipedia.org/wiki/International_System_of_Units"><abbr    title="International System of Units">SI</abbr></a> seconds to    historical <a href="https://en.wikipedia.org/wiki/Solar_time">solar time</a>    to more than about one-hour accuracy.    See: Stephenson FR, Morrison LV, Hohenkerk CY.    <a href="http://dx.doi.org/10.1098/rspa.2016.0404">Measurement of    the Earth's rotation: 720 BC to AD 2015</a>.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:713:    proposed standard has it jumping back a second instead; and in    practice POSIX clocks more typically either progress glacially during    a leap second, or are slightly slowed while near a leap second.    </li>    <li>    The <code><abbr>tz</abbr></code> database does not represent how    uncertain its information is.    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>      <p>   In short, many, perhaps most, of the <code><abbr>tz</abbr></code>   database's pre-1970 and future timestamps are either wrong or   misleading.   Any attempt to pass the   <code><abbr>tz</abbr></code> database off as the definition of time   should be unacceptable to anybody who cares about the facts.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:757:      <h3 id="POSIX">POSIX properties and limitations</h3>   <ul>    <li>    <p>    In POSIX, time display in a process is controlled by the    environment variable <code>TZ</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.    </p>       <p>    The POSIX <code>TZ</code> string takes the following form:    </p>       <p>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:867:    <abbr>US</abbr> time conversion rules change (as in the United    States in 1987), all programs that do time conversion must be    recompiled to ensure proper results.    </li>    <li>    The <code>TZ</code> environment variable is process-global, which    makes it hard to write efficient, thread-safe applications that    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    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.)    </li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:966:    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>.    </li>    <li>    A function <code>tzsetwall</code> has been added to arrange for the    system's best approximation to local wall clock time to be delivered    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    where <code>time_t</code> is signed.    </li>    <li>    These functions can account for leap seconds, thanks to Bradley White.    </li>   </ul>   
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1033:    which can occur when a location changes to a time zone with a    lesser <abbr>UT</abbr> offset.    </li>   </ul>      <h3 id="other-portability">Other portability notes</h3>   <ul>    <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.    Programs that in the past used the <code>timezone</code> function    may now examine <code>localtime(&amp;clock)-&gt;tm_zone</code>    (if <code>TM_ZONE</code> is defined) or    <code>tzname[localtime(&amp;clock)-&gt;tm_isdst]</code>    (if <code>HAVE_TZNAME</code> is defined) to learn the correct time    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    later versions of <abbr>BSD</abbr>.    </li>    <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.    </li>    <li>    The functions that are conditionally compiled    if <code>STD_INSPIRED</code> is defined should, at this point, be    looked on primarily as food for thought.    They are not in any sense "standard compatible" &ndash; some are    not, in fact, specified in <em>any</em> standard.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1148:   based on guesswork and these guesses may be corrected or improved.   </p>   </section>      <section>    <h2 id="calendar">Calendrical issues</h2>   <p>   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.   </p>   </section>      <section>    <h2 id="planets">Time and time zones on other planets</h2>   <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   seconds rather than terrestrial seconds.   </p>      <p>   A Mars solar day is called a "sol" and has a mean period equal to   about 24 hours 39 minutes 35.244 seconds in terrestrial time.   It is divided into a conventional 24-hour clock, so each Mars second
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1255:    <li>    Michael Allison and Robert Schmunk,    "<a href="https://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical    Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a>"    (2015-06-30).    </li>    <li>    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,    "<a href="https://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/">Jet    Lag Is Worse on Mars</a>", <cite>The Atlantic</cite> (2015-02-26)    </li>    <li>    Matt Williams,    "<a href="https://www.universetoday.com/37481/days-of-the-planets/">How    long is a day on the other planets of the solar system?</a>"