diff options
Diffstat (limited to 'theory.html')
| -rw-r--r-- | theory.html | 1304 |
1 files changed, 1304 insertions, 0 deletions
diff --git a/theory.html b/theory.html new file mode 100644 index 000000000000..fc2102b3e3c9 --- /dev/null +++ b/theory.html @@ -0,0 +1,1304 @@ +<html lang="en"> +<head> + <title>Theory and pragmatics of the tz code and data</title> + <meta charset="UTF-8"> +</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="#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> +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. +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-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 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 +<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> + +<ul> + <li> + Uniquely identify every region 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. + </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→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. +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> + 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 + 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>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>. + </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, + 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>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>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 + 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>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> + <li> + 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>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>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, 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> +The file '<code>zone1970.tab</code>' lists geographical locations used +to name <code><abbr>tz</abbr></code> regions. +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 +<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° +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>'). +</p> + +<p> +Older versions of this package defined legacy names that are +incompatible with the first guideline of location names, but which are +still supported. +These legacy names are mostly defined in the file +'<code>etcetera</code>'. +Also, the file '<code>backward</code>' defines the legacy names +'<code>GMT0</code>', '<code>GMT-0</code>' and '<code>GMT+0</code>', +and the file '<code>northamerica</code>' defines the legacy names +'<code>EST5EDT</code>', '<code>CST6CDT</code>', +'<code>MST7MDT</code>', and '<code>PST8PDT</code>'. +</p> + +<p> +Excluding '<code>backward</code>' should not affect the other data. +If '<code>backward</code>' is excluded, excluding +'<code>etcetera</code>' should not affect the remaining data. +</p> +</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 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 + 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 + character set in the current locale. + In practice ASCII alphanumerics and '<code>+</code>' and + '<code>-</code>' are safe in all locales. + + <p> + In other words, in the C locale the POSIX extended regular + expression <code>[-+[:alnum:]]{3,6}</code> should match the + abbreviation. + This guarantees that all abbreviations could have been specified by a + POSIX <code>TZ</code> string. + </p> + </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–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> + <p> + For times taken from a city's longitude, use the + traditional <var>x</var>MT notation. + The only abbreviation like this in current use is '<abbr>GMT</abbr>'. + 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> + + <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 + <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–1932, + DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time + 1880–1916, + MMT/MST/MDST for Moscow 1880–1919, and + RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926. + An extra-special case is SET for Swedish Time (<em>svensk + normaltid</em>) 1879–1899, 3° 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 + 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 + 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>. + </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'. +</p> +</section> + +<section> + <h2 id="accuracy">Accuracy of the <code><abbr>tz</abbr></code> database</h2> +<p> +The <code><abbr>tz</abbr></code> database is not authoritative, and it +surely has errors. +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 <code><abbr>tz</abbr></code> database arise from many sources: +</p> + +<ul> + <li> + The <code><abbr>tz</abbr></code> database predicts future + timestamps, and current predictions + 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 + 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 + Global Transformation of Time, 1870–1950</a></cite>, + Vanessa Ogle writes + "Outside of Europe and North America there was no system of time + zones at all, often not even a stable landscape of mean times, + prior to the middle decades of the twentieth century". + See: Timothy Shenk, <a +href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle">Booked: + A Global History of Time</a>. <cite>Dissent</cite> 2015-12-17. + </li> + <li> + Most of the pre-1970 data entries come from unreliable sources, often + astrology books that lack citations and whose compilers evidently + invented entries when the true facts were unknown, without + reporting which entries were known and which were invented. + These books often contradict each other or give implausible entries, + and on the rare occasions when they are checked they are + typically found to be incorrect. + </li> + <li> + For the UK the <code><abbr>tz</abbr></code> database relies on + years of first-class work done by + Joseph Myers and others; see + "<a href="https://www.polyomino.org.uk/british-time/">History of + legal time in Britain</a>". + Other countries are not done nearly as well. + </li> + <li> + Sometimes, different people in the same city maintain clocks + that differ significantly. + Historically, railway time was used by railroad companies (which + did not always + agree with each other), church-clock time was used for birth + certificates, etc. + More recently, competing political groups might disagree about + clock settings. Often this is merely common practice, but + sometimes it is set by law. + For example, from 1891 to 1911 the <abbr>UT</abbr> offset in France + was legally <abbr>UT</abbr> +00:09:21 outside train stations and + <abbr>UT</abbr> +00:04:21 inside. Other examples include + Chillicothe in 1920, Palm Springs in 1946/7, and Jerusalem and + Ürümqi to this day. + </li> + <li> + Although a named location in the <code><abbr>tz</abbr></code> + 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&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 + 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 + 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 + <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> + Even if the time is specified by law, locations sometimes + deliberately flout the law. + </li> + <li> + Early timekeeping practices, even assuming perfect clocks, were + often not specified to the accuracy that the + <code><abbr>tz</abbr></code> database requires. + </li> + <li> + Sometimes historical timekeeping was specified more precisely + than what the <code><abbr>tz</abbr></code> code can handle. + For example, from 1909 to 1937 <a + href="https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm" + hreflang="nl">Netherlands clocks</a> were legally Amsterdam Mean + Time (estimated to be <abbr>UT</abbr> + +00:19:32.13), but the <code><abbr>tz</abbr></code> + code cannot represent the fractional second. + In practice these old specifications were rarely if ever + implemented to subsecond precision. + </li> + <li> + Even when all the timestamp transitions recorded by the + <code><abbr>tz</abbr></code> database are correct, the + <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. + </li> + <li> + The <code><abbr>tz</abbr></code> database models pre-standard 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. + 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. + </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, + <abbr>UT</abbr> denotes a family of time standards that includes + Coordinated Universal Time (<abbr>UTC</abbr>) along with other + variants such as <abbr>UT1</abbr> and <abbr>GMT</abbr>, + with days starting at midnight. + 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 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>. + <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. + 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. + </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 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. +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 +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 +that are upwards compatible with those of POSIX. +Code compatible with this package is already +<a href="tz-link.html#tzdb">part of many platforms</a>, where the +primary use of this package is to update obsolete time-related files. +To do this, you may need to compile the time zone compiler +'<code>zic</code>' supplied with this package instead of using the +system '<code>zic</code>', since the format of <code>zic</code>'s +input is occasionally extended, and a platform may still be shipping +an older <code>zic</code>. +</p> + +<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 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> + <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. + Starting with POSIX.1-2001, <var>std</var> and <var>dst</var> + may also be in a quoted form like '<code><+09></code>'; + this allows "<code>+</code>" and "<code>-</code>" in the names. + </dd> + <dt><var>offset</var></dt><dd> + is of the form + '<code>[±]<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≤<var>hh</var>≤24. + The default <abbr>DST</abbr> 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> + specifies the beginning and end of <abbr>DST</abbr>. + If this is absent, the system supplies its own ruleset + for <abbr>DST</abbr>, and its rules can differ from year to year; + typically <abbr>US</abbr> <abbr>DST</abbr> rules are used. + </dd> + <dt><var>time</var></dt><dd> + takes the form + '<var>hh</var><code>:</code>[<var>mm</var>[<code>:</code><var>ss</var>]]' + and defaults to 02:00. + This is the same format as the offset, except that a + leading '<code>+</code>' or '<code>-</code>' is not allowed. + </dd> + <dt><var>date</var></dt><dd> + takes one of the following forms: + <dl> + <dt>J<var>n</var> (1≤<var>n</var>≤365)</dt><dd> + origin-1 day number not counting February 29 + </dd> + <dt><var>n</var> (0≤<var>n</var>≤365)</dt><dd> + origin-0 day number counting February 29 if present + </dd> + <dt><code>M</code><var>m</var><code>.</code><var>n</var><code>.</code><var>d</var> + (0[Sunday]≤<var>d</var>≤6[Saturday], 1≤<var>n</var>≤5, + 1≤<var>m</var>≤12)</dt><dd> + for the <var>d</var>th day of week <var>n</var> of + month <var>m</var> of the year, where week 1 is the first + week in which day <var>d</var> appears, and + '<code>5</code>' stands for the last week in which + day <var>d</var> appears (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> + + <p> + Here is an example POSIX <code>TZ</code> string for New + Zealand after 2007. + It says that standard time (<abbr>NZST</abbr>) is 12 hours ahead + of <abbr>UT</abbr>, and that daylight saving time + (<abbr>NZDT</abbr>) is observed from September's last Sunday at + 02:00 until April's first Sunday at 03:00: + </p> + + <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre> + + <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 + "<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 + 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 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 – 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> + <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 + 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, + 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 + (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. + 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 + 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. + 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). + </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. + 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 + 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 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 – directly or + indirectly – and there is no <code>TZ</code> environment + variable; portable applications should not, however, rely on this + 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> + +<h3 id="vestigial">POSIX features no longer needed</h3> +<p> +POSIX and <a href="https://en.wikipedia.org/wiki/ISO_C"><abbr>ISO</abbr> C</a> +define some <a href="https://en.wikipedia.org/wiki/API"><abbr +title="application programming interface">API</abbr>s</a> that are vestigial: +they are not needed, and are relics of a too-simple model that does +not suffice to handle many real-world timestamps. +Although the <code><abbr>tz</abbr></code> code supports these +vestigial <abbr>API</abbr>s for backwards compatibility, they should +be avoided in portable applications. +The vestigial <abbr>API</abbr>s are: +</p> +<ul> + <li> + The POSIX <code>tzname</code> variable does not suffice and is no + longer needed. + To get a timestamp's time zone abbreviation, consult + the <code>tm_zone</code> member if available; otherwise, + use <code>strftime</code>'s <code>"%Z"</code> conversion + specification. + </li> + <li> + The POSIX <code>daylight</code> and <code>timezone</code> + variables do not suffice and are no longer needed. + To get a timestamp's <abbr>UT</abbr> offset, consult + the <code>tm_gmtoff</code> member if available; otherwise, + subtract values returned by <code>localtime</code> + and <code>gmtime</code> using the rules of the Gregorian calendar, + or use <code>strftime</code>'s <code>"%z"</code> conversion + specification if a string like <code>"+0900"</code> suffices. + </li> + <li> + The <code>tm_isdst</code> member is almost never needed and most of + its uses should be discouraged in favor of the abovementioned + <abbr>API</abbr>s. + Although it can still be used in arguments to + <code>mktime</code> to disambiguate timestamps near + a <abbr>DST</abbr> transition when the clock jumps back, this + disambiguation does not work when standard time itself jumps back, + 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 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(&clock)->tm_zone</code> + (if <code>TM_ZONE</code> is defined) or + <code>tzname[localtime(&clock)->tm_isdst]</code> + (if <code>HAVE_TZNAME</code> is defined) to learn the correct time + zone abbreviation to use. + </li> + <li> + 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 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" – 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 + 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> +</ul> +</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. + </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> + The format of <code>zic</code> input files, documented in + the <code>zic</code> man page. + </li> + <li> + The format of <code>zic</code> output files, documented in + the <code>tzfile</code> man page. + </li> + <li> + The format of zone table files, documented in <code>zone1970.tab</code>. + </li> + <li> + The format of the country code file, documented in <code>iso3166.tab</code>. + </li> + <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, <code><abbr>tz</abbr></code> 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.html#download">Downloading +the <code><abbr>tz</abbr></code> database</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 <abbr>UT</abbr> +offsets or abbreviations for timestamps, as data entries are often +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 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 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 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 +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>. +</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. +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> + +<p> +Many calendars have been proposed for Mars, but none have achieved +wide acceptance. +Astronomers often use Mars Sol Date (<abbr>MSD</abbr>) which is a +sequential count of Mars solar days elapsed since about 1873-12-29 +12:00 <abbr>GMT</abbr>. +</p> + +<p> +In our solar system, Mars is the planet with time and calendar most +like Earth's. +On other planets, Sun-based time and calendars would work quite +differently. +For example, although Mercury's +<a href="https://en.wikipedia.org/wiki/Rotation_period">sidereal +rotation period</a> is 58.646 Earth days, Mercury revolves around the +Sun so rapidly that an observer on Mercury's equator would see a +sunrise only every 175.97 Earth days, i.e., a Mercury year is 0.5 of a +Mercury day. +Venus is more complicated, partly because its rotation is slightly +<a href="https://en.wikipedia.org/wiki/Retrograde_motion">retrograde</a>: +its year is 1.92 of its days. +Gas giants like Jupiter are trickier still, as their polar and +equatorial regions rotate at different rates, so that the length of a +day depends on latitude. +This effect is most pronounced on Neptune, where the day is about 12 +hours at the poles and 18 hours at the equator. +</p> + +<p> +Although the <code><abbr>tz</abbr></code> database does not support +time on other planets, it is documented here in the hopes that support +will be added eventually. +</p> + +<p> +Sources for time on other planets: +</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>" + (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. + </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). + </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> |