theory.html revision 325324
1325324Sgordon<!DOCTYPE html> 2325324Sgordon<html lang="en"> 3325324Sgordon<head> 4325324Sgordon <title>Theory and pragmatics of the tz code and data</title> 5325324Sgordon <meta charset="UTF-8"> 6325324Sgordon</head> 7325324Sgordon 8325324Sgordon<!-- The somewhat-unusal indenting style in this file is intended to 9325324Sgordon shrink the output of the shell command 'diff Theory Theory.html', 10325324Sgordon where 'Theory' was the plain text file that this file is derived 11325324Sgordon from. The 'Theory' file used leading white space to indent, and 12325324Sgordon when possible that indentation is preserved here. Eventually we 13325324Sgordon may stop doing this and remove this comment. --> 14325324Sgordon 15325324Sgordon<body> 16325324Sgordon <h1>Theory and pragmatics of the tz code and data</h1> 17325324Sgordon <h3>Outline</h3> 18325324Sgordon <nav> 19325324Sgordon <ul> 20325324Sgordon <li><a href="#scope">Scope of the tz database</a></li> 21325324Sgordon <li><a href="#naming">Names of time zone rules</a></li> 22325324Sgordon <li><a href="#abbreviations">Time zone abbreviations</a></li> 23325324Sgordon <li><a href="#accuracy">Accuracy of the tz database</a></li> 24325324Sgordon <li><a href="#functions">Time and date functions</a></li> 25325324Sgordon <li><a href="#stability">Interface stability</a></li> 26325324Sgordon <li><a href="#calendar">Calendrical issues</a></li> 27325324Sgordon <li><a href="#planets">Time and time zones on other planets</a></li> 28325324Sgordon </ul> 29325324Sgordon </nav> 30325324Sgordon 31325324Sgordon 32325324Sgordon <section> 33325324Sgordon <h2 id="scope">Scope of the tz database</h2> 34325324Sgordon<p> 35325324SgordonThe tz database attempts to record the history and predicted future of 36325324Sgordonall computer-based clocks that track civil time. To represent this 37325324Sgordondata, the world is partitioned into regions whose clocks all agree 38325324Sgordonabout timestamps that occur after the somewhat-arbitrary cutoff point 39325324Sgordonof the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region, 40325324Sgordonthe database records all known clock transitions, and labels the region 41325324Sgordonwith a notable location. Although 1970 is a somewhat-arbitrary 42325324Sgordoncutoff, there are significant challenges to moving the cutoff earlier 43325324Sgordoneven by a decade or two, due to the wide variety of local practices 44325324Sgordonbefore computer timekeeping became prevalent. 45325324Sgordon</p> 46325324Sgordon 47325324Sgordon<p> 48325324SgordonClock transitions before 1970 are recorded for each such location, 49325324Sgordonbecause most systems support timestamps before 1970 and could 50325324Sgordonmisbehave if data entries were omitted for pre-1970 transitions. 51325324SgordonHowever, the database is not designed for and does not suffice for 52325324Sgordonapplications requiring accurate handling of all past times everywhere, 53325324Sgordonas it would take far too much effort and guesswork to record all 54325324Sgordondetails of pre-1970 civil timekeeping. 55325324Sgordon</p> 56325324Sgordon 57325324Sgordon<p> 58325324SgordonAs described below, reference source code for using the tz database is 59325324Sgordonalso available. The tz code is upwards compatible with POSIX, an 60325324Sgordoninternational standard for UNIX-like systems. As of this writing, the 61325324Sgordoncurrent edition of POSIX is: 62325324Sgordon <a href="http://pubs.opengroup.org/onlinepubs/9699919799/"> 63325324Sgordon The Open Group Base Specifications Issue 7</a>, 64325324Sgordon IEEE Std 1003.1-2008, 2016 Edition. 65325324Sgordon</p> 66325324Sgordon </section> 67325324Sgordon 68325324Sgordon 69325324Sgordon 70325324Sgordon <section> 71325324Sgordon <h2 id="naming">Names of time zone rules</h2> 72325324Sgordon<p> 73325324SgordonEach of the database's time zone rules has a unique name. 74325324SgordonInexperienced users are not expected to select these names unaided. 75325324SgordonDistributors should provide documentation and/or a simple selection 76325324Sgordoninterface that explains the names; for one example, see the 'tzselect' 77325324Sgordonprogram in the tz code. The 78325324Sgordon<a href="http://cldr.unicode.org/">Unicode Common Locale Data 79325324SgordonRepository</a> contains data that may be useful for other 80325324Sgordonselection interfaces. 81325324Sgordon</p> 82325324Sgordon 83325324Sgordon<p> 84325324SgordonThe time zone rule naming conventions attempt to strike a balance 85325324Sgordonamong the following goals: 86325324Sgordon</p> 87325324Sgordon<ul> 88325324Sgordon <li> 89325324Sgordon Uniquely identify every region where clocks have agreed since 1970. 90325324Sgordon This is essential for the intended use: static clocks keeping local 91325324Sgordon civil time. 92325324Sgordon </li> 93325324Sgordon <li> 94325324Sgordon Indicate to experts where that region is. 95325324Sgordon </li> 96325324Sgordon <li> 97325324Sgordon Be robust in the presence of political changes. For example, names 98325324Sgordon of countries are ordinarily not used, to avoid incompatibilities 99325324Sgordon when countries change their name (e.g. Zaire→Congo) or when 100325324Sgordon locations change countries (e.g. Hong Kong from UK colony to 101325324Sgordon China). 102325324Sgordon </li> 103325324Sgordon <li> 104325324Sgordon Be portable to a wide variety of implementations. 105325324Sgordon </li> 106325324Sgordon <li> 107325324Sgordon Use a consistent naming conventions over the entire world. 108325324Sgordon </li> 109325324Sgordon</ul> 110325324Sgordon<p> 111325324SgordonNames normally have the 112325324Sgordonform <var>AREA</var><code>/</code><var>LOCATION</var>, 113325324Sgordonwhere <var>AREA</var> is the name of a continent or ocean, 114325324Sgordonand <var>LOCATION</var> is the name of a specific 115325324Sgordonlocation within that region. North and South America share the same 116325324Sgordonarea, '<code>America</code>'. Typical names are 117325324Sgordon'<code>Africa/Cairo</code>', '<code>America/New_York</code>', and 118325324Sgordon'<code>Pacific/Honolulu</code>'. 119325324Sgordon</p> 120325324Sgordon 121325324Sgordon<p> 122325324SgordonHere are the general rules used for choosing location names, 123325324Sgordonin decreasing order of importance: 124325324Sgordon</p> 125325324Sgordon<ul> 126325324Sgordon <li> 127325324Sgordon Use only valid POSIX file name components (i.e., the parts of 128325324Sgordon names other than '<code>/</code>'). Do not use the file name 129325324Sgordon components '<code>.</code>' and '<code>..</code>'. 130325324Sgordon Within a file name component, 131325324Sgordon use only ASCII letters, '<code>.</code>', 132325324Sgordon '<code>-</code>' and '<code>_</code>'. Do not use 133325324Sgordon digits, as that might create an ambiguity with POSIX 134325324Sgordon TZ strings. A file name component must not exceed 14 135325324Sgordon characters or start with '<code>-</code>'. E.g., 136325324Sgordon prefer '<code>Brunei</code>' to 137325324Sgordon '<code>Bandar_Seri_Begawan</code>'. Exceptions: see 138325324Sgordon the discussion 139325324Sgordon of legacy names below. 140325324Sgordon </li> 141325324Sgordon <li> 142325324Sgordon A name must not be empty, or contain '<code>//</code>', or 143325324Sgordon start or end with '<code>/</code>'. 144325324Sgordon </li> 145325324Sgordon <li> 146325324Sgordon Do not use names that differ only in case. Although the reference 147325324Sgordon implementation is case-sensitive, some other implementations 148325324Sgordon are not, and they would mishandle names differing only in case. 149325324Sgordon </li> 150325324Sgordon <li> 151325324Sgordon If one name <var>A</var> is an initial prefix of another 152325324Sgordon name <var>AB</var> (ignoring case), then <var>B</var> 153325324Sgordon must not start with '<code>/</code>', as a 154325324Sgordon regular file cannot have 155325324Sgordon the same name as a directory in POSIX. For example, 156325324Sgordon '<code>America/New_York</code>' precludes 157325324Sgordon '<code>America/New_York/Bronx</code>'. 158325324Sgordon </li> 159325324Sgordon <li> 160325324Sgordon Uninhabited regions like the North Pole and Bouvet Island 161325324Sgordon do not need locations, since local time is not defined there. 162325324Sgordon </li> 163325324Sgordon <li> 164325324Sgordon There should typically be at least one name for each ISO 3166-1 165325324Sgordon officially assigned two-letter code for an inhabited country 166325324Sgordon or territory. 167325324Sgordon </li> 168325324Sgordon <li> 169325324Sgordon If all the clocks in a region have agreed since 1970, 170325324Sgordon don't bother to include more than one location 171325324Sgordon even if subregions' clocks disagreed before 1970. 172325324Sgordon Otherwise these tables would become annoyingly large. 173325324Sgordon </li> 174325324Sgordon <li> 175325324Sgordon If a name is ambiguous, use a less ambiguous alternative; 176325324Sgordon e.g. many cities are named San Jos�� and Georgetown, so 177325324Sgordon prefer '<code>Costa_Rica</code>' to '<code>San_Jose</code>' and '<code>Guyana</code>' to '<code>Georgetown</code>'. 178325324Sgordon </li> 179325324Sgordon <li> 180325324Sgordon Keep locations compact. Use cities or small islands, not countries 181325324Sgordon or regions, so that any future time zone changes do not split 182325324Sgordon locations into different time zones. E.g. prefer 183325324Sgordon '<code>Paris</code>' to '<code>France</code>', since 184325324Sgordon France has had multiple time zones. 185325324Sgordon </li> 186325324Sgordon <li> 187325324Sgordon Use mainstream English spelling, e.g. prefer 188325324Sgordon '<code>Rome</code>' to '<code>Roma</code>', and prefer 189325324Sgordon '<code>Athens</code>' to the Greek 190325324Sgordon '<code>����������</code>' or the Romanized 191325324Sgordon '<code>Ath��na</code>'. 192325324Sgordon The POSIX file name restrictions encourage this rule. 193325324Sgordon </li> 194325324Sgordon <li> 195325324Sgordon Use the most populous among locations in a zone, 196325324Sgordon e.g. prefer '<code>Shanghai</code>' to 197325324Sgordon '<code>Beijing</code>'. Among locations with 198325324Sgordon similar populations, pick the best-known location, 199325324Sgordon e.g. prefer '<code>Rome</code>' to '<code>Milan</code>'. 200325324Sgordon </li> 201325324Sgordon <li> 202325324Sgordon Use the singular form, e.g. prefer '<code>Canary</code>' to '<code>Canaries</code>'. 203325324Sgordon </li> 204325324Sgordon <li> 205325324Sgordon Omit common suffixes like '<code>_Islands</code>' and 206325324Sgordon '<code>_City</code>', unless that would lead to 207325324Sgordon ambiguity. E.g. prefer '<code>Cayman</code>' to 208325324Sgordon '<code>Cayman_Islands</code>' and 209325324Sgordon '<code>Guatemala</code>' to 210325324Sgordon '<code>Guatemala_City</code>', but prefer 211325324Sgordon '<code>Mexico_City</code>' to '<code>Mexico</code>' 212325324Sgordon because the country 213325324Sgordon of Mexico has several time zones. 214325324Sgordon </li> 215325324Sgordon <li> 216325324Sgordon Use '<code>_</code>' to represent a space. 217325324Sgordon </li> 218325324Sgordon <li> 219325324Sgordon Omit '<code>.</code>' from abbreviations in names, e.g. prefer 220325324Sgordon '<code>St_Helena</code>' to '<code>St._Helena</code>'. 221325324Sgordon </li> 222325324Sgordon <li> 223325324Sgordon Do not change established names if they only marginally 224325324Sgordon violate the above rules. For example, don't change 225325324Sgordon the existing name '<code>Rome</code>' to 226325324Sgordon '<code>Milan</code>' merely because 227325324Sgordon Milan's population has grown to be somewhat greater 228325324Sgordon than Rome's. 229325324Sgordon </li> 230325324Sgordon <li> 231325324Sgordon If a name is changed, put its old spelling in the 232325324Sgordon '<code>backward</code>' file. 233325324Sgordon This means old spellings will continue to work. 234325324Sgordon </li> 235325324Sgordon</ul> 236325324Sgordon 237325324Sgordon<p> 238325324SgordonThe file '<code>zone1970.tab</code>' lists geographical locations used 239325324Sgordonto name time 240325324Sgordonzone rules. It is intended to be an exhaustive list of names for 241325324Sgordongeographic regions as described above; this is a subset of the names 242325324Sgordonin the data. Although a '<code>zone1970.tab</code>' location's longitude 243325324Sgordoncorresponds to its LMT offset with one hour for every 15 degrees east 244325324Sgordonlongitude, this relationship is not exact. 245325324Sgordon</p> 246325324Sgordon 247325324Sgordon<p> 248325324SgordonOlder versions of this package used a different naming scheme, 249325324Sgordonand these older names are still supported. 250325324SgordonSee the file '<code>backward</code>' for most of these older names 251325324Sgordon(e.g., '<code>US/Eastern</code>' instead of '<code>America/New_York</code>'). 252325324SgordonThe other old-fashioned names still supported are 253325324Sgordon'<code>WET</code>', '<code>CET</code>', '<code>MET</code>', and '<code>EET</code>' (see the file '<code>europe</code>'). 254325324Sgordon</p> 255325324Sgordon 256325324Sgordon<p> 257325324SgordonOlder versions of this package defined legacy names that are 258325324Sgordonincompatible with the first rule of location names, but which are 259325324Sgordonstill supported. These legacy names are mostly defined in the file 260325324Sgordon'<code>etcetera</code>'. Also, the file '<code>backward</code>' defines the legacy names 261325324Sgordon'<code>GMT0</code>', '<code>GMT-0</code>' and '<code>GMT+0</code>', and the file '<code>northamerica</code>' defines the 262325324Sgordonlegacy names '<code>EST5EDT</code>', '<code>CST6CDT</code>', '<code>MST7MDT</code>', and '<code>PST8PDT</code>'. 263325324Sgordon</p> 264325324Sgordon 265325324Sgordon<p> 266325324SgordonExcluding '<code>backward</code>' should not affect the other data. If 267325324Sgordon'<code>backward</code>' is excluded, excluding '<code>etcetera</code>' should not affect the 268325324Sgordonremaining data. 269325324Sgordon</p> 270325324Sgordon 271325324Sgordon 272325324Sgordon </section> 273325324Sgordon <section> 274325324Sgordon <h2 id="abbreviations">Time zone abbreviations</h2> 275325324Sgordon<p> 276325324SgordonWhen this package is installed, it generates time zone abbreviations 277325324Sgordonlike '<code>EST</code>' to be compatible with human tradition and POSIX. 278325324SgordonHere are the general rules used for choosing time zone abbreviations, 279325324Sgordonin decreasing order of importance: 280325324Sgordon<ul> 281325324Sgordon <li> 282325324Sgordon Use three or more characters that are ASCII alphanumerics or 283325324Sgordon '<code>+</code>' or '<code>-</code>'. 284325324Sgordon Previous editions of this database also used characters like 285325324Sgordon '<code> </code>' and '<code>?</code>', but these 286325324Sgordon characters have a special meaning to 287325324Sgordon the shell and cause commands like 288325324Sgordon '<code>set `date`</code>' 289325324Sgordon to have unexpected effects. 290325324Sgordon Previous editions of this rule required upper-case letters, 291325324Sgordon but the Congressman who introduced Chamorro Standard Time 292325324Sgordon preferred "ChST", so lower-case letters are now allowed. 293325324Sgordon Also, POSIX from 2001 on relaxed the rule to allow 294325324Sgordon '<code>-</code>', '<code>+</code>', 295325324Sgordon and alphanumeric characters from the portable character set 296325324Sgordon in the current locale. In practice ASCII alphanumerics and 297325324Sgordon '<code>+</code>' and '<code>-</code>' are safe in all locales. 298325324Sgordon 299325324Sgordon In other words, in the C locale the POSIX extended regular 300325324Sgordon expression <code>[-+[:alnum:]]{3,}</code> should match 301325324Sgordon the abbreviation. 302325324Sgordon This guarantees that all abbreviations could have been 303325324Sgordon specified by a POSIX TZ string. 304325324Sgordon </li> 305325324Sgordon <li> 306325324Sgordon Use abbreviations that are in common use among English-speakers, 307325324Sgordon e.g. 'EST' for Eastern Standard Time in North America. 308325324Sgordon We assume that applications translate them to other languages 309325324Sgordon as part of the normal localization process; for example, 310325324Sgordon a French application might translate 'EST' to 'HNE'. 311325324Sgordon </li> 312325324Sgordon <li> 313325324Sgordon For zones whose times are taken from a city's longitude, use the 314325324Sgordon traditional <var>x</var>MT notation, e.g. 'PMT' for 315325324Sgordon Paris Mean Time. 316325324Sgordon The only name like this in current use is 'GMT'. 317325324Sgordon </li> 318325324Sgordon <li> 319325324Sgordon Use 'LMT' for local mean time of locations before the introduction 320325324Sgordon of standard time; see "<a href="#scope">Scope of the 321325324Sgordon tz database</a>". 322325324Sgordon </li> 323325324Sgordon <li> 324325324Sgordon If there is no common English abbreviation, use numeric offsets like 325325324Sgordon <code>-</code>05 and <code>+</code>0830 that are 326325324Sgordon generated by zic's <code>%z</code> notation. 327325324Sgordon </li> 328325324Sgordon <li> 329325324Sgordon Use current abbreviations for older timestamps to avoid confusion. 330325324Sgordon For example, in 1910 a common English abbreviation for UT +01 331325324Sgordon in central Europe was 'MEZ' (short for both "Middle European 332325324Sgordon Zone" and for "Mitteleurop��ische Zeit" in German). Nowadays 333325324Sgordon 'CET' ("Central European Time") is more common in English, and 334325324Sgordon the database uses 'CET' even for circa-1910 timestamps as this 335325324Sgordon is less confusing for modern users and avoids the need for 336325324Sgordon determining when 'CET' supplanted 'MEZ' in common usage. 337325324Sgordon </li> 338325324Sgordon <li> 339325324Sgordon Use a consistent style in a zone's history. For example, if a zone's 340325324Sgordon history tends to use numeric abbreviations and a particular 341325324Sgordon entry could go either way, use a numeric abbreviation. 342325324Sgordon </li> 343325324Sgordon</ul> 344325324Sgordon [The remaining guidelines predate the introduction of <code>%z</code>. 345325324Sgordon They are problematic as they mean tz data entries invent 346325324Sgordon notation rather than record it. These guidelines are now 347325324Sgordon deprecated and the plan is to gradually move to <code>%z</code> for 348325324Sgordon inhabited locations and to "<code>-</code>00" for uninhabited locations.] 349325324Sgordon<ul> 350325324Sgordon <li> 351325324Sgordon If there is no common English abbreviation, abbreviate the English 352325324Sgordon translation of the usual phrase used by native speakers. 353325324Sgordon If this is not available or is a phrase mentioning the country 354325324Sgordon (e.g. "Cape Verde Time"), then: 355325324Sgordon <ul> 356325324Sgordon <li> 357325324Sgordon When a country is identified with a single or principal zone, 358325324Sgordon append 'T' to the country's ISO code, e.g. 'CVT' for 359325324Sgordon Cape Verde Time. For summer time append 'ST'; 360325324Sgordon for double summer time append 'DST'; etc. 361325324Sgordon </li> 362325324Sgordon <li> 363325324Sgordon Otherwise, take the first three letters of an English place 364325324Sgordon name identifying each zone and append 'T', 'ST', etc. 365325324Sgordon as before; e.g. 'CHAST' for CHAtham Summer Time. 366325324Sgordon </li> 367325324Sgordon </ul> 368325324Sgordon </li> 369325324Sgordon <li> 370325324Sgordon Use UT (with time zone abbreviation '<code>-</code>00') for 371325324Sgordon locations while uninhabited. The leading 372325324Sgordon '<code>-</code>' is a flag that the time 373325324Sgordon zone is in some sense undefined; this notation is 374325324Sgordon derived from Internet RFC 3339. 375325324Sgordon </li> 376325324Sgordon</ul> 377325324Sgordon<p> 378325324SgordonApplication writers should note that these abbreviations are ambiguous 379325324Sgordonin practice: e.g. 'CST' has a different meaning in China than 380325324Sgordonit does in the United States. In new applications, it's often better 381325324Sgordonto use numeric UT offsets like '<code>-</code>0600' instead of time zone 382325324Sgordonabbreviations like 'CST'; this avoids the ambiguity. 383325324Sgordon</p> 384325324Sgordon </section> 385325324Sgordon 386325324Sgordon 387325324Sgordon <section> 388325324Sgordon <h2 id="accuracy">Accuracy of the tz database</h2> 389325324Sgordon<p> 390325324SgordonThe tz database is not authoritative, and it surely has errors. 391325324SgordonCorrections are welcome and encouraged; see the file CONTRIBUTING. 392325324SgordonUsers requiring authoritative data should consult national standards 393325324Sgordonbodies and the references cited in the database's comments. 394325324Sgordon</p> 395325324Sgordon 396325324Sgordon<p> 397325324SgordonErrors in the tz database arise from many sources: 398325324Sgordon</p> 399325324Sgordon<ul> 400325324Sgordon <li> 401325324Sgordon The tz database predicts future timestamps, and current predictions 402325324Sgordon will be incorrect after future governments change the rules. 403325324Sgordon For example, if today someone schedules a meeting for 13:00 next 404325324Sgordon October 1, Casablanca time, and tomorrow Morocco changes its 405325324Sgordon daylight saving rules, software can mess up after the rule change 406325324Sgordon if it blithely relies on conversions made before the change. 407325324Sgordon </li> 408325324Sgordon <li> 409325324Sgordon The pre-1970 entries in this database cover only a tiny sliver of how 410325324Sgordon clocks actually behaved; the vast majority of the necessary 411325324Sgordon information was lost or never recorded. Thousands more zones would 412325324Sgordon be needed if the tz database's scope were extended to cover even 413325324Sgordon just the known or guessed history of standard time; for example, 414325324Sgordon the current single entry for France would need to split into dozens 415325324Sgordon of entries, perhaps hundreds. And in most of the world even this 416325324Sgordon approach would be misleading due to widespread disagreement or 417325324Sgordon indifference about what times should be observed. In her 2015 book 418325324Sgordon <cite>The Global Transformation of Time, 1870-1950</cite>, Vanessa Ogle writes 419325324Sgordon "Outside of Europe and North America there was no system of time 420325324Sgordon zones at all, often not even a stable landscape of mean times, 421325324Sgordon prior to the middle decades of the twentieth century". See: 422325324Sgordon Timothy Shenk, <a 423325324Sgordon href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle">Booked: 424325324Sgordon A Global History of Time</a>. <cite>Dissent</cite> 2015-12-17. 425325324Sgordon </li> 426325324Sgordon <li> 427325324Sgordon Most of the pre-1970 data entries come from unreliable sources, often 428325324Sgordon astrology books that lack citations and whose compilers evidently 429325324Sgordon invented entries when the true facts were unknown, without 430325324Sgordon reporting which entries were known and which were invented. 431325324Sgordon These books often contradict each other or give implausible entries, 432325324Sgordon and on the rare occasions when they are checked they are 433325324Sgordon typically found to be incorrect. 434325324Sgordon </li> 435325324Sgordon <li> 436325324Sgordon For the UK the tz database relies on years of first-class work done by 437325324Sgordon Joseph Myers and others; see 438325324Sgordon "<a href="https://www.polyomino.org.uk/british-time/">History of 439325324Sgordon legal time in Britain</a>". 440325324Sgordon Other countries are not done nearly as well. 441325324Sgordon </li> 442325324Sgordon <li> 443325324Sgordon Sometimes, different people in the same city would maintain clocks 444325324Sgordon that differed significantly. Railway time was used by railroad 445325324Sgordon companies (which did not always agree with each other), 446325324Sgordon church-clock time was used for birth certificates, etc. 447325324Sgordon Often this was merely common practice, but sometimes it was set by law. 448325324Sgordon For example, from 1891 to 1911 the UT offset in France was legally 449325324Sgordon 0:09:21 outside train stations and 0:04:21 inside. 450325324Sgordon </li> 451325324Sgordon <li> 452325324Sgordon Although a named location in the tz database stands for the 453325324Sgordon containing region, its pre-1970 data entries are often accurate for 454325324Sgordon only a small subset of that region. For example, <code>Europe/London</code> 455325324Sgordon stands for the United Kingdom, but its pre-1847 times are valid 456325324Sgordon only for locations that have London's exact meridian, and its 1847 457325324Sgordon transition to GMT is known to be valid only for the L&NW and the 458325324Sgordon Caledonian railways. 459325324Sgordon </li> 460325324Sgordon <li> 461325324Sgordon The tz database does not record the earliest time for which a zone's 462325324Sgordon data entries are thereafter valid for every location in the region. 463325324Sgordon For example, <code>Europe/London</code> is valid for all locations in its 464325324Sgordon region after GMT was made the standard time, but the date of 465325324Sgordon standardization (1880-08-02) is not in the tz database, other than 466325324Sgordon in commentary. For many zones the earliest time of validity is 467325324Sgordon unknown. 468325324Sgordon </li> 469325324Sgordon <li> 470325324Sgordon The tz database does not record a region's boundaries, and in many 471325324Sgordon cases the boundaries are not known. For example, the zone 472325324Sgordon <code>America/Kentucky/Louisville</code> represents a region around 473325324Sgordon the city of 474325324Sgordon Louisville, the boundaries of which are unclear. 475325324Sgordon </li> 476325324Sgordon <li> 477325324Sgordon Changes that are modeled as instantaneous transitions in the tz 478325324Sgordon database were often spread out over hours, days, or even decades. 479325324Sgordon </li> 480325324Sgordon <li> 481325324Sgordon Even if the time is specified by law, locations sometimes 482325324Sgordon deliberately flout the law. 483325324Sgordon </li> 484325324Sgordon <li> 485325324Sgordon Early timekeeping practices, even assuming perfect clocks, were 486325324Sgordon often not specified to the accuracy that the tz database requires. 487325324Sgordon </li> 488325324Sgordon <li> 489325324Sgordon Sometimes historical timekeeping was specified more precisely 490325324Sgordon than what the tz database can handle. For example, from 1909 to 491325324Sgordon 1937 Netherlands clocks were legally UT +00:19:32.13, but the tz 492325324Sgordon database cannot represent the fractional second. 493325324Sgordon </li> 494325324Sgordon <li> 495325324Sgordon Even when all the timestamp transitions recorded by the tz database 496325324Sgordon are correct, the tz rules that generate them may not faithfully 497325324Sgordon reflect the historical rules. For example, from 1922 until World 498325324Sgordon War II the UK moved clocks forward the day following the third 499325324Sgordon Saturday in April unless that was Easter, in which case it moved 500325324Sgordon clocks forward the previous Sunday. Because the tz database has no 501325324Sgordon way to specify Easter, these exceptional years are entered as 502325324Sgordon separate tz Rule lines, even though the legal rules did not change. 503325324Sgordon </li> 504325324Sgordon <li> 505325324Sgordon The tz database models pre-standard time using the proleptic Gregorian 506325324Sgordon calendar and local mean time (LMT), but many people used other 507325324Sgordon calendars and other timescales. For example, the Roman Empire used 508325324Sgordon the Julian calendar, and had 12 varying-length daytime hours with a 509325324Sgordon non-hour-based system at night. 510325324Sgordon </li> 511325324Sgordon <li> 512325324Sgordon Early clocks were less reliable, and data entries do not represent 513325324Sgordon clock error. 514325324Sgordon </li> 515325324Sgordon <li> 516325324Sgordon The tz database assumes Universal Time (UT) as an origin, even 517325324Sgordon though UT is not standardized for older timestamps. In the tz 518325324Sgordon database commentary, UT denotes a family of time standards that 519325324Sgordon includes Coordinated Universal Time (UTC) along with other variants 520325324Sgordon such as UT1 and GMT, with days starting at midnight. Although UT 521325324Sgordon equals UTC for modern timestamps, UTC was not defined until 1960, 522325324Sgordon so commentary uses the more-general abbreviation UT for timestamps 523325324Sgordon that might predate 1960. Since UT, UT1, etc. disagree slightly, 524325324Sgordon and since pre-1972 UTC seconds varied in length, interpretation of 525325324Sgordon older timestamps can be problematic when subsecond accuracy is 526325324Sgordon needed. 527325324Sgordon </li> 528325324Sgordon <li> 529325324Sgordon Civil time was not based on atomic time before 1972, and we don't 530325324Sgordon know the history of earth's rotation accurately enough to map SI 531325324Sgordon seconds to historical solar time to more than about one-hour 532325324Sgordon accuracy. See: Stephenson FR, Morrison LV, Hohenkerk CY. 533325324Sgordon <a href="http://dx.doi.org/10.1098/rspa.2016.0404">Measurement 534325324Sgordon of the Earth's rotation: 720 BC to AD 2015</a>. 535325324Sgordon <cite>Proc Royal Soc A</cite>. 2016 Dec 7;472:20160404. 536325324Sgordon Also see: Espenak F. <a 537325324Sgordon href="https://eclipse.gsfc.nasa.gov/SEhelp/uncertainty2004.html">Uncertainty 538325324Sgordon in Delta T (��T)</a>. 539325324Sgordon </li> 540325324Sgordon <li> 541325324Sgordon The relationship between POSIX time (that is, UTC but ignoring leap 542325324Sgordon seconds) and UTC is not agreed upon after 1972. Although the POSIX 543325324Sgordon clock officially stops during an inserted leap second, at least one 544325324Sgordon proposed standard has it jumping back a second instead; and in 545325324Sgordon practice POSIX clocks more typically either progress glacially during 546325324Sgordon a leap second, or are slightly slowed while near a leap second. 547325324Sgordon </li> 548325324Sgordon <li> 549325324Sgordon The tz database does not represent how uncertain its information is. 550325324Sgordon Ideally it would contain information about when data entries are 551325324Sgordon incomplete or dicey. Partial temporal knowledge is a field of 552325324Sgordon active research, though, and it's not clear how to apply it here. 553325324Sgordon </li> 554325324Sgordon</ul> 555325324Sgordon<p> 556325324SgordonIn short, many, perhaps most, of the tz database's pre-1970 and future 557325324Sgordontimestamps are either wrong or misleading. Any attempt to pass the 558325324Sgordontz database off as the definition of time should be unacceptable to 559325324Sgordonanybody who cares about the facts. In particular, the tz database's 560325324SgordonLMT offsets should not be considered meaningful, and should not prompt 561325324Sgordoncreation of zones merely because two locations differ in LMT or 562325324Sgordontransitioned to standard time at different dates. 563325324Sgordon</p> 564325324Sgordon </section> 565325324Sgordon 566325324Sgordon 567325324Sgordon <section> 568325324Sgordon <h2 id="functions">Time and date functions</h2> 569325324Sgordon<p> 570325324SgordonThe tz code contains time and date functions that are upwards 571325324Sgordoncompatible with those of POSIX. 572325324Sgordon</p> 573325324Sgordon 574325324Sgordon<p> 575325324SgordonPOSIX has the following properties and limitations. 576325324Sgordon</p> 577325324Sgordon<ul> 578325324Sgordon <li> 579325324Sgordon <p> 580325324Sgordon In POSIX, time display in a process is controlled by the 581325324Sgordon environment variable TZ. Unfortunately, the POSIX TZ string takes 582325324Sgordon a form that is hard to describe and is error-prone in practice. 583325324Sgordon Also, POSIX TZ strings can't deal with other (for example, Israeli) 584325324Sgordon daylight saving time rules, or situations where more than two 585325324Sgordon time zone abbreviations are used in an area. 586325324Sgordon </p> 587325324Sgordon <p> 588325324Sgordon The POSIX TZ string takes the following form: 589325324Sgordon </p> 590325324Sgordon <p> 591325324Sgordon <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>]]] 592325324Sgordon </p> 593325324Sgordon <p> 594325324Sgordon where: 595325324Sgordon <dl> 596325324Sgordon <dt><var>std</var> and <var>dst</var></dt><dd> 597325324Sgordon are 3 or more characters specifying the standard 598325324Sgordon and daylight saving time (DST) zone names. 599325324Sgordon Starting with POSIX.1-2001, <var>std</var> 600325324Sgordon and <var>dst</var> may also be 601325324Sgordon in a quoted form like '<code><UTC+10></code>'; this allows 602325324Sgordon "<code>+</code>" and "<code>-</code>" in the names. 603325324Sgordon </dd> 604325324Sgordon <dt><var>offset</var></dt><dd> 605325324Sgordon is of the form 606325324Sgordon '<code>[±]<var>hh</var>:[<var>mm</var>[:<var>ss</var>]]</code>' 607325324Sgordon and specifies the offset west of UT. '<var>hh</var>' 608325324Sgordon may be a single digit; 0≤<var>hh</var>≤24. 609325324Sgordon The default DST offset is one hour ahead of standard time. 610325324Sgordon </dd> 611325324Sgordon <dt><var>date</var>[<code>/</code><var>time</var>]<code>,</code><var>date</var>[<code>/</code><var>time</var>]</dt><dd> 612325324Sgordon specifies the beginning and end of DST. If this is absent, 613325324Sgordon the system supplies its own rules for DST, and these can 614325324Sgordon differ from year to year; typically US DST rules are used. 615325324Sgordon </dd> 616325324Sgordon <dt><var>time</var></dt><dd> 617325324Sgordon takes the form 618325324Sgordon '<var>hh</var><code>:</code>[<var>mm</var>[<code>:</code><var>ss</var>]]' 619325324Sgordon and defaults to 02:00. 620325324Sgordon This is the same format as the offset, except that a 621325324Sgordon leading '<code>+</code>' or '<code>-</code>' is not allowed. 622325324Sgordon </dd> 623325324Sgordon <dt><var>date</var></dt><dd> 624325324Sgordon takes one of the following forms: 625325324Sgordon <dl> 626325324Sgordon <dt>J<var>n</var> (1≤<var>n</var>≤365)</dt><dd> 627325324Sgordon origin-1 day number not counting February 29 628325324Sgordon </dd> 629325324Sgordon <dt><var>n</var> (0≤<var>n</var>≤365)</dt><dd> 630325324Sgordon origin-0 day number counting February 29 if present 631325324Sgordon </dd> 632325324Sgordon <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> 633325324Sgordon for the <var>d</var>th day of 634325324Sgordon week <var>n</var> of month <var>m</var> of the 635325324Sgordon year, where week 1 is the first week in which 636325324Sgordon day <var>d</var> appears, and '<code>5</code>' 637325324Sgordon stands for the last week in which 638325324Sgordon day <var>d</var> appears 639325324Sgordon (which may be either the 4th or 5th week). 640325324Sgordon Typically, this is the only useful form; 641325324Sgordon the <var>n</var> 642325324Sgordon and <code>J</code><var>n</var> forms are 643325324Sgordon rarely used. 644325324Sgordon </dd> 645325324Sgordon</dl> 646325324Sgordon</dd> 647325324Sgordon</dl> 648325324Sgordon Here is an example POSIX TZ string for New Zealand after 2007. 649325324Sgordon It says that standard time (NZST) is 12 hours ahead of UTC, 650325324Sgordon and that daylight saving time (NZDT) is observed from September's 651325324Sgordon last Sunday at 02:00 until April's first Sunday at 03:00: 652325324Sgordon 653325324Sgordon <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre> 654325324Sgordon 655325324Sgordon This POSIX TZ string is hard to remember, and mishandles some 656325324Sgordon timestamps before 2008. With this package you can use this 657325324Sgordon instead: 658325324Sgordon 659325324Sgordon <pre><code>TZ='Pacific/Auckland'</code></pre> 660325324Sgordon </li> 661325324Sgordon <li> 662325324Sgordon POSIX does not define the exact meaning of TZ values like 663325324Sgordon "<code>EST5EDT</code>". 664325324Sgordon Typically the current US DST rules are used to interpret such values, 665325324Sgordon but this means that the US DST rules are compiled into each program 666325324Sgordon that does time conversion. This means that when US time conversion 667325324Sgordon rules change (as in the United States in 1987), all programs that 668325324Sgordon do time conversion must be recompiled to ensure proper results. 669325324Sgordon </li> 670325324Sgordon <li> 671325324Sgordon The TZ environment variable is process-global, which makes it hard 672325324Sgordon to write efficient, thread-safe applications that need access 673325324Sgordon to multiple time zones. 674325324Sgordon </li> 675325324Sgordon <li> 676325324Sgordon In POSIX, there's no tamper-proof way for a process to learn the 677325324Sgordon system's best idea of local wall clock. (This is important for 678325324Sgordon applications that an administrator wants used only at certain 679325324Sgordon times – 680325324Sgordon without regard to whether the user has fiddled the TZ environment 681325324Sgordon variable. While an administrator can "do everything in UTC" to get 682325324Sgordon around the problem, doing so is inconvenient and precludes handling 683325324Sgordon daylight saving time shifts - as might be required to limit phone 684325324Sgordon calls to off-peak hours.) 685325324Sgordon </li> 686325324Sgordon <li> 687325324Sgordon POSIX provides no convenient and efficient way to determine the UT 688325324Sgordon offset and time zone abbreviation of arbitrary timestamps, 689325324Sgordon particularly for time zone settings that do not fit into the 690325324Sgordon POSIX model. 691325324Sgordon </li> 692325324Sgordon <li> 693325324Sgordon POSIX requires that systems ignore leap seconds. 694325324Sgordon </li> 695325324Sgordon <li> 696325324Sgordon The tz code attempts to support all the <code>time_t</code> 697325324Sgordon implementations allowed by POSIX. The <code>time_t</code> 698325324Sgordon type represents a nonnegative count of 699325324Sgordon seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. 700325324Sgordon In practice, <code>time_t</code> is usually a signed 64- or 701325324Sgordon 32-bit integer; 32-bit signed <code>time_t</code> values stop 702325324Sgordon working after 2038-01-19 03:14:07 UTC, so 703325324Sgordon new implementations these days typically use a signed 64-bit integer. 704325324Sgordon Unsigned 32-bit integers are used on one or two platforms, 705325324Sgordon and 36-bit and 40-bit integers are also used occasionally. 706325324Sgordon Although earlier POSIX versions allowed <code>time_t</code> to be a 707325324Sgordon floating-point type, this was not supported by any practical 708325324Sgordon systems, and POSIX.1-2013 and the tz code both 709325324Sgordon require <code>time_t</code> 710325324Sgordon to be an integer type. 711325324Sgordon </li> 712325324Sgordon</ul> 713325324Sgordon<p> 714325324SgordonThese are the extensions that have been made to the POSIX functions: 715325324Sgordon</p> 716325324Sgordon<ul> 717325324Sgordon <li> 718325324Sgordon <p> 719325324Sgordon The TZ environment variable is used in generating the name of a file 720325324Sgordon from which time zone information is read (or is interpreted a la 721325324Sgordon POSIX); TZ is no longer constrained to be a three-letter time zone 722325324Sgordon name followed by a number of hours and an optional three-letter 723325324Sgordon daylight time zone name. The daylight saving time rules to be used 724325324Sgordon for a particular time zone are encoded in the time zone file; 725325324Sgordon the format of the file allows U.S., Australian, and other rules to be 726325324Sgordon encoded, and allows for situations where more than two time zone 727325324Sgordon abbreviations are used. 728325324Sgordon </p> 729325324Sgordon <p> 730325324Sgordon It was recognized that allowing the TZ environment variable to 731325324Sgordon take on values such as '<code>America/New_York</code>' might 732325324Sgordon cause "old" programs 733325324Sgordon (that expect TZ to have a certain form) to operate incorrectly; 734325324Sgordon consideration was given to using some other environment variable 735325324Sgordon (for example, TIMEZONE) to hold the string used to generate the 736325324Sgordon time zone information file name. In the end, however, it was decided 737325324Sgordon to continue using TZ: it is widely used for time zone purposes; 738325324Sgordon separately maintaining both TZ and TIMEZONE seemed a nuisance; 739325324Sgordon and systems where "new" forms of TZ might cause problems can simply 740325324Sgordon use TZ values such as "<code>EST5EDT</code>" which can be used both by 741325324Sgordon "new" programs (a la POSIX) and "old" programs (as zone names and 742325324Sgordon offsets). 743325324Sgordon </p> 744325324Sgordon</li> 745325324Sgordon<li> 746325324Sgordon The code supports platforms with a UT offset member 747325324Sgordon in <code>struct tm</code>, 748325324Sgordon e.g., <code>tm_gmtoff</code>. 749325324Sgordon</li> 750325324Sgordon<li> 751325324Sgordon The code supports platforms with a time zone abbreviation member in 752325324Sgordon <code>struct tm</code>, e.g., <code>tm_zone</code>. 753325324Sgordon</li> 754325324Sgordon<li> 755325324Sgordon Since the TZ environment variable can now be used to control time 756325324Sgordon conversion, the <code>daylight</code> 757325324Sgordon and <code>timezone</code> variables are no longer needed. 758325324Sgordon (These variables are defined and set by <code>tzset</code>; 759325324Sgordon however, their values will not be used 760325324Sgordon by <code>localtime</code>.) 761325324Sgordon</li> 762325324Sgordon<li> 763325324Sgordon Functions <code>tzalloc</code>, <code>tzfree</code>, 764325324Sgordon <code>localtime_rz</code>, and <code>mktime_z</code> for 765325324Sgordon more-efficient thread-safe applications that need to use 766325324Sgordon multiple time zones. The <code>tzalloc</code> 767325324Sgordon and <code>tzfree</code> functions allocate and free objects of 768325324Sgordon type <code>timezone_t</code>, and <code>localtime_rz</code> 769325324Sgordon and <code>mktime_z</code> are like <code>localtime_r</code> 770325324Sgordon and <code>mktime</code> with an extra 771325324Sgordon <code>timezone_t</code> argument. The functions were inspired 772325324Sgordon by NetBSD. 773325324Sgordon</li> 774325324Sgordon<li> 775325324Sgordon A function <code>tzsetwall</code> has been added to arrange 776325324Sgordon for the system's 777325324Sgordon best approximation to local wall clock time to be delivered by 778325324Sgordon subsequent calls to <code>localtime</code>. Source code for portable 779325324Sgordon applications that "must" run on local wall clock time should call 780325324Sgordon <code>tzsetwall</code>; if such code is moved to "old" systems that don't 781325324Sgordon provide tzsetwall, you won't be able to generate an executable program. 782325324Sgordon (These time zone functions also arrange for local wall clock time to be 783325324Sgordon used if tzset is called – directly or indirectly – 784325324Sgordon and there's no TZ 785325324Sgordon environment variable; portable applications should not, however, rely 786325324Sgordon on this behavior since it's not the way SVR2 systems behave.) 787325324Sgordon</li> 788325324Sgordon<li> 789325324Sgordon Negative <code>time_t</code> values are supported, on systems 790325324Sgordon where <code>time_t</code> is signed. 791325324Sgordon</li> 792325324Sgordon<li> 793325324Sgordon These functions can account for leap seconds, thanks to Bradley White. 794325324Sgordon</li> 795325324Sgordon</ul> 796325324Sgordon<p> 797325324SgordonPoints of interest to folks with other systems: 798325324Sgordon</p> 799325324Sgordon<ul> 800325324Sgordon <li> 801325324Sgordon Code compatible with this package is already part of many platforms, 802325324Sgordon including GNU/Linux, Android, the BSDs, Chromium OS, Cygwin, AIX, iOS, 803325324Sgordon BlackBery 10, macOS, Microsoft Windows, OpenVMS, and Solaris. 804325324Sgordon On such hosts, the primary use of this package 805325324Sgordon is to update obsolete time zone rule tables. 806325324Sgordon To do this, you may need to compile the time zone compiler 807325324Sgordon '<code>zic</code>' supplied with this package instead of using 808325324Sgordon the system '<code>zic</code>', since the format 809325324Sgordon of <code>zic</code>'s input is occasionally extended, and a 810325324Sgordon platform may still be shipping an older <code>zic</code>. 811325324Sgordon </li> 812325324Sgordon <li> 813325324Sgordon The UNIX Version 7 <code>timezone</code> function is not 814325324Sgordon present in this package; 815325324Sgordon it's impossible to reliably map timezone's arguments (a "minutes west 816325324Sgordon of GMT" value and a "daylight saving time in effect" flag) to a 817325324Sgordon time zone abbreviation, and we refuse to guess. 818325324Sgordon Programs that in the past used the timezone function may now examine 819325324Sgordon <code>localtime(&clock)->tm_zone</code> 820325324Sgordon (if <code>TM_ZONE</code> is defined) or 821325324Sgordon <code>tzname[localtime(&clock)->tm_isdst]</code> 822325324Sgordon (if <code>HAVE_TZNAME</code> is defined) 823325324Sgordon to learn the correct time zone abbreviation to use. 824325324Sgordon </li> 825325324Sgordon <li> 826325324Sgordon The 4.2BSD <code>gettimeofday</code> function is not used in 827325324Sgordon this package. 828325324Sgordon This formerly let users obtain the current UTC offset and DST flag, 829325324Sgordon but this functionality was removed in later versions of BSD. 830325324Sgordon </li> 831325324Sgordon <li> 832325324Sgordon In SVR2, time conversion fails for near-minimum or near-maximum 833325324Sgordon <code>time_t</code> values when doing conversions for places 834325324Sgordon that don't use UT. 835325324Sgordon This package takes care to do these conversions correctly. 836325324Sgordon A comment in the source code tells how to get compatibly wrong 837325324Sgordon results. 838325324Sgordon </li> 839325324Sgordon</ul> 840325324Sgordon<p> 841325324SgordonThe functions that are conditionally compiled 842325324Sgordonif <code>STD_INSPIRED</code> is defined 843325324Sgordonshould, at this point, be looked on primarily as food for thought. They are 844325324Sgordonnot in any sense "standard compatible" – some are not, in fact, 845325324Sgordonspecified in <em>any</em> standard. They do, however, represent responses of 846325324Sgordonvarious authors to 847325324Sgordonstandardization proposals. 848325324Sgordon</p> 849325324Sgordon 850325324Sgordon<p> 851325324SgordonOther time conversion proposals, in particular the one developed by folks at 852325324SgordonHewlett Packard, offer a wider selection of functions that provide capabilities 853325324Sgordonbeyond those provided here. The absence of such functions from this package 854325324Sgordonis not meant to discourage the development, standardization, or use of such 855325324Sgordonfunctions. Rather, their absence reflects the decision to make this package 856325324Sgordoncontain valid extensions to POSIX, to ensure its broad acceptability. If 857325324Sgordonmore powerful time conversion functions can be standardized, so much the 858325324Sgordonbetter. 859325324Sgordon</p> 860325324Sgordon </section> 861325324Sgordon 862325324Sgordon 863325324Sgordon <section> 864325324Sgordon <h2 id="stability">Interface stability</h2> 865325324Sgordon<p> 866325324SgordonThe tz code and data supply the following interfaces: 867325324Sgordon</p> 868325324Sgordon<ul> 869325324Sgordon <li> 870325324Sgordon A set of zone names as per "<a href="#naming">Names of time zone 871325324Sgordon rules</a>" above. 872325324Sgordon </li> 873325324Sgordon <li> 874325324Sgordon Library functions described in "<a href="#functions">Time and date 875325324Sgordon functions</a>" above. 876325324Sgordon </li> 877325324Sgordon <li> 878325324Sgordon The programs <code>tzselect</code>, <code>zdump</code>, 879325324Sgordon and <code>zic</code>, documented in their man pages. 880325324Sgordon </li> 881325324Sgordon <li> 882325324Sgordon The format of <code>zic</code> input files, documented in 883325324Sgordon the <code>zic</code> man page. 884325324Sgordon </li> 885325324Sgordon <li> 886325324Sgordon The format of <code>zic</code> output files, documented in 887325324Sgordon the <code>tzfile</code> man page. 888325324Sgordon </li> 889325324Sgordon <li> 890325324Sgordon The format of zone table files, documented in <code>zone1970.tab</code>. 891325324Sgordon </li> 892325324Sgordon <li> 893325324Sgordon The format of the country code file, documented in <code>iso3166.tab</code>. 894325324Sgordon </li> 895325324Sgordon <li> 896325324Sgordon The version number of the code and data, as the first line of 897325324Sgordon the text file '<code>version</code>' in each release. 898325324Sgordon </li> 899325324Sgordon</ul> 900325324Sgordon<p> 901325324SgordonInterface changes in a release attempt to preserve compatibility with 902325324Sgordonrecent releases. For example, tz data files typically do not rely on 903325324Sgordonrecently-added <code>zic</code> features, so that users can run 904325324Sgordonolder <code>zic</code> versions to process newer data 905325324Sgordonfiles. <a href="tz-link.htm">Sources for time zone and daylight 906325324Sgordonsaving time data</a> describes how 907325324Sgordonreleases are tagged and distributed. 908325324Sgordon</p> 909325324Sgordon 910325324Sgordon<p> 911325324SgordonInterfaces not listed above are less stable. For example, users 912325324Sgordonshould not rely on particular UT offsets or abbreviations for 913325324Sgordontimestamps, as data entries are often based on guesswork and these 914325324Sgordonguesses may be corrected or improved. 915325324Sgordon</p> 916325324Sgordon </section> 917325324Sgordon 918325324Sgordon 919325324Sgordon <section> 920325324Sgordon <h2 id="calendar">Calendrical issues</h2> 921325324Sgordon<p> 922325324SgordonCalendrical issues are a bit out of scope for a time zone database, 923325324Sgordonbut they indicate the sort of problems that we would run into if we 924325324Sgordonextended the time zone database further into the past. An excellent 925325324Sgordonresource in this area is Nachum Dershowitz and Edward M. Reingold, 926325324Sgordon<cite><a href="https://www.cs.tau.ac.il/~nachum/calendar-book/third-edition/">Calendrical 927325324SgordonCalculations: Third Edition</a></cite>, Cambridge University Press (2008). 928325324SgordonOther information and sources are given in the file '<samp>calendars</samp>' 929325324Sgordonin the tz distribution. They sometimes disagree. 930325324Sgordon</p> 931325324Sgordon </section> 932325324Sgordon 933325324Sgordon 934325324Sgordon <section> 935325324Sgordon <h2 id="planets">Time and time zones on other planets</h2> 936325324Sgordon<p> 937325324SgordonSome people's work schedules use Mars time. Jet Propulsion Laboratory 938325324Sgordon(JPL) coordinators have kept Mars time on and off at least since 1997 939325324Sgordonfor the Mars Pathfinder mission. Some of their family members have 940325324Sgordonalso adapted to Mars time. Dozens of special Mars watches were built 941325324Sgordonfor JPL workers who kept Mars time during the Mars Exploration 942325324SgordonRovers mission (2004). These timepieces look like normal Seikos and 943325324SgordonCitizens but use Mars seconds rather than terrestrial seconds. 944325324Sgordon</p> 945325324Sgordon 946325324Sgordon<p> 947325324SgordonA Mars solar day is called a "sol" and has a mean period equal to 948325324Sgordonabout 24 hours 39 minutes 35.244 seconds in terrestrial time. It is 949325324Sgordondivided into a conventional 24-hour clock, so each Mars second equals 950325324Sgordonabout 1.02749125 terrestrial seconds. 951325324Sgordon</p> 952325324Sgordon 953325324Sgordon<p> 954325324SgordonThe prime meridian of Mars goes through the center of the crater 955325324SgordonAiry-0, named in honor of the British astronomer who built the 956325324SgordonGreenwich telescope that defines Earth's prime meridian. Mean solar 957325324Sgordontime on the Mars prime meridian is called Mars Coordinated Time (MTC). 958325324Sgordon</p> 959325324Sgordon 960325324Sgordon<p> 961325324SgordonEach landed mission on Mars has adopted a different reference for 962325324Sgordonsolar time keeping, so there is no real standard for Mars time zones. 963325324SgordonFor example, the Mars Exploration Rover project (2004) defined two 964325324Sgordontime zones "Local Solar Time A" and "Local Solar Time B" for its two 965325324Sgordonmissions, each zone designed so that its time equals local true solar 966325324Sgordontime at approximately the middle of the nominal mission. Such a "time 967325324Sgordonzone" is not particularly suited for any application other than the 968325324Sgordonmission itself. 969325324Sgordon</p> 970325324Sgordon 971325324Sgordon<p> 972325324SgordonMany calendars have been proposed for Mars, but none have achieved 973325324Sgordonwide acceptance. Astronomers often use Mars Sol Date (MSD) which is a 974325324Sgordonsequential count of Mars solar days elapsed since about 1873-12-29 975325324Sgordon12:00 GMT. 976325324Sgordon</p> 977325324Sgordon 978325324Sgordon<p> 979325324SgordonIn our solar system, Mars is the planet with time and calendar most 980325324Sgordonlike Earth's. On other planets, Sun-based time and calendars would 981325324Sgordonwork quite differently. For example, although Mercury's sidereal 982325324Sgordonrotation period is 58.646 Earth days, Mercury revolves around the Sun 983325324Sgordonso rapidly that an observer on Mercury's equator would see a sunrise 984325324Sgordononly every 175.97 Earth days, i.e., a Mercury year is 0.5 of a Mercury 985325324Sgordonday. Venus is more complicated, partly because its rotation is 986325324Sgordonslightly retrograde: its year is 1.92 of its days. Gas giants like 987325324SgordonJupiter are trickier still, as their polar and equatorial regions 988325324Sgordonrotate at different rates, so that the length of a day depends on 989325324Sgordonlatitude. This effect is most pronounced on Neptune, where the day is 990325324Sgordonabout 12 hours at the poles and 18 hours at the equator. 991325324Sgordon</p> 992325324Sgordon 993325324Sgordon<p> 994325324SgordonAlthough the tz database does not support time on other planets, it is 995325324Sgordondocumented here in the hopes that support will be added eventually. 996325324Sgordon</p> 997325324Sgordon 998325324Sgordon<p> 999325324SgordonSources: 1000325324Sgordon</p> 1001325324Sgordon<ul> 1002325324Sgordon <li> 1003325324SgordonMichael Allison and Robert Schmunk, 1004325324Sgordon"<a href="https://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical 1005325324SgordonNotes on Mars Solar Time as Adopted by the Mars24 Sunclock</a>" 1006325324Sgordon(2012-08-08). 1007325324Sgordon </li> 1008325324Sgordon <li> 1009325324SgordonJia-Rui Chong, 1010325324Sgordon"<a href="http://articles.latimes.com/2004/jan/14/science/sci-marstime14">Workdays 1011325324SgordonFit for a Martian</a>", Los Angeles Times 1012325324Sgordon(2004-01-14), pp A1, A20-A21. 1013325324Sgordon </li> 1014325324Sgordon <li> 1015325324SgordonTom Chmielewski, 1016325324Sgordon"<a href="https://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/">Jet 1017325324SgordonLag Is Worse on Mars</a>", The Atlantic (2015-02-26) 1018325324Sgordon </li> 1019325324Sgordon <li> 1020325324SgordonMatt Williams, 1021325324Sgordon"<a href="https://www.universetoday.com/37481/days-of-the-planets/">How 1022325324Sgordonlong is a day on the other planets of the solar system?</a>" 1023325324Sgordon(2017-04-27). 1024325324Sgordon </li> 1025325324Sgordon</ul> 1026325324Sgordon </section> 1027325324Sgordon 1028325324Sgordon <footer> 1029325324Sgordon <hr> 1030325324SgordonThis file is in the public domain, so clarified as of 2009-05-17 by 1031325324SgordonArthur David Olson. 1032325324Sgordon </footer> 1033325324Sgordon</body> 1034325324Sgordon</html> 1035