Branch: Tag:

2014-09-04

2014-09-04 12:43:31 by Henrik Grubbström (Grubba) <grubba@grubba.org>

Updated to tzdata2014g.

1: + This file is in the public domain, so clarified as of + 2009-05-17 by Arthur David Olson.    -  + ----- Outline ----- +  +  Time and date functions +  Scope of the tz database +  Names of time zone rule files +  Time zone abbreviations +  Calendrical issues +  Time and time zones on Mars +  + ----- Time and date functions ----- +  + These time and date functions are upwards compatible with those of POSIX, + an international standard for UNIX-like systems. + As of this writing, the current edition of POSIX is: +  +  The Open Group Base Specifications Issue 7 +  IEEE Std 1003.1, 2013 Edition +  <http://pubs.opengroup.org/onlinepubs/9699919799/> +  + POSIX has the following properties and limitations. +  + * In POSIX, time display in a process is controlled by the +  environment variable TZ. Unfortunately, the POSIX TZ string takes +  a form that is hard to describe and is error-prone in practice. +  Also, POSIX TZ strings can't deal with other (for example, Israeli) +  daylight saving time rules, or situations where more than two +  time zone abbreviations are used in an area. +  +  The POSIX TZ string takes the following form: +  +  stdoffset[dst[offset][,date[/time],date[/time]]] +  +  where: +  +  std and dst +  are 3 or more characters specifying the standard +  and daylight saving time (DST) zone names. +  Starting with POSIX.1-2001, std and dst may also be +  in a quoted form like "<UTC+10>"; this allows +  "+" and "-" in the names. +  offset +  is of the form '[+-]hh:[mm[:ss]]' and specifies the +  offset west of UT. 'hh' may be a single digit; 0<=hh<=24. +  The default DST offset is one hour ahead of standard time. +  date[/time],date[/time] +  specifies the beginning and end of DST. If this is absent, +  the system supplies its own rules for DST, and these can +  differ from year to year; typically US DST rules are used. +  time +  takes the form 'hh:[mm[:ss]]' and defaults to 02:00. +  This is the same format as the offset, except that a +  leading '+' or '-' is not allowed. +  date +  takes one of the following forms: +  Jn (1<=n<=365) +  origin-1 day number not counting February 29 +  n (0<=n<=365) +  origin-0 day number counting February 29 if present +  Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12) +  for the dth day of week n of month m of the year, +  where week 1 is the first week in which day d appears, +  and '5' stands for the last week in which day d appears +  (which may be either the 4th or 5th week). +  Typically, this is the only useful form; +  the n and Jn forms are rarely used. +  +  Here is an example POSIX TZ string, for US Pacific time using rules +  appropriate from 1987 through 2006: +  +  TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00' +  +  This POSIX TZ string is hard to remember, and mishandles time stamps +  before 1987 and after 2006. With this package you can use this +  instead: +  +  TZ='America/Los_Angeles' +  + * POSIX does not define the exact meaning of TZ values like "EST5EDT". +  Typically the current US DST rules are used to interpret such values, +  but this means that the US DST rules are compiled into each program +  that does time conversion. This means that when US time conversion +  rules change (as in the United States in 1987), all programs that +  do time conversion must be recompiled to ensure proper results. +  + * In POSIX, there's 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 "TZ" environment +  variable. While an administrator can "do everything in UTC" 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.) +  + * POSIX requires that systems ignore leap seconds. +  + * The tz code attempts to support all the time_t implementations +  allowed by POSIX. The time_t type represents a nonnegative count of +  seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. +  In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit +  signed time_t values stop working after 2038-01-19 03:14:07 UTC, 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 integers are also used occasionally. +  Although earlier POSIX versions allowed time_t to be a +  floating-point type, this was not supported by any practical +  systems, and POSIX.1-2013 and the tz code both require time_t +  to be an integer type. +  + These are the extensions that have been made to the POSIX functions: +  + * The "TZ" environment variable is used in generating the name of a file +  from which time zone information is read (or is interpreted a la +  POSIX); "TZ" is no longer constrained to be a three-letter time zone +  name followed by a number of hours and an optional three-letter +  daylight time zone name. The daylight saving time rules to be used +  for a particular time zone are encoded in the time zone 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. +  +  It was recognized that allowing the "TZ" environment variable to +  take on values such as "America/New_York" might cause "old" programs +  (that expect "TZ" to have a certain form) to operate incorrectly; +  consideration was given to using some other environment variable +  (for example, "TIMEZONE") to hold the string used to generate the +  time zone information file name. In the end, however, it was decided +  to continue using "TZ": it is widely used for time zone purposes; +  separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance; +  and systems where "new" forms of "TZ" might cause problems can simply +  use TZ values such as "EST5EDT" which can be used both by +  "new" programs (a la POSIX) and "old" programs (as zone names and +  offsets). +  + * To handle places where more than two time zone abbreviations are used, +  the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst] +  (where "tmp" is the value the function returns) to the time zone +  abbreviation to be used. This differs from POSIX, where the elements +  of tzname are only changed as a result of calls to tzset. +  + * Since the "TZ" environment variable can now be used to control time +  conversion, the "daylight" and "timezone" variables are no longer +  needed. (These variables are defined and set by "tzset"; however, their +  values will not be used by "localtime.") +  + * The "localtime" function has been set up to deliver correct results +  for near-minimum or near-maximum time_t values. (A comment in the +  source code tells how to get compatibly wrong results). +  + * A function "tzsetwall" has been added to arrange for the system's +  best approximation to local wall clock time to be delivered by +  subsequent calls to "localtime." Source code for portable +  applications that "must" run on local wall clock time should call +  "tzsetwall();" if such code is moved to "old" systems that don't +  provide tzsetwall, you won't be able to generate an executable program. +  (These time zone functions also arrange for local wall clock time to be +  used if tzset is called - directly or indirectly - and there's no "TZ" +  environment variable; portable applications should not, however, rely +  on this behavior since it's not the way SVR2 systems behave.) +  + * Negative time_t values are supported, on systems where time_t is signed. +  + * These functions can account for leap seconds, thanks to Bradley White. +  + Points of interest to folks with other systems: +  + * This package is already part of many POSIX-compliant hosts, +  including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun. +  On such hosts, the primary use of this package +  is to update obsolete time zone rule tables. +  To do this, you may need to compile the time zone compiler +  'zic' supplied with this package instead of using the system 'zic', +  since the format of zic's input changed slightly in late 1994, +  and many vendors still do not support the new input format. +  + * The UNIX Version 7 "timezone" function is not present in this package; +  it's impossible to reliably map timezone's arguments (a "minutes west +  of GMT" 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 timezone function may now examine +  tzname[localtime(&clock)->tm_isdst] to learn the correct time +  zone abbreviation to use. Alternatively, use +  localtime(&clock)->tm_zone if this has been enabled. +  + * The 4.2BSD gettimeofday function is not used in this package. +  This formerly let users obtain the current UTC offset and DST flag, +  but this functionality was removed in later versions of BSD. +  + * In SVR2, time conversion fails for near-minimum or near-maximum +  time_t values when doing conversions for places that don't use UT. +  This package takes care to do these conversions correctly. +  + The functions that are conditionally compiled if STD_INSPIRED 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 + *any* standard. They do, however, represent responses of various authors to + standardization proposals. +  + 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. +  +  + ----- Scope of the tz database ----- +  + The tz database attempts to record the history and predicted future of + all computer-based clocks that track civil time. To represent this + data, the world is partitioned into regions whose clocks all agree + about time stamps that occur after the somewhat-arbitrary cutoff point + of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region, + the database records all known clock transitions, and labels the region + with a notable 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. +  + Clock transitions before 1970 are recorded for each such location, + because most POSIX-compatible systems support negative time stamps 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. +  +  + ----- Accuracy of the tz database ----- +  + The tz database is not authoritative, and it surely has errors. + Corrections are welcome and encouraged; see the file CONTRIBUTING. + Users requiring authoritative data should consult national standards + bodies and the references cited in the database's comments. +  + Errors in the tz database arise from many sources: +  +  * The tz database predicts future time stamps, 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. +  +  * 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 zones would +  be needed if the tz 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. +  +  * 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. +  +  * For the UK the tz database relies on years of first-class work done by +  Joseph Myers and others; see <http://www.polyomino.org.uk/british-time/>. +  Other countries are not done nearly as well. +  +  * Sometimes, different people in the same city would maintain clocks +  that differed significantly. Railway time was used by railroad +  companies (which did not always agree with each other), +  church-clock time was used for birth certificates, etc. +  Often this was merely common practice, but sometimes it was set by law. +  For example, from 1891 to 1911 the UT offset in France was legally +  0:09:21 outside train stations and 0:04:21 inside. +  +  * Although a named location in the tz database stands for the +  containing region, its pre-1970 data entries are often accurate for +  only a small subset of that region. For example, Europe/London +  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 GMT is known to be valid only for the L&NW and the +  Caledonian railways. +  +  * The tz database does not record the earliest time for which a zone's +  data entries are thereafter valid for every location in the region. +  For example, Europe/London is valid for all locations in its +  region after GMT was made the standard time, but the date of +  standardization (1880-08-02) is not in the tz database, other than +  in commentary. For many zones the earliest time of validity is +  unknown. +  +  * The tz database does not record a region's boundaries, and in many +  cases the boundaries are not known. For example, the zone +  America/Kentucky/Louisville represents a region around the city of +  Louisville, the boundaries of which are unclear. +  +  * Changes that are modeled as instantaneous transitions in the tz +  database were often spread out over hours, days, or even decades. +  +  * Even if the time is specified by law, locations sometimes +  deliberately flout the law. +  +  * Early timekeeping practices, even assuming perfect clocks, were +  often not specified to the accuracy that the tz database requires. +  +  * Sometimes historical timekeeping was specified more precisely +  than what the tz database can handle. For example, from 1909 to +  1937 Netherlands clocks were legally UT+00:19:32.13, but the tz +  database cannot represent the fractional second. +  +  * Even when all the timestamp transitions recorded by the tz database +  are correct, the tz 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 tz database has no +  way to specify Easter, these exceptional years are entered as +  separate tz Rule lines, even though the legal rules did not change. +  +  * The tz database models pre-standard time using the Gregorian +  calendar and local mean time (LMT), but many people used other +  calendars and other timescales. For example, the Roman Empire used +  the Julian calendar, and had 12 varying-length daytime hours with a +  non-hour-based system at night. +  +  * Early clocks were less reliable, and data entries do not represent +  this unreliability. +  +  * As for leap seconds, civil time was not based on atomic time before +  1972, and we don't know the history of earth's rotation accurately +  enough to map SI seconds to historical solar time to more than +  about one-hour accuracy. See: Morrison LV, Stephenson FR. +  Historical values of the Earth's clock error Delta T and the +  calculation of eclipses. J Hist Astron. 2004;35:327-36 +  <http://adsabs.harvard.edu/full/2004JHA....35..327M>; +  Historical values of the Earth's clock error. J Hist Astron. 2005;36:339 +  <http://adsabs.harvard.edu/full/2005JHA....36..339M>. +  +  * The relationship between POSIX time (that is, UTC but ignoring leap +  seconds) and UTC is not agreed upon after 1972. Although the POSIX +  clock officially stops during an inserted leap second, at least one +  proposed standard has it jumping back a second instead; and in +  practice POSIX clocks more typically either progress glacially during +  a leap second, or are slightly slowed while near a leap second. +  +  * The tz database does not represent how uncertain its information is. +  Ideally it would contain information about when data entries are +  incomplete or dicey. Partial temporal knowledge is a field of +  active research, though, and it's not clear how to apply it here. +  + In short, many, perhaps most, of the tz database's pre-1970 and future + time stamps are either wrong or misleading. Any attempt to pass the + tz database off as the definition of time should be unacceptable to + anybody who cares about the facts. In particular, the tz database's + LMT offsets should not be considered meaningful, and should not prompt + creation of zones merely because two locations differ in LMT or + transitioned to standard time at different dates. +  +  + ----- Names of time zone rule files ----- +  + The time zone rule file naming conventions attempt to strike a balance + among the following goals: +  +  * Uniquely identify every national region where clocks have all +  agreed since 1970. This is essential for the intended use: static +  clocks keeping local civil time. +  +  * Indicate to humans as to where that region is. This simplifies use. +  +  * Be robust in the presence of political changes. This reduces the +  number of updates and backward-compatibility hacks. 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). +  +  * Be portable to a wide variety of implementations. +  This promotes use of the technology. +  +  * Use a consistent naming convention over the entire world. +  This simplifies both use and maintenance. +  + This naming convention is not intended for use by inexperienced users + to select TZ values by themselves (though they can of course examine + and reuse existing settings). Distributors should provide + documentation and/or a simple selection interface that explains the + names; see the 'tzselect' program supplied with this distribution for + one example. +  + Names normally have the form AREA/LOCATION, where AREA is the name + of a continent or ocean, and LOCATION is the name of a specific + location within that region. North and South America share the same + area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', + and 'Pacific/Honolulu'. +  + Here are the general rules used for choosing location names, + in decreasing order of importance: +  +  Use only valid POSIX file name components (i.e., the parts of +  names other than '/'). Do not use the file name +  components '.' and '..'. Within a file name component, +  use only ASCII letters, '.', '-' and '_'. Do not use +  digits, as that might create an ambiguity with POSIX +  TZ strings. A file name component must not exceed 14 +  characters or start with '-'. E.g., prefer 'Brunei' +  to 'Bandar_Seri_Begawan'. Exceptions: see the discussion +  of legacy names below. +  A name must not be empty, or contain '//', or start or end with '/'. +  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. +  If one name A is an initial prefix of another name AB (ignoring case), +  then B must not start with '/', as a regular file cannot have +  the same name as a directory in POSIX. For example, +  'America/New_York' precludes 'America/New_York/Bronx'. +  Uninhabited regions like the North Pole and Bouvet Island +  do not need locations, since local time is not defined there. +  There should typically be at least one name for each ISO 3166-1 +  officially assigned two-letter code for an inhabited country +  or territory. +  If all the clocks in a region have agreed since 1970, +  don't bother to include more than one location +  even if subregions' clocks disagreed before 1970. +  Otherwise these tables would become annoyingly large. +  If a name is ambiguous, use a less ambiguous alternative; +  e.g. many cities are named San José and Georgetown, so +  prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'. +  Keep locations compact. Use cities or small islands, not countries +  or regions, so that any future time zone changes do not split +  locations into different time zones. E.g. prefer 'Paris' +  to 'France', since France has had multiple time zones. +  Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and +  prefer 'Athens' to the Greek 'Αθήνα' or the Romanized 'Athína'. +  The POSIX file name restrictions encourage this rule. +  Use the most populous among locations in a zone, +  e.g. prefer 'Shanghai' to 'Beijing'. Among locations with +  similar populations, pick the best-known location, +  e.g. prefer 'Rome' to 'Milan'. +  Use the singular form, e.g. prefer 'Canary' to 'Canaries'. +  Omit common suffixes like '_Islands' and '_City', unless that +  would lead to ambiguity. E.g. prefer 'Cayman' to +  'Cayman_Islands' and 'Guatemala' to 'Guatemala_City', +  but prefer 'Mexico_City' to 'Mexico' because the country +  of Mexico has several time zones. +  Use '_' to represent a space. +  Omit '.' from abbreviations in names, e.g. prefer 'St_Helena' +  to 'St._Helena'. +  Do not change established names if they only marginally +  violate the above rules. For example, don't change +  the existing name 'Rome' to 'Milan' merely because +  Milan's population has grown to be somewhat greater +  than Rome's. +  If a name is changed, put its old spelling in the 'backward' file. +  This means old spellings will continue to work. +  + The file 'zone1970.tab' lists geographical locations used to name time + zone rule files. 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 'zone1970.tab' location's longitude + corresponds to its LMT offset with one hour for every 15 degrees east + longitude, this relationship is not exact. +  + Older versions of this package used a different naming scheme, + and these older names are still supported. + See the file 'backward' for most of these older names + (e.g., 'US/Eastern' instead of 'America/New_York'). + The other old-fashioned names still supported are + 'WET', 'CET', 'MET', and 'EET' (see the file 'europe'). +  + Older versions of this package defined legacy names that are + incompatible with the first rule of location names, but which are + still supported. These legacy names are mostly defined in the file + 'etcetera'. Also, the file 'backward' defines the legacy names + 'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file + 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT', + 'MST7MDT', and 'PST8PDT'. +  + Excluding 'backward' should not affect the other data. If + 'backward' is excluded, excluding 'etcetera' should not affect the + remaining data. +  +  + ----- Time zone abbreviations ----- +  + When this package is installed, it generates time zone abbreviations + like 'EST' to be compatible with human tradition and POSIX. + Here are the general rules used for choosing time zone abbreviations, + in decreasing order of importance: +  +  Use abbreviations that consist of three or more ASCII letters. +  Previous editions of this database also used characters like +  ' ' and '?', but these characters have a special meaning to +  the shell and cause commands like +  set `date` +  to have unexpected effects. +  Previous editions of this rule required upper-case letters, +  but the Congressman who introduced Chamorro Standard Time +  preferred "ChST", so the rule has been relaxed. +  +  This rule guarantees that all abbreviations could have +  been specified by a POSIX TZ string. POSIX +  requires at least three characters for an +  abbreviation. POSIX through 2000 says that an abbreviation +  cannot start with ':', and cannot contain ',', '-', +  '+', NUL, or a digit. POSIX from 2001 on changes this +  rule to say that an abbreviation can contain only '-', '+', +  and alphanumeric characters from the portable character set +  in the current locale. To be portable to both sets of +  rules, an abbreviation must therefore use only ASCII +  letters. +  +  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'. +  +  For zones whose times are taken from a city's longitude, use the +  traditional xMT notation, e.g. 'PMT' for Paris Mean Time. +  The only name like this in current use is 'GMT'. +  +  If there is no common English abbreviation, abbreviate the English +  translation of the usual phrase used by native speakers. +  If this is not available or is a phrase mentioning the country +  (e.g. "Cape Verde Time"), then: +  +  When a country is identified with a single or principal zone, +  append 'T' to the country's ISO code, e.g. 'CVT' for +  Cape Verde Time. For summer time append 'ST'; +  for double summer time append 'DST'; etc. +  Otherwise, take the first three letters of an English place +  name identifying each zone and append 'T', 'ST', etc. +  as before; e.g. 'VLAST' for VLAdivostok Summer Time. +  +  Use 'LMT' for local mean time of locations before the introduction +  of standard time; see "Scope of the tz database". +  +  Use UT (with time zone abbreviation 'zzz') for locations while +  uninhabited. The 'zzz' mnemonic is that these locations are, +  in some sense, asleep. +  + Application writers should note that these abbreviations are ambiguous + in practice: e.g. 'CST' has a different meaning in China than + it does in the United States. In new applications, it's often better + to use numeric UT offsets like '-0600' instead of time zone + abbreviations like 'CST'; this avoids the ambiguity. +  +  + ----- Calendrical issues ----- +  + Calendrical issues are a bit out of scope for a time zone database, + but they indicate the sort of problems that we would run into if we + extended the time zone database further into the past. An excellent + resource in this area is Nachum Dershowitz and Edward M. Reingold, + Calendrical Calculations: Third Edition, Cambridge University Press (2008) + <http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/>. + Other information and sources are given below. They sometimes disagree. +  +  + France +  + Gregorian calendar adopted 1582-12-20. + French Revolutionary calendar used 1793-11-24 through 1805-12-31, + and (in Paris only) 1871-05-06 through 1871-05-23. +  +  + Russia +  + From Chris Carrier (1996-12-02): + On 1929-10-01 the Soviet Union instituted an "Eternal Calendar" + with 30-day months plus 5 holidays, with a 5-day week. + On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the + Gregorian calendar while retaining the 6-day week; on 1940-06-27 it + reverted to the 7-day week. With the 6-day week the usual days + off were the 6th, 12th, 18th, 24th and 30th of the month. + (Source: Evitiar Zerubavel, _The Seven Day Circle_) +  +  + Mark Brader reported a similar story in "The Book of Calendars", edited + by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But: +  + From: Petteri Sulonen (via Usenet) + Date: 14 Jan 1999 00:00:00 GMT + ... +  + If your source is correct, how come documents between 1929 and 1940 were + still dated using the conventional, Gregorian calendar? +  + I can post a scan of a document dated December 1, 1934, signed by + Yenukidze, the secretary, on behalf of Kalinin, the President of the + Executive Committee of the Supreme Soviet, if you like. +  +  +  + Sweden (and Finland) +  + From: Mark Brader + Subject: Re: Gregorian reform - a part of locale? + <news:1996Jul6.012937.29190@sq.com> + Date: 1996-07-06 +  + In 1700, Denmark made the transition from Julian to Gregorian. Sweden + decided to *start* a transition in 1700 as well, but rather than have one of + those unsightly calendar gaps :-), they simply decreed that the next leap + year after 1696 would be in 1744 - putting the whole country on a calendar + different from both Julian and Gregorian for a period of 40 years. +  + However, in 1704 something went wrong and the plan was not carried through; + they did, after all, have a leap year that year. And one in 1708. In 1712 + they gave it up and went back to Julian, putting 30 days in February that + year!... +  + Then in 1753, Sweden made the transition to Gregorian in the usual manner, + getting there only 13 years behind the original schedule. +  + (A previous posting of this story was challenged, and Swedish readers + produced the following references to support it: "Tideräkning och historia" + by Natanael Beckman (1924) and "Tid, en bok om tideräkning och + kalenderväsen" by Lars-Olof Lodén (1968). +  +  + Grotefend's data +  + From: "Michael Palmer" [with one obvious typo fixed] + Subject: Re: Gregorian Calendar (was Re: Another FHC related question + Newsgroups: soc.genealogy.german + Date: Tue, 9 Feb 1999 02:32:48 -800 + ... +  + The following is a(n incomplete) listing, arranged chronologically, of + European states, with the date they converted from the Julian to the + Gregorian calendar: +  + 04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman +  Catholics and Danzig only) + 09/20 Dec 1582 - France, Lorraine +  + 21 Dec 1582/ +  01 Jan 1583 - Holland, Brabant, Flanders, Hennegau + 10/21 Feb 1583 - bishopric of Liege (Lüttich) + 13/24 Feb 1583 - bishopric of Augsburg + 04/15 Oct 1583 - electorate of Trier + 05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg, +  Salzburg, Brixen + 13/24 Oct 1583 - Austrian Oberelsaß and Breisgau + 20/31 Oct 1583 - bishopric of Basel + 02/13 Nov 1583 - duchy of Jülich-Berg + 02/13 Nov 1583 - electorate and city of Köln + 04/15 Nov 1583 - bishopric of Würzburg + 11/22 Nov 1583 - electorate of Mainz + 16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden + 17/28 Nov 1583 - bishopric of Münster and duchy of Cleve + 14/25 Dec 1583 - Steiermark +  + 06/17 Jan 1584 - Austria and Bohemia + 11/22 Jan 1584 - Lucerne, Uri, Schwyz, Zug, Freiburg, Solothurn + 12/23 Jan 1584 - Silesia and the Lausitz + 22 Jan/ +  02 Feb 1584 - Hungary (legally on 21 Oct 1587) +  Jun 1584 - Unterwalden + 01/12 Jul 1584 - duchy of Westfalen +  + 16/27 Jun 1585 - bishopric of Paderborn +  + 14/25 Dec 1590 - Transylvania +  + 22 Aug/ +  02 Sep 1612 - duchy of Prussia +  + 13/24 Dec 1614 - Pfalz-Neuburg +  +  1617 - duchy of Kurland (reverted to the Julian calendar in +  1796) +  +  1624 - bishopric of Osnabrück +  +  1630 - bishopric of Minden +  + 15/26 Mar 1631 - bishopric of Hildesheim +  +  1655 - Kanton Wallis +  + 05/16 Feb 1682 - city of Strassburg +  + 18 Feb/ +  01 Mar 1700 - Protestant Germany (including Swedish possessions in +  Germany), Denmark, Norway + 30 Jun/ +  12 Jul 1700 - Gelderland, Zutphen + 10 Nov/ +  12 Dec 1700 - Utrecht, Overijssel +  + 31 Dec 1700/ +  12 Jan 1701 - Friesland, Groningen, Zürich, Bern, Basel, Geneva, +  Turgau, and Schaffhausen +  +  1724 - Glarus, Appenzell, and the city of St. Gallen +  + 01 Jan 1750 - Pisa and Florence +  + 02/14 Sep 1752 - Great Britain +  + 17 Feb/ +  01 Mar 1753 - Sweden +  + 1760-1812 - Graubünden +  + The Russian empire (including Finland and the Baltic states) did not + convert to the Gregorian calendar until the Soviet revolution of 1917. +  + Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen + Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend + (Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28. +  +  + ----- Time and time zones on Mars ----- +  + Some people have adjusted their work schedules to fit Mars time. + Dozens of special Mars watches were built for Jet Propulsion + Laboratory 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. +  + 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. +  + The prime meridian of Mars goes through the center of the crater + Airy-0, 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 Mars Coordinated Time (MTC). +  + 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 Mars Exploration Rover 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. +  + Many calendars have been proposed for Mars, but none have achieved + wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a + sequential count of Mars solar days elapsed since about 1873-12-29 + 12:00 GMT. +  + The tz database does not currently support Mars time, but it is + documented here in the hopes that support will be added eventually. +  + Sources: +  + Michael Allison and Robert Schmunk, + "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" + <http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08). +  + Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times + <http://articles.latimes.com/2004/jan/14/science/sci-marstime14> + (2004-01-14), pp A1, A20-A21. +  +  + ----- + Local Variables: + coding: utf-8 + End:   Newline at end of file added.