pike.git / lib / modules / Calendar.pmod / tzdata / Theory

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/Theory:33:   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.      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:       The Open Group Base Specifications Issue 7 -  IEEE Std 1003.1, 2013 Edition +  IEEE Std 1003.1-2008, 2016 Edition    <http://pubs.opengroup.org/onlinepubs/9699919799/>            ----- Names of time zone rules -----      Each of the database's time zone rules 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 'tzselect'
pike.git/lib/modules/Calendar.pmod/tzdata/Theory:202:    For zones whose times are taken from a city's longitude, use the    traditional xMT notation, e.g. 'PMT' for Paris Mean Time.    The only name like this in current use is 'GMT'.       Use 'LMT' for local mean time of locations before the introduction    of standard time; see "Scope of the tz database".       If there is no common English abbreviation, use numeric offsets like    -05 and +0830 that are generated by zic's %z notation.    +  Use current abbreviations for older timestamps to avoid confusion. +  For example, in 1910 a common English abbreviation for UT +01 +  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. +  +  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. +     [The remaining guidelines predate the introduction of %z.    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 %z for    inhabited locations and to "-00" for uninhabited locations.]       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:       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.    Otherwise, take the first three letters of an English place    name identifying each zone and append 'T', 'ST', etc. -  as before; e.g. 'VLAST' for VLAdivostok Summer Time. +  as before; e.g. 'CHAST' for CHAtham Summer Time.       Use UT (with time zone abbreviation '-00') for locations while    uninhabited. The leading '-' is a flag that the time    zone is in some sense undefined; this notation is    derived from Internet RFC 3339.      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 '-0600' instead of time zone
pike.git/lib/modules/Calendar.pmod/tzdata/Theory:353:    equals UTC for modern time stamps, UTC was not defined until 1960,    so commentary uses the more-general abbreviation UT for time stamps    that might predate 1960. Since UT, UT1, etc. disagree slightly,    and since pre-1972 UTC seconds varied in length, interpretation of    older time stamps can be problematic when subsecond accuracy is    needed.       * Civil time was not based on atomic time before 1972, and we don't    know the history of earth's rotation accurately enough to map SI    seconds to historical solar time to more than about one-hour -  accuracy. See: Morrison LV, Stephenson FR. -  Historical values of the Earth's clock error Delta T and the -  calculation of eclipses. J Hist Astron. 2004;35:327-36 -  <http://adsabs.harvard.edu/full/2004JHA....35..327M>; -  Historical values of the Earth's clock error. J Hist Astron. 2005;36:339 -  <http://adsabs.harvard.edu/full/2005JHA....36..339M>. +  accuracy. See: Stephenson FR, Morrison LV, Hohenkerk CY. +  Measurement of the Earth's rotation: 720 BC to AD 2015. +  Proc Royal Soc A. 2016 Dec 7;472:20160404. +  http://dx.doi.org/10.1098/rspa.2016.0404 +  Also see: Espenak F. Uncertainty in Delta T (ΔT). +  http://eclipse.gsfc.nasa.gov/SEhelp/uncertainty2004.html       * The relationship between POSIX time (that is, UTC but ignoring leap    seconds) and UTC is not agreed upon after 1972. Although the POSIX    clock officially stops during an inserted leap second, at least one    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.       * The tz database does not represent how uncertain its information is.    Ideally it would contain information about when data entries are