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

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:45:   </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 + 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 tz database is   also available. The tz code is upwards compatible with POSIX, an   international standard for UNIX-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 Edition.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:233:    This means old spellings will continue to work.    </li>   </ul>      <p>   The file '<code>zone1970.tab</code>' lists geographical locations used   to name time   zone rules. It is intended to be an exhaustive list of names for   geographic regions as described above; this is a subset of the names   in the data. Although a '<code>zone1970.tab</code>' location's longitude - corresponds to its LMT offset with one hour for every 15 degrees east + corresponds to its LMT offset with one hour for every 15&deg; east   longitude, this relationship is not exact.   </p>      <p>   Older versions of this package used a different naming scheme,   and these older names are still supported.   See the file '<code>backward</code>' for most of these older names   (e.g., '<code>US/Eastern</code>' instead of '<code>America/New_York</code>').   The other old-fashioned names still supported are   '<code>WET</code>', '<code>CET</code>', '<code>MET</code>', and '<code>EET</code>' (see the file '<code>europe</code>').
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:272:    </section>    <section>    <h2 id="abbreviations">Time zone abbreviations</h2>   <p>   When this package is installed, it generates time zone abbreviations   like '<code>EST</code>' to be compatible with human tradition and POSIX.   Here are the general rules used for choosing time zone abbreviations,   in decreasing order of importance:   <ul>    <li> -  Use three or more characters that are ASCII alphanumerics or +  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    '<code>set `date`</code>'    to have unexpected effects.    Previous editions of this rule required upper-case letters,    but the Congressman who introduced Chamorro Standard Time    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 character set    in the current locale. In practice ASCII alphanumerics and    '<code>+</code>' and '<code>-</code>' are safe in all locales.       In other words, in the C locale the POSIX extended regular -  expression <code>[-+[:alnum:]]{3,}</code> should match +  expression <code>[-+[:alnum:]]{3,6}</code> should match    the abbreviation.    This guarantees that all abbreviations could have been    specified by a POSIX TZ string.    </li>    <li>    Use abbreviations that are in common use among English-speakers,    e.g. 'EST' for Eastern Standard Time in North America.    We assume that applications translate them to other languages    as part of the normal localization process; for example,    a French application might translate 'EST' to 'HNE'. -  +  + <p><small>These abbreviations (for standard/daylight/etc. time) are: + ACST/ACDT Australian Central, + AST/ADT/APT/AWT/ADDT Atlantic, + AEST/AEDT Australian Eastern, + AHST/AHDT Alaska-Hawaii, + AKST/AKDT Alaska, + AWST/AWDT Australian Western, + BST/BDT Bering, + CAT/CAST Central Africa, + CET/CEST/CEMT Central European, + ChST Chamorro, + CST/CDT/CWT/CPT/CDDT Central [North America], + CST/CDT China, + GMT/BST/IST/BDST Greenwich, + EAT East Africa, + EST/EDT/EWT/EPT/EDDT Eastern [North America], + EET/EEST Eastern European, + GST Guam, + HST/HDT Hawaii, + HKT/HKST Hong Kong, + IST India, + IST/GMT Irish, + IST/IDT/IDDT Israel, + JST/JDT Japan, + KST/KDT Korea, + MET/MEST Middle European (a backward-compatibility alias for Central European), + MSK/MSD Moscow, + MST/MDT/MWT/MPT/MDDT Mountain, + NST/NDT/NWT/NPT/NDDT Newfoundland, + NST/NDT/NWT/NPT Nome, + NZMT/NZST New Zealand through 1945, + NZST/NZDT New Zealand 1946&ndash;present, + PKT/PKST Pakistan, + PST/PDT/PWT/PPT/PDDT Pacific, + SAST South Africa, + SST Samoa, + WAT/WAST West Africa, + WET/WEST/WEMT Western European, + WIB Waktu Indonesia Barat, + WIT Waktu Indonesia Timur, + WITA Waktu Indonesia Tengah, + YST/YDT/YWT/YPT/YDDT Yukon</small>.</p>    </li>    <li>    For zones whose times are taken from a city's longitude, use the -  traditional <var>x</var>MT notation, e.g. 'PMT' for -  Paris Mean Time. -  The only name like this in current use is 'GMT'. + traditional <var>x</var>MT notation. The only abbreviation like this + in current use is 'GMT'. The others are for timestamps before 1960, + except that Monrovia Mean Time persisted until 1972. Typically, + numeric abbreviations (e.g., '<code>-</code>004430' for MMT) would + cause trouble here, as the numeric strings would exceed the POSIX length limit. +  + <p><small>These abbreviations are: + AMT Amsterdam, Asunción, Athens; + BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels, Bucharest; + CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba; + DMT Dublin/Dunsink; + EMT Easter; + FFMT Fort-de-France; + FMT Funchal; + GMT Greenwich; + HMT Havana, Helsinki, Horta, Howrah; + IMT Irkutsk, Istanbul; + JMT Jerusalem; + KMT Kaunas, Kiev, Kingston; + LMT Lima, Lisbon, local, Luanda; + MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, +  Moscow; + PLMT Phù Liễn; + PMT Paramaribo, Paris, Perm, Pontianak, Prague; + PMMT Port Moresby; + QMT Quito; + RMT Rangoon, Riga, Rome; + SDMT Santo Domingo; + SJMT San José; + SMT Santiago, Simferopol, Singapore, Stanley; + TBMT Tbilisi; + TMT Tallinn, Tehran; + WMT Warsaw</small>.</p> +  + <p><small>A few abbreviations also follow the pattern that + GMT/BST established for time in the UK. They are: +  + CMT/BST for Calamarca Mean Time and Bolivian Summer Time + 1890&ndash;1932, DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time + 1880&ndash;1916, MMT/MST/MDST for Moscow 1880&ndash;1919, and RMT/LST + for Riga Mean Time and Latvian Summer time 1880&ndash;1926. + An extra-special case is SET for Swedish Time (<em>svensk + normaltid</em>) 1879&ndash;1899, 3&deg; west of the Stockholm + Observatory.</small></p>    </li>    <li>    Use 'LMT' for local mean time of locations before the introduction    of standard time; see "<a href="#scope">Scope of the    tz database</a>".    </li>    <li>    If there is no common English abbreviation, use numeric offsets like    <code>-</code>05 and <code>+</code>0830 that are    generated by zic's <code>%z</code> notation.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:333:    'CET' ("Central European Time") is more common in English, and    the database uses 'CET' even for circa-1910 timestamps as this    is less confusing for modern users and avoids the need for    determining when 'CET' supplanted 'MEZ' in common usage.    </li>    <li>    Use a consistent style in a zone's history. For example, if a zone's    history tends to use numeric abbreviations and a particular    entry could go either way, use a numeric abbreviation.    </li> - </ul> -  [The remaining guidelines predate the introduction of <code>%z</code>. -  They are problematic as they mean tz data entries invent -  notation rather than record it. These guidelines are now -  deprecated and the plan is to gradually move to <code>%z</code> for -  inhabited locations and to "<code>-</code>00" for uninhabited locations.] - <ul> +     <li> -  If there is no common English abbreviation, abbreviate the English -  translation of the usual phrase used by native speakers. -  If this is not available or is a phrase mentioning the country -  (e.g. "Cape Verde Time"), then: -  <ul> -  <li> -  When a country is identified with a single or principal zone, -  append 'T' to the country's ISO code, e.g. 'CVT' for -  Cape Verde Time. For summer time append 'ST'; -  for double summer time append 'DST'; etc. -  </li> -  <li> -  Otherwise, take the first three letters of an English place -  name identifying each zone and append 'T', 'ST', etc. -  as before; e.g. 'CHAST' for CHAtham Summer Time. -  </li> -  </ul> -  </li> -  <li> +     Use UT (with time zone abbreviation '<code>-</code>00') for    locations while uninhabited. The leading    '<code>-</code>' is a flag that the time    zone is in some sense undefined; this notation is    derived from Internet RFC 3339.    </li>   </ul>   <p>   Application writers should note that these abbreviations are ambiguous - in practice: e.g. 'CST' has a different meaning in China than - it does in the United States. In new applications, it's often better - to use numeric UT offsets like '<code>-</code>0600' instead of time zone - abbreviations like 'CST'; this avoids the ambiguity. + in practice: e.g., 'CST' means one thing in China and something else + in North America, and 'IST' can refer to time in India, Ireland or + Israel. To avoid ambiguity, use numeric UT offsets like + '<code>-</code>0600' instead of time zone abbreviations like 'CST'.   </p>    </section>          <section>    <h2 id="accuracy">Accuracy of the tz database</h2>   <p>   The tz database is not authoritative, and it surely has errors. - Corrections are welcome and encouraged; see the file CONTRIBUTING. + Corrections are welcome and encouraged; see the file <code>CONTRIBUTING</code>.   Users requiring authoritative data should consult national standards   bodies and the references cited in the database's comments.   </p>      <p>   Errors in the tz database arise from many sources:   </p>   <ul>    <li>    The tz database predicts future timestamps, and current predictions
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:591:    <var>stdoffset</var>[<var>dst</var>[<var>offset</var>][<code>,</code><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]]]    </p>    <p>    where:    <dl>    <dt><var>std</var> and <var>dst</var></dt><dd>    are 3 or more characters specifying the standard    and daylight saving time (DST) zone names.    Starting with POSIX.1-2001, <var>std</var>    and <var>dst</var> may also be -  in a quoted form like '<code>&lt;UTC+10&gt;</code>'; this allows +  in a quoted form like '<code>&lt;+09&gt;</code>'; this allows    "<code>+</code>" and "<code>-</code>" in the names.    </dd>    <dt><var>offset</var></dt><dd>    is of the form    '<code>[&plusmn;]<var>hh</var>:[<var>mm</var>[:<var>ss</var>]]</code>'    and specifies the offset west of UT. '<var>hh</var>'    may be a single digit; 0&le;<var>hh</var>&le;24.    The default DST offset is one hour ahead of standard time.    </dd>    <dt><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]</dt><dd>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:639:    (which may be either the 4th or 5th week).    Typically, this is the only useful form;    the <var>n</var>    and <code>J</code><var>n</var> forms are    rarely used.    </dd>   </dl>   </dd>   </dl>    Here is an example POSIX TZ string for New Zealand after 2007. -  It says that standard time (NZST) is 12 hours ahead of UTC, +  It says that standard time (NZST) is 12 hours ahead of UT,    and that daylight saving time (NZDT) is observed from September's    last Sunday at 02:00 until April's first Sunday at 03:00:       <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre>       This POSIX TZ string is hard to remember, and mishandles some    timestamps before 2008. With this package you can use this    instead:       <pre><code>TZ='Pacific/Auckland'</code></pre>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:671:    The TZ environment variable is process-global, which makes it hard    to write efficient, thread-safe applications that need access    to multiple time zones.    </li>    <li>    In POSIX, there's 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 TZ environment -  variable. While an administrator can "do everything in UTC" to get +  variable. While an administrator can "do everything in UT" 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>    <li>    POSIX provides no convenient and efficient way to determine the UT    offset and time zone abbreviation of arbitrary timestamps,    particularly for time zone settings that do not fit into the    POSIX model.    </li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:895:    <li>    The version number of the code and data, as the first line of    the text file '<code>version</code>' in each release.    </li>   </ul>   <p>   Interface changes in a release attempt to preserve compatibility with   recent releases. For example, tz data files typically do not rely on   recently-added <code>zic</code> features, so that users can run   older <code>zic</code> versions to process newer data - files. <a href="tz-link.htm">Sources for time zone and daylight + files. <a href="tz-link.html">Sources for time zone and daylight   saving time data</a> describes how   releases are tagged and distributed.   </p>      <p>   Interfaces not listed above are less stable. For example, users   should not rely on particular UT offsets or abbreviations for   timestamps, as data entries are often based on guesswork and these   guesses may be corrected or improved.   </p>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:996:   </p>      <p>   Sources:   </p>   <ul>    <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>" - (2012-08-08). + (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>", Los Angeles Times   (2004-01-14), pp A1, A20-A21.    </li>    <li>   Tom Chmielewski,   "<a href="https://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/">Jet