+++ /dev/null
-# $NetBSD: Theory,v 1.8 2004/05/27 20:39:49 kleink Exp $\r
-@(#)Theory 7.15\r
-\r
-\r
------ Outline -----\r
-\r
- Time and date functions\r
- Names of time zone regions\r
- Time zone abbreviations\r
- Calendrical issues\r
- Time and time zones on Mars\r
-\r
-\r
------ Time and date functions -----\r
-\r
-These time and date functions are upwards compatible with POSIX.1,\r
-an international standard for UNIX-like systems.\r
-As of this writing, the current edition of POSIX.1 is:\r
-\r
- Information technology --Portable Operating System Interface (POSIX (R))\r
- -- Part 1: System Application Program Interface (API) [C Language]\r
- ISO/IEC 9945-1:1996\r
- ANSI/IEEE Std 1003.1, 1996 Edition\r
- 1996-07-12\r
-\r
-POSIX.1 has the following properties and limitations.\r
-\r
-* In POSIX.1, time display in a process is controlled by the\r
- environment variable TZ. Unfortunately, the POSIX.1 TZ string takes\r
- a form that is hard to describe and is error-prone in practice.\r
- Also, POSIX.1 TZ strings can't deal with other (for example, Israeli)\r
- daylight saving time rules, or situations where more than two\r
- time zone abbreviations are used in an area.\r
-\r
- The POSIX.1 TZ string takes the following form:\r
-\r
- stdoffset[dst[offset],date[/time],date[/time]]\r
-\r
- where:\r
-\r
- std and dst\r
- are 3 or more characters specifying the standard\r
- and daylight saving time (DST) zone names.\r
- offset\r
- is of the form `[-]hh:[mm[:ss]]' and specifies the\r
- offset west of UTC. The default DST offset is one hour\r
- ahead of standard time.\r
- date[/time],date[/time]\r
- specifies the beginning and end of DST. If this is absent,\r
- the system supplies its own rules for DST, and these can\r
- differ from year to year; typically US DST rules are used.\r
- time\r
- takes the form `hh:[mm[:ss]]' and defaults to 02:00.\r
- date\r
- takes one of the following forms:\r
- Jn (1<=n<=365)\r
- origin-1 day number not counting February 29\r
- n (0<=n<=365)\r
- origin-0 day number counting February 29 if present\r
- Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12)\r
- for the dth day of week n of month m of the year,\r
- where week 1 is the first week in which day d appears,\r
- and `5' stands for the last week in which day d appears\r
- (which may be either the 4th or 5th week).\r
-\r
-* In POSIX.1, when a TZ value like "EST5EDT" is parsed,\r
- typically the current US DST rules are used,\r
- but this means that the US DST rules are compiled into each program\r
- that does time conversion. This means that when US time conversion\r
- rules change (as in the United States in 1987), all programs that\r
- do time conversion must be recompiled to ensure proper results.\r
-\r
-* In POSIX.1, there's no tamper-proof way for a process to learn the\r
- system's best idea of local wall clock. (This is important for\r
- applications that an administrator wants used only at certain times--\r
- without regard to whether the user has fiddled the "TZ" environment\r
- variable. While an administrator can "do everything in UTC" to get\r
- around the problem, doing so is inconvenient and precludes handling\r
- daylight saving time shifts--as might be required to limit phone\r
- calls to off-peak hours.)\r
-\r
-* POSIX.1 requires that systems ignore leap seconds.\r
-\r
-These are the extensions that have been made to the POSIX.1 functions:\r
-\r
-* The "TZ" environment variable is used in generating the name of a file\r
- from which time zone information is read (or is interpreted a la\r
- POSIX); "TZ" is no longer constrained to be a three-letter time zone\r
- name followed by a number of hours and an optional three-letter\r
- daylight time zone name. The daylight saving time rules to be used\r
- for a particular time zone are encoded in the time zone file;\r
- the format of the file allows U.S., Australian, and other rules to be\r
- encoded, and allows for situations where more than two time zone\r
- abbreviations are used.\r
-\r
- It was recognized that allowing the "TZ" environment variable to\r
- take on values such as "America/New_York" might cause "old" programs\r
- (that expect "TZ" to have a certain form) to operate incorrectly;\r
- consideration was given to using some other environment variable\r
- (for example, "TIMEZONE") to hold the string used to generate the\r
- time zone information file name. In the end, however, it was decided\r
- to continue using "TZ": it is widely used for time zone purposes;\r
- separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance;\r
- and systems where "new" forms of "TZ" might cause problems can simply\r
- use TZ values such as "EST5EDT" which can be used both by\r
- "new" programs (a la POSIX) and "old" programs (as zone names and\r
- offsets).\r
-\r
-* To handle places where more than two time zone abbreviations are used,\r
- the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst]\r
- (where "tmp" is the value the function returns) to the time zone\r
- abbreviation to be used. This differs from POSIX.1, where the elements\r
- of tzname are only changed as a result of calls to tzset.\r
-\r
-* Since the "TZ" environment variable can now be used to control time\r
- conversion, the "daylight" and "timezone" variables are no longer\r
- needed. (These variables are defined and set by "tzset"; however, their\r
- values will not be used by "localtime.")\r
-\r
-* The "localtime" function has been set up to deliver correct results\r
- for near-minimum or near-maximum time_t values. (A comment in the\r
- source code tells how to get compatibly wrong results).\r
-\r
-* A function "tzsetwall" has been added to arrange for the system's\r
- best approximation to local wall clock time to be delivered by\r
- subsequent calls to "localtime." Source code for portable\r
- applications that "must" run on local wall clock time should call\r
- "tzsetwall();" if such code is moved to "old" systems that don't\r
- provide tzsetwall, you won't be able to generate an executable program.\r
- (These time zone functions also arrange for local wall clock time to be\r
- used if tzset is called--directly or indirectly--and there's no "TZ"\r
- environment variable; portable applications should not, however, rely\r
- on this behavior since it's not the way SVR2 systems behave.)\r
-\r
-* These functions can account for leap seconds, thanks to Bradley White\r
- (bww@k.cs.cmu.edu).\r
-\r
-Points of interest to folks with other systems:\r
-\r
-* This package is already part of many POSIX-compliant hosts,\r
- including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun.\r
- On such hosts, the primary use of this package\r
- is to update obsolete time zone rule tables.\r
- To do this, you may need to compile the time zone compiler\r
- `zic' supplied with this package instead of using the system `zic',\r
- since the format of zic's input changed slightly in late 1994,\r
- and many vendors still do not support the new input format.\r
-\r
-* The UNIX Version 7 "timezone" function is not present in this package;\r
- it's impossible to reliably map timezone's arguments (a "minutes west\r
- of GMT" value and a "daylight saving time in effect" flag) to a\r
- time zone abbreviation, and we refuse to guess.\r
- Programs that in the past used the timezone function may now examine\r
- tzname[localtime(&clock)->tm_isdst] to learn the correct time\r
- zone abbreviation to use. Alternatively, use\r
- localtime(&clock)->tm_zone if this has been enabled.\r
-\r
-* The 4.2BSD gettimeofday function is not used in this package.\r
- This formerly let users obtain the current UTC offset and DST flag,\r
- but this functionality was removed in later versions of BSD.\r
-\r
-* In SVR2, time conversion fails for near-minimum or near-maximum\r
- time_t values when doing conversions for places that don't use UTC.\r
- This package takes care to do these conversions correctly.\r
-\r
-The functions that are conditionally compiled if STD_INSPIRED is defined\r
-should, at this point, be looked on primarily as food for thought. They are\r
-not in any sense "standard compatible"--some are not, in fact, specified in\r
-*any* standard. They do, however, represent responses of various authors to\r
-standardization proposals.\r
-\r
-Other time conversion proposals, in particular the one developed by folks at\r
-Hewlett Packard, offer a wider selection of functions that provide capabilities\r
-beyond those provided here. The absence of such functions from this package\r
-is not meant to discourage the development, standardization, or use of such\r
-functions. Rather, their absence reflects the decision to make this package\r
-contain valid extensions to POSIX.1, to ensure its broad\r
-acceptability. If more powerful time conversion functions can be standardized,\r
-so much the better.\r
-\r
-\r
------ Names of time zone rule files -----\r
-\r
-The time zone rule file naming conventions attempt to strike a balance\r
-among the following goals:\r
-\r
- * Uniquely identify every national region where clocks have all\r
- agreed since 1970. This is essential for the intended use: static\r
- clocks keeping local civil time.\r
-\r
- * Indicate to humans as to where that region is. This simplifes use.\r
-\r
- * Be robust in the presence of political changes. This reduces the\r
- number of updates and backward-compatibility hacks. For example,\r
- names of countries are ordinarily not used, to avoid\r
- incompatibilities when countries change their name\r
- (e.g. Zaire->Congo) or when locations change countries\r
- (e.g. Hong Kong from UK colony to China).\r
-\r
- * Be portable to a wide variety of implementations.\r
- This promotes use of the technology.\r
-\r
- * Use a consistent naming convention over the entire world.\r
- This simplifies both use and maintenance.\r
-\r
-This naming convention is not intended for use by inexperienced users\r
-to select TZ values by themselves (though they can of course examine\r
-and reuse existing settings). Distributors should provide\r
-documentation and/or a simple selection interface that explains the\r
-names; see the 'tzselect' program supplied with this distribution for\r
-one example.\r
-\r
-Names normally have the form AREA/LOCATION, where AREA is the name\r
-of a continent or ocean, and LOCATION is the name of a specific\r
-location within that region. North and South America share the same\r
-area, `America'. Typical names are `Africa/Cairo', `America/New_York',\r
-and `Pacific/Honolulu'.\r
-\r
-Here are the general rules used for choosing location names,\r
-in decreasing order of importance:\r
-\r
- Use only valid POSIX file name components (i.e., the parts of\r
- names other than `/'). Within a file name component,\r
- use only ASCII letters, `.', `-' and `_'. Do not use\r
- digits, as that might create an ambiguity with POSIX\r
- TZ strings. A file name component must not exceed 14\r
- characters or start with `-'. E.g., prefer `Brunei'\r
- to `Bandar_Seri_Begawan'.\r
- Include at least one location per time zone rule set per country.\r
- One such location is enough. Use ISO 3166 (see the file\r
- iso3166.tab) to help decide whether something is a country.\r
- If all the clocks in a country's region have agreed since 1970,\r
- don't bother to include more than one location\r
- even if subregions' clocks disagreed before 1970.\r
- Otherwise these tables would become annoyingly large.\r
- If a name is ambiguous, use a less ambiguous alternative;\r
- e.g. many cities are named San Jose and Georgetown, so\r
- prefer `Costa_Rica' to `San_Jose' and `Guyana' to `Georgetown'.\r
- Keep locations compact. Use cities or small islands, not countries\r
- or regions, so that any future time zone changes do not split\r
- locations into different time zones. E.g. prefer `Paris'\r
- to `France', since France has had multiple time zones.\r
- Use mainstream English spelling, e.g. prefer `Rome' to `Roma', and\r
- prefer `Athens' to the true name (which uses Greek letters).\r
- The POSIX file name restrictions encourage this rule.\r
- Use the most populous among locations in a country's time zone,\r
- e.g. prefer `Shanghai' to `Beijing'. Among locations with\r
- similar populations, pick the best-known location,\r
- e.g. prefer `Rome' to `Milan'.\r
- Use the singular form, e.g. prefer `Canary' to `Canaries'.\r
- Omit common suffixes like `_Islands' and `_City', unless that\r
- would lead to ambiguity. E.g. prefer `Cayman' to\r
- `Cayman_Islands' and `Guatemala' to `Guatemala_City',\r
- but prefer `Mexico_City' to `Mexico' because the country\r
- of Mexico has several time zones.\r
- Use `_' to represent a space.\r
- Omit `.' from abbreviations in names, e.g. prefer `St_Helena'\r
- to `St._Helena'.\r
- Do not change established names if they only marginally\r
- violate the above rules. For example, don't change\r
- the existing name `Rome' to `Milan' merely because\r
- Milan's population has grown to be somewhat greater\r
- than Rome's.\r
- If a name is changed, put its old spelling in the `backward' file.\r
-\r
-The file `zone.tab' lists the geographical locations used to name\r
-time zone rule files.\r
-\r
-Older versions of this package used a different naming scheme,\r
-and these older names are still supported.\r
-See the file `backward' for most of these older names\r
-(e.g. `US/Eastern' instead of `America/New_York').\r
-The other old-fashioned names still supported are\r
-`WET', `CET', `MET', `EET' (see the file `europe'),\r
-and `Factory' (see the file `factory').\r
-\r
-\r
------ Time zone abbreviations -----\r
-\r
-When this package is installed, it generates time zone abbreviations\r
-like `EST' to be compatible with human tradition and POSIX.1.\r
-Here are the general rules used for choosing time zone abbreviations,\r
-in decreasing order of importance:\r
-\r
- Use abbreviations that consist of three or more ASCII letters.\r
- Previous editions of this database also used characters like\r
- ' ' and '?', but these characters have a special meaning to\r
- the shell and cause commands like\r
- set `date`\r
- to have unexpected effects.\r
- Previous editions of this rule required upper-case letters,\r
- but the Congressman who introduced Chamorro Standard Time\r
- preferred "ChST", so the rule has been relaxed.\r
-\r
- This rule guarantees that all abbreviations could have\r
- been specified by a POSIX.1 TZ string. POSIX.1\r
- requires at least three characters for an\r
- abbreviation. POSIX.1-1996 says that an abbreviation\r
- cannot start with ':', and cannot contain ',', '-',\r
- '+', NUL, or a digit. Draft 7 of POSIX 1003.1-200x\r
- changes this rule to say that an abbreviation can\r
- contain only '-', '+', and alphanumeric characters in\r
- the current locale. To be portable to both sets of\r
- rules, an abbreviation must therefore use only ASCII\r
- letters, as these are the only letters that are\r
- alphabetic in all locales.\r
-\r
- Use abbreviations that are in common use among English-speakers,\r
- e.g. `EST' for Eastern Standard Time in North America.\r
- We assume that applications translate them to other languages\r
- as part of the normal localization process; for example,\r
- a French application might translate `EST' to `HNE'.\r
-\r
- For zones whose times are taken from a city's longitude, use the\r
- traditional xMT notation, e.g. `PMT' for Paris Mean Time.\r
- The only name like this in current use is `GMT'.\r
-\r
- If there is no common English abbreviation, abbreviate the English\r
- translation of the usual phrase used by native speakers.\r
- If this is not available or is a phrase mentioning the country\r
- (e.g. ``Cape Verde Time''), then:\r
-\r
- When a country has a single or principal time zone region,\r
- append `T' to the country's ISO code, e.g. `CVT' for\r
- Cape Verde Time. For summer time append `ST';\r
- for double summer time append `DST'; etc.\r
- When a country has multiple time zones, take the first three\r
- letters of an English place name identifying each zone\r
- and then append `T', `ST', etc. as before;\r
- e.g. `VLAST' for VLAdivostok Summer Time.\r
-\r
- Use "zzz" for locations while uninhabited. The mnemonic is that\r
- these locations are, in some sense, asleep.\r
-\r
-Application writers should note that these abbreviations are ambiguous\r
-in practice: e.g. `EST' has a different meaning in Australia than\r
-it does in the United States. In new applications, it's often better\r
-to use numeric UTC offsets like `-0500' instead of time zone\r
-abbreviations like `EST'; this avoids the ambiguity.\r
-\r
-\r
------ Calendrical issues -----\r
-\r
-Calendrical issues are a bit out of scope for a time zone database,\r
-but they indicate the sort of problems that we would run into if we\r
-extended the time zone database further into the past. An excellent\r
-resource in this area is Nachum Dershowitz and Edward M. Reingold,\r
-<a href="http://emr.cs.uiuc.edu/home/reingold/calendar-book/index.shtml">\r
-Calendrical Calculations\r
-</a>, Cambridge University Press (1997). Other information and\r
-sources are given below. They sometimes disagree.\r
-\r
-\r
-France\r
-\r
-Gregorian calendar adopted 1582-12-20.\r
-French Revolutionary calendar used 1793-11-24 through 1805-12-31,\r
-and (in Paris only) 1871-05-06 through 1871-05-23.\r
-\r
-\r
-Russia\r
-\r
-From Chris Carrier <72157.3334@CompuServe.COM> (1996-12-02):\r
-On 1929-10-01 the Soviet Union instituted an ``Eternal Calendar''\r
-with 30-day months plus 5 holidays, with a 5-day week.\r
-On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the\r
-Gregorian calendar while retaining the 6-day week; on 1940-06-27 it\r
-reverted to the 7-day week. With the 6-day week the usual days\r
-off were the 6th, 12th, 18th, 24th and 30th of the month.\r
-(Source: Evitiar Zerubavel, _The Seven Day Circle_)\r
-\r
-\r
-Mark Brader reported a similar story in "The Book of Calendars", edited\r
-by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But:\r
-\r
-From: Petteri Sulonen (via Usenet)\r
-Date: 14 Jan 1999 00:00:00 GMT\r
-Message-ID: <Petteri.Sulonen-1401991626030001@lapin-kulta.in.helsinki.fi>\r
-\r
-If your source is correct, how come documents between 1929 -- 1940 were\r
-still dated using the conventional, Gregorian calendar?\r
-\r
-I can post a scan of a document dated December 1, 1934, signed by\r
-Yenukidze, the secretary, on behalf of Kalinin, the President of the\r
-Executive Committee of the Supreme Soviet, if you like.\r
-\r
-\r
-\r
-Sweden (and Finland)\r
-\r
-From: msb@sq.com (Mark Brader)\r
-<a href="news:1996Jul6.012937.29190@sq.com">\r
-Subject: Re: Gregorian reform -- a part of locale?\r
-</a>\r
-Date: 1996-07-06\r
-\r
-In 1700, Denmark made the transition from Julian to Gregorian. Sweden\r
-decided to *start* a transition in 1700 as well, but rather than have one of\r
-those unsightly calendar gaps :-), they simply decreed that the next leap\r
-year after 1696 would be in 1744 -- putting the whole country on a calendar\r
-different from both Julian and Gregorian for a period of 40 years.\r
-\r
-However, in 1704 something went wrong and the plan was not carried through;\r
-they did, after all, have a leap year that year. And one in 1708. In 1712\r
-they gave it up and went back to Julian, putting 30 days in February that\r
-year!...\r
-\r
-Then in 1753, Sweden made the transition to Gregorian in the usual manner,\r
-getting there only 13 years behind the original schedule.\r
-\r
-(A previous posting of this story was challenged, and Swedish readers\r
-produced the following references to support it: "Tiderakning och historia"\r
-by Natanael Beckman (1924) and "Tid, en bok om tiderakning och\r
-kalendervasen" by Lars-Olof Lode'n (no date was given).)\r
-\r
-\r
-Grotefend's data\r
-\r
-From: "Michael Palmer" <mpalmer@netcom.com> [with one obvious typo fixed]\r
-Subject: Re: Gregorian Calendar (was Re: Another FHC related question\r
-Newsgroups: soc.genealogy.german\r
-Date: Tue, 9 Feb 1999 02:32:48 -800\r
-Message-ID: <199902091032.CAA09644@netcom10.netcom.com>\r
-\r
-The following is a(n incomplete) listing, arranged chronologically, of\r
-European states, with the date they converted from the Julian to the\r
-Gregorian calendar:\r
-\r
-04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman\r
- Catholics and Danzig only)\r
-09/20 Dec 1582 - France, Lorraine\r
-\r
-21 Dec 1582/\r
- 01 Jan 1583 - Holland, Brabant, Flanders, Hennegau\r
-10/21 Feb 1583 - bishopric of Liege (L"uttich)\r
-13/24 Feb 1583 - bishopric of Augsburg\r
-04/15 Oct 1583 - electorate of Trier\r
-05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg,\r
- Salzburg, Brixen\r
-13/24 Oct 1583 - Austrian Oberelsass and Breisgau\r
-20/31 Oct 1583 - bishopric of Basel\r
-02/13 Nov 1583 - duchy of J"ulich-Berg\r
-02/13 Nov 1583 - electorate and city of K"oln\r
-04/15 Nov 1583 - bishopric of W"urzburg\r
-11/22 Nov 1583 - electorate of Mainz\r
-16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden\r
-17/28 Nov 1583 - bishopric of M"unster and duchy of Cleve\r
-14/25 Dec 1583 - Steiermark\r
-\r
-06/17 Jan 1584 - Austria and Bohemia\r
-11/22 Jan 1584 - Luzern, Uri, Schwyz, Zug, Freiburg, Solothurn\r
-12/23 Jan 1584 - Silesia and the Lausitz\r
-22 Jan/\r
- 02 Feb 1584 - Hungary (legally on 21 Oct 1587)\r
- Jun 1584 - Unterwalden\r
-01/12 Jul 1584 - duchy of Westfalen\r
-\r
-16/27 Jun 1585 - bishopric of Paderborn\r
-\r
-14/25 Dec 1590 - Transylvania\r
-\r
-22 Aug/\r
- 02 Sep 1612 - duchy of Prussia\r
-\r
-13/24 Dec 1614 - Pfalz-Neuburg\r
-\r
- 1617 - duchy of Kurland (reverted to the Julian calendar in\r
- 1796)\r
-\r
- 1624 - bishopric of Osnabr"uck\r
-\r
- 1630 - bishopric of Minden\r
-\r
-15/26 Mar 1631 - bishopric of Hildesheim\r
-\r
- 1655 - Kanton Wallis\r
-\r
-05/16 Feb 1682 - city of Strassburg\r
-\r
-18 Feb/\r
- 01 Mar 1700 - Protestant Germany (including Swedish possessions in\r
- Germany), Denmark, Norway\r
-30 Jun/\r
- 12 Jul 1700 - Gelderland, Zutphen\r
-10 Nov/\r
- 12 Dec 1700 - Utrecht, Overijssel\r
-\r
-31 Dec 1700/\r
- 12 Jan 1701 - Friesland, Groningen, Z"urich, Bern, Basel, Geneva,\r
- Turgau, and Schaffhausen\r
-\r
- 1724 - Glarus, Appenzell, and the city of St. Gallen\r
-\r
-01 Jan 1750 - Pisa and Florence\r
-\r
-02/14 Sep 1752 - Great Britain\r
-\r
-17 Feb/\r
- 01 Mar 1753 - Sweden\r
-\r
-1760-1812 - Graub"unden\r
-\r
-The Russian empire (including Finland and the Baltic states) did not\r
-convert to the Gregorian calendar until the Soviet revolution of 1917.\r
-\r
-Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen\r
-Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend\r
-(Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28.\r
-\r
-\r
------ Time and time zones on Mars -----\r
-\r
-Some people have adjusted their work schedules to fit Mars time.\r
-Dozens of special Mars watches were built for Jet Propulsion\r
-Laboratory workers who kept Mars time during the Mars Exploration\r
-Rovers mission (2004). These timepieces look like normal Seikos and\r
-Citizens but use Mars seconds rather than terrestrial seconds.\r
-\r
-A Mars solar day is called a "sol" and has a mean period equal to\r
-about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is\r
-divided into a conventional 24-hour clock, so each Mars second equals\r
-about 1.02749125 terrestrial seconds.\r
-\r
-The prime meridian of Mars goes through the center of the crater\r
-Airy-0, named in honor of the British astronomer who built the\r
-Greenwich telescope that defines Earth's prime meridian. Mean solar\r
-time on the Mars prime meridian is called Mars Coordinated Time (MTC).\r
-\r
-Each landed mission on Mars has adopted a different reference for\r
-solar time keeping, so there is no real standard for Mars time zones.\r
-For example, the Mars Exploration Rover project (2004) defined two\r
-time zones "Local Solar Time A" and "Local Solar Time B" for its two\r
-missions, each zone designed so that its time equals local true solar\r
-time at approximately the middle of the nominal mission. Such a "time\r
-zone" is not particularly suited for any application other than the\r
-mission itself.\r
-\r
-Many calendars have been proposed for Mars, but none have achieved\r
-wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a\r
-sequential count of Mars solar days elapsed since about 1873-12-29\r
-12:00 GMT.\r
-\r
-The tz database does not currently support Mars time, but it is\r
-documented here in the hopes that support will be added eventually.\r
-\r
-Sources:\r
-\r
-Michael Allison and Robert Schmunk,\r
-"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"\r
-<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-03-15).\r
-\r
-Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times\r
-(2004-01-14), pp A1, A20-A21.\r
projects / mirror_edk2.git / blobdiff