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

version» Context lines:

pike.git/lib/modules/Calendar.pmod/tzdata/Theory:1:   Theory and pragmatics of the tz code and data         ----- Outline -----       Scope of the tz database    Names of time zone rules    Time zone abbreviations    Accuracy of the tz database    Time and date functions +  Interface stability    Calendrical issues    Time and time zones on Mars         ----- Scope of the tz database -----      The tz database attempts to record the history and predicted future of   all computer-based clocks that track civil time. To represent this   data, the world is partitioned into regions whose clocks all agree   about time stamps that occur after the somewhat-arbitrary cutoff point
pike.git/lib/modules/Calendar.pmod/tzdata/Theory:335:    way to specify Easter, these exceptional years are entered as    separate tz Rule lines, even though the legal rules did not change.       * The tz database models pre-standard time using the proleptic Gregorian    calendar and local mean time (LMT), but many people used other    calendars and other timescales. For example, the Roman Empire used    the Julian calendar, and had 12 varying-length daytime hours with a    non-hour-based system at night.       * Early clocks were less reliable, and data entries do not represent -  this unreliability. +  clock error.    -  * As for leap seconds, 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. +  * The tz database assumes Universal Time (UT) as an origin, even +  though UT is not standardized for older time stamps. In the tz +  database commentary, UT denotes a family of time standards that +  includes Coordinated Universal Time (UTC) along with other variants +  such as UT1 and GMT, with days starting at midnight. Although UT +  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>.       * 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
pike.git/lib/modules/Calendar.pmod/tzdata/Theory:594:    * The programs tzselect, zdump, and zic, documented in their man pages.       * The format of zic input files, documented in the zic man page.       * The format of zic output files, documented in the tzfile man page.       * The format of zone table files, documented in zone1970.tab.       * The format of the country code file, documented in iso3166.tab.    - When these interfaces are changed, an effort is made to preserve - backward compatibility. For example, tz data files typically do not - rely on recently-added zic features, so that users can run older zic - versions to process newer data files. +  * The version number of the code and data, as the first line of +  the text file 'version' in each release.    -  + Interface changes in a release attempt to preserve compatibility with + recent releases. For example, tz data files typically do not rely on + recently-added zic features, so that users can run older zic versions + to process newer data files. The tz-link.htm file describes how + releases are tagged and distributed. +    Interfaces not listed above are less stable. For example, users   should not rely on particular UT offsets or abbreviations for time   stamps, as data entries are often based on guesswork and these guesses   may be corrected or improved.         ----- Calendrical issues -----      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