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

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1: + <!DOCTYPE html>   <html lang="en">   <head>    <title>Theory and pragmatics of the tz code and data</title>    <meta charset="UTF-8"> -  +  <style> +  pre {margin-left: 2em; white-space: pre-wrap;} +  </style>   </head>      <body>   <h1>Theory and pragmatics of the <code><abbr>tz</abbr></code> code and data</h1>    <h3>Outline</h3>    <nav>    <ul>    <li><a href="#scope">Scope of the <code><abbr>tz</abbr></code>    database</a></li> -  <li><a href="#naming">Names of time zone rulesets</a></li> +  <li><a href="#naming">Names of timezones</a></li>    <li><a href="#abbreviations">Time zone abbreviations</a></li>    <li><a href="#accuracy">Accuracy of the <code><abbr>tz</abbr></code>    database</a></li>    <li><a href="#functions">Time and date functions</a></li>    <li><a href="#stability">Interface stability</a></li>    <li><a href="#calendar">Calendrical issues</a></li>    <li><a href="#planets">Time and time zones on other planets</a></li>    </ul>    </nav>      <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> + href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones"><dfn>timezones</dfn></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 + The database labels each timezone 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, + Each timezone typically corresponds to a geographical region that is + smaller than a traditional time zone, because clocks in a timezone + all agree after 1970 whereas a traditional time zone merely + specifies current standard time. For example, applications that deal + with current and future timestamps in the traditional North + American mountain time zone can choose from the timezones + <code>America/Denver</code> which observes US-style daylight saving + time, <code>America/Mazatlan</code> which observes Mexican-style DST, + and <code>America/Phoenix</code> which does not observe DST. + Applications that also deal with past timestamps in the mountain time + zone can choose from over a dozen timezones, such as + <code>America/Boise</code>, <code>America/Edmonton</code>, and + <code>America/Hermosillo</code>, each of which currently uses mountain + time but differs from other timezones for some timestamps after 1970. + </p> +  + <p> + Clock transitions before 1970 are recorded for each timezone,   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.   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.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:66:   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-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 + 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   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 does not always make sense to talk about a region's - "base offset", since it is not necessarily a single number. + Whether and when a timezone changes its + clock, and even the timezone's notional base offset from UTC, are variable. + It does not always make sense to talk about a timezone's + "base offset", which is not necessarily a single number.   </p>      </section>      <section> -  <h2 id="naming">Names of time zone rulesets</h2> +  <h2 id="naming">Names of timezones</h2>   <p> - Each <code><abbr>tz</abbr></code> region has a unique name that - corresponds to a set of time zone rules. + Each timezone has a unique name.   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 + interface that explains each name via a map or via descriptive text like + "Ruthenia" instead of the timezone name "<code>Europe/Uzhgorod</code>". + If geolocation information is available, a selection interface can + locate the user on a timezone map or prioritize names that are + geographically close. For an example selection interface, 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. + interfaces; it maps timezone names like <code>Europe/Uzhgorod</code> + to CLDR names like <code>uauzh</code> which are in turn mapped to + locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and + "乌日哥罗德".   </p>      <p>   The naming conventions attempt to strike a balance   among the following goals:   </p>      <ul>    <li> -  Uniquely identify every region where clocks have agreed since 1970. +  Uniquely identify every timezone where clocks have agreed since 1970.    This is essential for the intended use: static clocks keeping local    civil time.    </li>    <li> -  Indicate to experts where that region is. +  Indicate to experts where the timezone's clocks typically are.    </li>    <li>    Be robust in the presence of political changes.    For example, names of countries are ordinarily not used, to avoid    incompatibilities when countries change their name (e.g.,    Zaire&rarr;Congo) or when locations change countries (e.g., Hong    Kong from UK colony to China).    </li>    <li>    Be portable to a wide variety of implementations.    </li>    <li>    Use a consistent naming conventions over the entire world.    </li>   </ul>      <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. + <var>AREA</var> is a continent or ocean, and + <var>LOCATION</var> is a specific location within the area.   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, + choosing timezone names,   in decreasing order of importance:   </p>      <ul>    <li>    Use only valid POSIX file name components (i.e., the parts of    names other than '<code>/</code>').    Do not use the file name components '<code>.</code>' and    '<code>..</code>'.    Within a file name component, use only <a
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:189:    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, -  do not bother to include more than one location -  even if subregions' clocks disagreed before 1970. +  If all the clocks in a timezone have agreed since 1970, +  do not bother to include more than one timezone +  even if some of the 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>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. +  timezones.    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>Europe/Rome</code> to <code>Europe/Roma</code>, and +  <code>Europe/Rome</code> to <code>Europa/Roma</code>, and    prefer <code>Europe/Athens</code> to the Greek -  <code>Europe/Αθήνα</code> or the Romanized -  <code>Europe/Athína</code>. +  <code>Ευρώπη/Αθήνα</code> or the Romanized +  <code>Evrópi/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>Asia/Shanghai</code> to    <code>Asia/Beijing</code>.    Among locations with similar populations, pick the best-known    location, e.g., prefer <code>Europe/Rome</code> to    <code>Europe/Milan</code>.    </li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:267:    </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>   The file '<code>zone1970.tab</code>' lists geographical locations used - to name <code><abbr>tz</abbr></code> regions. + to name timezones.   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. + regions as described above; this is a subset of the timezones in the data.   Although a '<code>zone1970.tab</code>' location's   <a href="https://en.wikipedia.org/wiki/Longitude">longitude</a>   corresponds to   its <a href="https://en.wikipedia.org/wiki/Local_mean_time">local mean   time (<abbr>LMT</abbr>)</a> 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,
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:373:    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, +  GST/GDT Guam, +  HST/HDT/HWT/HPT 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, -  +  PST/PDT Philippine,    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>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:446:    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 -  <abbr>GMT<abbr>/<abbr>BST</abbr> established for time in the UK. +  <abbr>GMT</abbr>/<abbr>BST</abbr> 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 '<abbr>LMT</abbr>' for local mean time of locations before the    introduction of standard time; see "<a href="#scope">Scope of the    <code><abbr>tz</abbr></code> 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 +  <code>-</code>05 and <code>+</code>0530 that are generated    by <code>zic</code>'s <code>%z</code> notation.    </li>    <li>    Use current abbreviations for older timestamps to avoid confusion.    For example, in 1910 a common English abbreviation for time    in central Europe was 'MEZ' (short for both "Middle European    Zone" and for "Mitteleuropäische Zeit" in German).    Nowadays '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 <code><abbr>tz</abbr></code> region's history. -  For example, if history tends to use numeric +  Use a consistent style in a timezone's history. +  For example, if a history tends to use numeric    abbreviations and a particular entry could go either way, use a    numeric abbreviation.    </li>    <li>    Use    <a href="https://en.wikipedia.org/wiki/Universal_Time">Universal Time</a>    (<abbr>UT</abbr>) (with time zone abbreviation '<code>-</code>00') for    locations while uninhabited.    The leading '<code>-</code>' is a flag that the <abbr>UT</abbr> offset is in    some sense undefined; this notation is derived    from <a href="https://tools.ietf.org/html/rfc3339">Internet -  <abbr title="Request For Comments">RFC 3339</a>. +  <abbr title="Request For Comments">RFC</abbr> 3339</a>.    </li>   </ul>      <p>   Application writers should note that these abbreviations are ambiguous   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 <abbr>UT</abbr> offsets like   '<code>-</code>0600' instead of time zone abbreviations like 'CST'.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:536:    will be incorrect after future governments change the rules.    For example, if today someone schedules a meeting for 13:00 next    October 1, Casablanca time, and tomorrow Morocco changes its    daylight saving rules, software can mess up after the rule change    if it blithely relies on conversions made before the change.    </li>    <li>    The pre-1970 entries in this database cover only a tiny sliver of how    clocks actually behaved; the vast majority of the necessary    information was lost or never recorded. -  Thousands more <code><abbr>tz</abbr></code> regions would be needed if +  Thousands more timezones would be needed if    the <code><abbr>tz</abbr></code> database's scope were extended to    cover even just the known or guessed history of standard time; for    example, the current single entry for France would need to split    into dozens of entries, perhaps hundreds.    And in most of the world even this approach would be misleading    due to widespread disagreement or indifference about what times    should be observed.    In her 2015 book    <cite><a    href="http://www.hup.harvard.edu/catalog.php?isbn=9780674286146">The
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:601:    database stands for the containing region, its pre-1970 data    entries are often accurate for only a small subset of that region.    For example, <code>Europe/London</code> stands for the United    Kingdom, but its pre-1847 times are valid only for locations that    have London's exact meridian, and its 1847 transition    to <abbr>GMT</abbr> is known to be valid only for the L&amp;NW and    the Caledonian railways.    </li>    <li>    The <code><abbr>tz</abbr></code> database does not record the -  earliest time for which a <code><abbr>tz</abbr></code> region's +  earliest time for which a timezone's    data entries are thereafter valid for every location in the region.    For example, <code>Europe/London</code> is valid for all locations    in its region after <abbr>GMT</abbr> was made the standard time,    but the date of standardization (1880-08-02) is not in the    <code><abbr>tz</abbr></code> database, other than in commentary. -  For many <code><abbr>tz</abbr></code> regions the earliest time of +  For many timezones the earliest time of    validity is unknown.    </li>    <li>    The <code><abbr>tz</abbr></code> database does not record a    region's boundaries, and in many cases the boundaries are not known. -  For example, the <code><abbr>tz</abbr></code> region +  For example, the timezone    <code>America/Kentucky/Louisville</code> represents a region    around the city of Louisville, the boundaries of which are    unclear.    </li>    <li>    Changes that are modeled as instantaneous transitions in the    <code><abbr>tz</abbr></code>    database were often spread out over hours, days, or even decades.    </li>    <li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:657:    <code><abbr>tz</abbr></code> rules that generate them may not    faithfully reflect the historical rules.    For example, from 1922 until World War II the UK moved clocks    forward the day following the third Saturday in April unless that    was Easter, in which case it moved clocks forward the previous    Sunday.    Because the <code><abbr>tz</abbr></code> database has no    way to specify Easter, these exceptional years are entered as    separate <code><abbr>tz</abbr> Rule</code> lines, even though the    legal rules did not change. +  When transitions are known but the historical rules behind them are not, +  the database contains <code>Zone</code> and <code>Rule</code> +  entries that are intended to represent only the generated +  transitions, not any underlying historical rules; however, this +  intent is recorded at best only in commentary.    </li>    <li> -  The <code><abbr>tz</abbr></code> database models pre-standard time +  The <code><abbr>tz</abbr></code> database models time    using the <a    href="https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar">proleptic -  Gregorian calendar</a> and local mean time, but many people used -  other calendars and other timescales. +  Gregorian calendar</a> with days containing 24 equal-length hours +  numbered 00 through 23, except when clock transitions occur. +  Pre-standard time is modeled as local mean time. +  However, historically many people used other calendars and other timescales.    For example, the Roman Empire used    the <a href="https://en.wikipedia.org/wiki/Julian_calendar">Julian    calendar</a>,    and <a href="https://en.wikipedia.org/wiki/Roman_timekeeping">Roman    timekeeping</a> had twelve varying-length daytime hours with a    non-hour-based system at night. -  +  And even today, some local practices diverge from the Gregorian +  calendar with 24-hour days. These divergences range from +  relatively minor, such as Japanese bars giving times like "24:30" for the +  wee hours of the morning, to more-significant differences such as <a +  href="https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-better-double-check-time">the +  east African practice of starting the day at dawn</a>, renumbering +  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. If DST is not used a different time zone +  can often do the trick; for example, in Kenya a <code>TZ</code> setting +  like <code>&lt;-03&gt;3</code> or <code>America/Cayenne</code> starts +  the day six hours later than <code>Africa/Nairobi</code> does.    </li>    <li>    Early clocks were less reliable, and data entries do not represent    clock error.    </li>    <li>    The <code><abbr>tz</abbr></code> database assumes Universal Time    (<abbr>UT</abbr>) as an origin, even though <abbr>UT</abbr> is not    standardized for older timestamps.    In the <code><abbr>tz</abbr></code> database commentary,
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:703:    <li>    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 +  <a href="https://dx.doi.org/10.1098/rspa.2016.0404">Measurement of    the Earth's rotation: 720 BC to AD 2015</a>.    <cite>Proc Royal Soc A</cite>. 2016 Dec 7;472:20160404.    Also see: Espenak F. <a    href="https://eclipse.gsfc.nasa.gov/SEhelp/uncertainty2004.html">Uncertainty    in Delta T (ΔT)</a>.    </li>    <li>    The relationship between POSIX time (that is, <abbr>UTC</abbr> but    ignoring <a href="https://en.wikipedia.org/wiki/Leap_second">leap    seconds</a>) and <abbr>UTC</abbr> is not agreed upon after 1972.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:739:      <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.   In particular, the <code><abbr>tz</abbr></code> database's   <abbr>LMT</abbr> offsets should not be considered meaningful, and - should not prompt creation of <code><abbr>tz</abbr></code> regions + should not prompt creation of timezones   merely because two locations   differ in <abbr>LMT</abbr> or transitioned to standard time at   different dates.   </p>   </section>      <section>    <h2 id="functions">Time and date functions</h2>   <p>   The <code><abbr>tz</abbr></code> code contains time and date functions
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:791:    <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:    </p>       <dl>    <dt><var>std</var> and <var>dst</var></dt><dd>    are 3 or more characters specifying the standard -  and daylight saving time (<abbr>DST</abbr>) zone names. +  and daylight saving time (<abbr>DST</abbr>) zone abbreviations.    Starting with POSIX.1-2001, <var>std</var> and <var>dst</var>    may also be 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 <abbr>UT</abbr>.    '<var>hh</var>' may be a single digit;    0&le;<var>hh</var>&le;24.
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:863:       <p>    This POSIX <code>TZ</code> string is hard to remember, and    mishandles some timestamps before 2008.    With this package you can use this instead:    </p>       <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>    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. +  need access to multiple timezones.    </li>    <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    the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary -  timestamps, particularly for <code><abbr>tz</abbr></code> regions +  timestamps, particularly for timezones    that do not fit into the POSIX model.    </li>    <li>    POSIX requires that systems ignore leap seconds.    </li>    <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    since 1970-01-01 00:00:00 <abbr>UTC</abbr>, ignoring leap seconds.    In practice, <code>time_t</code> is usually a signed 64- or 32-bit    integer; 32-bit signed <code>time_t</code> values stop working after    2038-01-19 03:14:07 <abbr>UTC</abbr>, so new implementations these    days typically use a signed 64-bit integer.    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>   </ul>      <h3 id="POSIX-extensions">Extensions to POSIX 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 binary file from which time-related information is read +  the name of a file from which time-related information is read    (or is interpreted à la POSIX); <code>TZ</code> is no longer -  constrained to be a three-letter time zone -  abbreviation followed by a number of hours and an optional three-letter -  daylight time zone abbreviation. +  constrained to be a string containing abbreviations +  and numeric data as described <a href="#POSIX">above</a>. +  The file's format is <dfn><abbr>TZif</abbr></dfn>, +  a timezone information format that contains binary data.    The daylight saving time rules to be used for a -  particular <code><abbr>tz</abbr></code> region are encoded in the -  binary file; the format of the file -  allows U.S., Australian, and other rules to be encoded, and +  particular timezone are encoded in the +  <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, +  Australian, and other rules to be encoded, and    allows for situations where more than two time zone    abbreviations are used.    </p>    <p>    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    some other environment variable (for example, <code>TIMEZONE</code>) -  to hold the string used to generate the binary file's name. +  to hold the string used to generate the <abbr>TZif</abbr> file's name.    In the end, however, it was decided to continue using    <code>TZ</code>: it is widely used for time zone purposes;    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>    The code supports platforms with a <abbr>UT</abbr> offset member    in <code>struct tm</code>, e.g., <code>tm_gmtoff</code>.    </li>    <li>    The code supports platforms with a time zone abbreviation member in    <code>struct tm</code>, e.g., <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 -  time zone rulesets. +  timezones.    The <code>tzalloc</code> and <code>tzfree</code> functions    allocate and free objects of type <code>timezone_t</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>.    </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
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1086:    <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.    They do, however, represent responses of various authors to    standardization proposals.    </li>    <li> -  Other time conversion proposals, in particular the one developed -  by folks at Hewlett Packard, offer a wider selection of functions +  Other time conversion proposals, in particular those supported by the +  <a href="https://howardhinnant.github.io/date/tz.html">Time Zone +  Database Parser</a>, offer a wider selection of functions    that provide capabilities beyond those provided here.    The absence of such functions from this package is not meant to    discourage the development, standardization, or use of such    functions.    Rather, their absence reflects the decision to make this package    contain valid extensions to POSIX, to ensure its broad    acceptability.    If more powerful time conversion functions can be standardized, so    much the better.    </li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1109:   </section>      <section>    <h2 id="stability">Interface stability</h2>   <p>   The <code><abbr>tz</abbr></code> code and data supply the following interfaces:   </p>      <ul>    <li> -  A set of <code><abbr>tz</abbr></code> region names as per -  "<a href="#naming">Names of time zone rulesets</a>" above. +  A set of timezone names as per +  "<a href="#naming">Names of timezones</a>" above.    </li>    <li>    Library functions described in "<a href="#functions">Time and date    functions</a>" above.    </li>    <li>    The programs <code>tzselect</code>, <code>zdump</code>,    and <code>zic</code>, documented in their man pages.    </li>    <li>
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1179:   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>. + use <a href="https://en.wikipedia.org/wiki/Timekeeping_on_Mars">Mars time</a>.   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 + <a href="https://en.wikipedia.org/wiki/Mars_Pathfinder">Mars   Pathfinder</a> mission.   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
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1205:   equals about 1.02749125 terrestrial seconds.   </p>      <p>   The <a href="https://en.wikipedia.org/wiki/Prime_meridian">prime   meridian</a> of Mars goes through the center of the crater   <a href="https://en.wikipedia.org/wiki/Airy-0">Airy-0</a>, named in   honor of the British astronomer who built the Greenwich telescope that   defines Earth's prime meridian.   Mean solar time on the Mars prime meridian is - called <a href="https://en.wikipedia.org/wiki/Mars_Coordinated_Time">Mars - Coordinated Time (<abbr>MTC</abbr>)</a>. + called Mars Coordinated Time (<abbr>MTC</abbr>).   </p>      <p>   Each landed mission on Mars has adopted a different reference for - solar time keeping, so there is no real standard for Mars time zones. + solar timekeeping, so there is no real standard for Mars time zones.   For example, the   <a href="https://en.wikipedia.org/wiki/Mars_Exploration_Rover">Mars   Exploration Rover</a> project (2004) defined two time zones "Local   Solar Time A" and "Local Solar Time B" for its two missions, each zone   designed so that its time equals local true solar time at   approximately the middle of the nominal mission.   Such a "time zone" is not particularly suited for any application   other than the mission itself.   </p>   
pike.git/lib/modules/Calendar.pmod/tzdata/theory.html:1283:    </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>" -  (2017-04-27). +  (2016-01-20).    </li>   </ul>   </section>      <footer>    <hr>    This file is in the public domain, so clarified as of 2009-05-17 by    Arthur David Olson.   </footer>   </body>   </html>