| 1 | @(#)Theory 8.3 |
| 2 | This file is in the public domain, so clarified as of |
| 3 | 2009-05-17 by Arthur David Olson. |
| 4 | |
| 5 | ----- Outline ----- |
| 6 | |
| 7 | Time and date functions |
| 8 | Names of time zone regions |
| 9 | Time zone abbreviations |
| 10 | Calendrical issues |
| 11 | Time and time zones on Mars |
| 12 | |
| 13 | ----- Time and date functions ----- |
| 14 | |
| 15 | These time and date functions are upwards compatible with POSIX, |
| 16 | an international standard for UNIX-like systems. |
| 17 | As of this writing, the current edition of POSIX is: |
| 18 | |
| 19 | Standard for Information technology |
| 20 | -- Portable Operating System Interface (POSIX (R)) |
| 21 | -- System Interfaces |
| 22 | IEEE Std 1003.1, 2004 Edition |
| 23 | <http://www.opengroup.org/online-pubs?DOC=7999959899> |
| 24 | <http://www.opengroup.org/pubs/catalog/t041.htm> |
| 25 | |
| 26 | POSIX has the following properties and limitations. |
| 27 | |
| 28 | * In POSIX, time display in a process is controlled by the |
| 29 | environment variable TZ. Unfortunately, the POSIX TZ string takes |
| 30 | a form that is hard to describe and is error-prone in practice. |
| 31 | Also, POSIX TZ strings can't deal with other (for example, Israeli) |
| 32 | daylight saving time rules, or situations where more than two |
| 33 | time zone abbreviations are used in an area. |
| 34 | |
| 35 | The POSIX TZ string takes the following form: |
| 36 | |
| 37 | stdoffset[dst[offset],date[/time],date[/time]] |
| 38 | |
| 39 | where: |
| 40 | |
| 41 | std and dst |
| 42 | are 3 or more characters specifying the standard |
| 43 | and daylight saving time (DST) zone names. |
| 44 | Starting with POSIX.1-2001, std and dst may also be |
| 45 | in a quoted form like "<UTC+10>"; this allows |
| 46 | "+" and "-" in the names. |
| 47 | offset |
| 48 | is of the form `[-]hh:[mm[:ss]]' and specifies the |
| 49 | offset west of UTC. The default DST offset is one hour |
| 50 | ahead of standard time. |
| 51 | date[/time],date[/time] |
| 52 | specifies the beginning and end of DST. If this is absent, |
| 53 | the system supplies its own rules for DST, and these can |
| 54 | differ from year to year; typically US DST rules are used. |
| 55 | time |
| 56 | takes the form `hh:[mm[:ss]]' and defaults to 02:00. |
| 57 | date |
| 58 | takes one of the following forms: |
| 59 | Jn (1<=n<=365) |
| 60 | origin-1 day number not counting February 29 |
| 61 | n (0<=n<=365) |
| 62 | origin-0 day number counting February 29 if present |
| 63 | Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12) |
| 64 | for the dth day of week n of month m of the year, |
| 65 | where week 1 is the first week in which day d appears, |
| 66 | and `5' stands for the last week in which day d appears |
| 67 | (which may be either the 4th or 5th week). |
| 68 | |
| 69 | Here is an example POSIX TZ string, for US Pacific time using rules |
| 70 | appropriate from 1987 through 2006: |
| 71 | |
| 72 | TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00' |
| 73 | |
| 74 | This POSIX TZ string is hard to remember, and mishandles time stamps |
| 75 | before 1987 and after 2006. With this package you can use this |
| 76 | instead: |
| 77 | |
| 78 | TZ='America/Los_Angeles' |
| 79 | |
| 80 | * POSIX does not define the exact meaning of TZ values like "EST5EDT". |
| 81 | Typically the current US DST rules are used to interpret such values, |
| 82 | but this means that the US DST rules are compiled into each program |
| 83 | that does time conversion. This means that when US time conversion |
| 84 | rules change (as in the United States in 1987), all programs that |
| 85 | do time conversion must be recompiled to ensure proper results. |
| 86 | |
| 87 | * In POSIX, there's no tamper-proof way for a process to learn the |
| 88 | system's best idea of local wall clock. (This is important for |
| 89 | applications that an administrator wants used only at certain times-- |
| 90 | without regard to whether the user has fiddled the "TZ" environment |
| 91 | variable. While an administrator can "do everything in UTC" to get |
| 92 | around the problem, doing so is inconvenient and precludes handling |
| 93 | daylight saving time shifts--as might be required to limit phone |
| 94 | calls to off-peak hours.) |
| 95 | |
| 96 | * POSIX requires that systems ignore leap seconds. |
| 97 | |
| 98 | These are the extensions that have been made to the POSIX functions: |
| 99 | |
| 100 | * The "TZ" environment variable is used in generating the name of a file |
| 101 | from which time zone information is read (or is interpreted a la |
| 102 | POSIX); "TZ" is no longer constrained to be a three-letter time zone |
| 103 | name followed by a number of hours and an optional three-letter |
| 104 | daylight time zone name. The daylight saving time rules to be used |
| 105 | for a particular time zone are encoded in the time zone file; |
| 106 | the format of the file allows U.S., Australian, and other rules to be |
| 107 | encoded, and allows for situations where more than two time zone |
| 108 | abbreviations are used. |
| 109 | |
| 110 | It was recognized that allowing the "TZ" environment variable to |
| 111 | take on values such as "America/New_York" might cause "old" programs |
| 112 | (that expect "TZ" to have a certain form) to operate incorrectly; |
| 113 | consideration was given to using some other environment variable |
| 114 | (for example, "TIMEZONE") to hold the string used to generate the |
| 115 | time zone information file name. In the end, however, it was decided |
| 116 | to continue using "TZ": it is widely used for time zone purposes; |
| 117 | separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance; |
| 118 | and systems where "new" forms of "TZ" might cause problems can simply |
| 119 | use TZ values such as "EST5EDT" which can be used both by |
| 120 | "new" programs (a la POSIX) and "old" programs (as zone names and |
| 121 | offsets). |
| 122 | |
| 123 | * To handle places where more than two time zone abbreviations are used, |
| 124 | the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst] |
| 125 | (where "tmp" is the value the function returns) to the time zone |
| 126 | abbreviation to be used. This differs from POSIX, where the elements |
| 127 | of tzname are only changed as a result of calls to tzset. |
| 128 | |
| 129 | * Since the "TZ" environment variable can now be used to control time |
| 130 | conversion, the "daylight" and "timezone" variables are no longer |
| 131 | needed. (These variables are defined and set by "tzset"; however, their |
| 132 | values will not be used by "localtime.") |
| 133 | |
| 134 | * The "localtime" function has been set up to deliver correct results |
| 135 | for near-minimum or near-maximum time_t values. (A comment in the |
| 136 | source code tells how to get compatibly wrong results). |
| 137 | |
| 138 | * A function "tzsetwall" has been added to arrange for the system's |
| 139 | best approximation to local wall clock time to be delivered by |
| 140 | subsequent calls to "localtime." Source code for portable |
| 141 | applications that "must" run on local wall clock time should call |
| 142 | "tzsetwall();" if such code is moved to "old" systems that don't |
| 143 | provide tzsetwall, you won't be able to generate an executable program. |
| 144 | (These time zone functions also arrange for local wall clock time to be |
| 145 | used if tzset is called--directly or indirectly--and there's no "TZ" |
| 146 | environment variable; portable applications should not, however, rely |
| 147 | on this behavior since it's not the way SVR2 systems behave.) |
| 148 | |
| 149 | * These functions can account for leap seconds, thanks to Bradley White. |
| 150 | |
| 151 | Points of interest to folks with other systems: |
| 152 | |
| 153 | * This package is already part of many POSIX-compliant hosts, |
| 154 | including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun. |
| 155 | On such hosts, the primary use of this package |
| 156 | is to update obsolete time zone rule tables. |
| 157 | To do this, you may need to compile the time zone compiler |
| 158 | `zic' supplied with this package instead of using the system `zic', |
| 159 | since the format of zic's input changed slightly in late 1994, |
| 160 | and many vendors still do not support the new input format. |
| 161 | |
| 162 | * The UNIX Version 7 "timezone" function is not present in this package; |
| 163 | it's impossible to reliably map timezone's arguments (a "minutes west |
| 164 | of GMT" value and a "daylight saving time in effect" flag) to a |
| 165 | time zone abbreviation, and we refuse to guess. |
| 166 | Programs that in the past used the timezone function may now examine |
| 167 | tzname[localtime(&clock)->tm_isdst] to learn the correct time |
| 168 | zone abbreviation to use. Alternatively, use |
| 169 | localtime(&clock)->tm_zone if this has been enabled. |
| 170 | |
| 171 | * The 4.2BSD gettimeofday function is not used in this package. |
| 172 | This formerly let users obtain the current UTC offset and DST flag, |
| 173 | but this functionality was removed in later versions of BSD. |
| 174 | |
| 175 | * In SVR2, time conversion fails for near-minimum or near-maximum |
| 176 | time_t values when doing conversions for places that don't use UTC. |
| 177 | This package takes care to do these conversions correctly. |
| 178 | |
| 179 | The functions that are conditionally compiled if STD_INSPIRED is defined |
| 180 | should, at this point, be looked on primarily as food for thought. They are |
| 181 | not in any sense "standard compatible"--some are not, in fact, specified in |
| 182 | *any* standard. They do, however, represent responses of various authors to |
| 183 | standardization proposals. |
| 184 | |
| 185 | Other time conversion proposals, in particular the one developed by folks at |
| 186 | Hewlett Packard, offer a wider selection of functions that provide capabilities |
| 187 | beyond those provided here. The absence of such functions from this package |
| 188 | is not meant to discourage the development, standardization, or use of such |
| 189 | functions. Rather, their absence reflects the decision to make this package |
| 190 | contain valid extensions to POSIX, to ensure its broad acceptability. If |
| 191 | more powerful time conversion functions can be standardized, so much the |
| 192 | better. |
| 193 | |
| 194 | |
| 195 | ----- Names of time zone rule files ----- |
| 196 | |
| 197 | The time zone rule file naming conventions attempt to strike a balance |
| 198 | among the following goals: |
| 199 | |
| 200 | * Uniquely identify every national region where clocks have all |
| 201 | agreed since 1970. This is essential for the intended use: static |
| 202 | clocks keeping local civil time. |
| 203 | |
| 204 | * Indicate to humans as to where that region is. This simplifes use. |
| 205 | |
| 206 | * Be robust in the presence of political changes. This reduces the |
| 207 | number of updates and backward-compatibility hacks. For example, |
| 208 | names of countries are ordinarily not used, to avoid |
| 209 | incompatibilities when countries change their name |
| 210 | (e.g. Zaire->Congo) or when locations change countries |
| 211 | (e.g. Hong Kong from UK colony to China). |
| 212 | |
| 213 | * Be portable to a wide variety of implementations. |
| 214 | This promotes use of the technology. |
| 215 | |
| 216 | * Use a consistent naming convention over the entire world. |
| 217 | This simplifies both use and maintenance. |
| 218 | |
| 219 | This naming convention is not intended for use by inexperienced users |
| 220 | to select TZ values by themselves (though they can of course examine |
| 221 | and reuse existing settings). Distributors should provide |
| 222 | documentation and/or a simple selection interface that explains the |
| 223 | names; see the 'tzselect' program supplied with this distribution for |
| 224 | one example. |
| 225 | |
| 226 | Names normally have the form AREA/LOCATION, where AREA is the name |
| 227 | of a continent or ocean, and LOCATION is the name of a specific |
| 228 | location within that region. North and South America share the same |
| 229 | area, `America'. Typical names are `Africa/Cairo', `America/New_York', |
| 230 | and `Pacific/Honolulu'. |
| 231 | |
| 232 | Here are the general rules used for choosing location names, |
| 233 | in decreasing order of importance: |
| 234 | |
| 235 | Use only valid POSIX file name components (i.e., the parts of |
| 236 | names other than `/'). Within a file name component, |
| 237 | use only ASCII letters, `.', `-' and `_'. Do not use |
| 238 | digits, as that might create an ambiguity with POSIX |
| 239 | TZ strings. A file name component must not exceed 14 |
| 240 | characters or start with `-'. E.g., prefer `Brunei' |
| 241 | to `Bandar_Seri_Begawan'. |
| 242 | Include at least one location per time zone rule set per country. |
| 243 | One such location is enough. Use ISO 3166 (see the file |
| 244 | iso3166.tab) to help decide whether something is a country. |
| 245 | However, uninhabited ISO 3166 regions like Bouvet Island |
| 246 | do not need locations, since local time is not defined there. |
| 247 | If all the clocks in a country's region have agreed since 1970, |
| 248 | don't bother to include more than one location |
| 249 | even if subregions' clocks disagreed before 1970. |
| 250 | Otherwise these tables would become annoyingly large. |
| 251 | If a name is ambiguous, use a less ambiguous alternative; |
| 252 | e.g. many cities are named San Jose and Georgetown, so |
| 253 | prefer `Costa_Rica' to `San_Jose' and `Guyana' to `Georgetown'. |
| 254 | Keep locations compact. Use cities or small islands, not countries |
| 255 | or regions, so that any future time zone changes do not split |
| 256 | locations into different time zones. E.g. prefer `Paris' |
| 257 | to `France', since France has had multiple time zones. |
| 258 | Use mainstream English spelling, e.g. prefer `Rome' to `Roma', and |
| 259 | prefer `Athens' to the true name (which uses Greek letters). |
| 260 | The POSIX file name restrictions encourage this rule. |
| 261 | Use the most populous among locations in a country's time zone, |
| 262 | e.g. prefer `Shanghai' to `Beijing'. Among locations with |
| 263 | similar populations, pick the best-known location, |
| 264 | e.g. prefer `Rome' to `Milan'. |
| 265 | Use the singular form, e.g. prefer `Canary' to `Canaries'. |
| 266 | Omit common suffixes like `_Islands' and `_City', unless that |
| 267 | would lead to ambiguity. E.g. prefer `Cayman' to |
| 268 | `Cayman_Islands' and `Guatemala' to `Guatemala_City', |
| 269 | but prefer `Mexico_City' to `Mexico' because the country |
| 270 | of Mexico has several time zones. |
| 271 | Use `_' to represent a space. |
| 272 | Omit `.' from abbreviations in names, e.g. prefer `St_Helena' |
| 273 | to `St._Helena'. |
| 274 | Do not change established names if they only marginally |
| 275 | violate the above rules. For example, don't change |
| 276 | the existing name `Rome' to `Milan' merely because |
| 277 | Milan's population has grown to be somewhat greater |
| 278 | than Rome's. |
| 279 | If a name is changed, put its old spelling in the `backward' file. |
| 280 | |
| 281 | The file `zone.tab' lists the geographical locations used to name |
| 282 | time zone rule files. It is intended to be an exhaustive list |
| 283 | of canonical names for geographic regions. |
| 284 | |
| 285 | Older versions of this package used a different naming scheme, |
| 286 | and these older names are still supported. |
| 287 | See the file `backward' for most of these older names |
| 288 | (e.g. `US/Eastern' instead of `America/New_York'). |
| 289 | The other old-fashioned names still supported are |
| 290 | `WET', `CET', `MET', `EET' (see the file `europe'), |
| 291 | and `Factory' (see the file `factory'). |
| 292 | |
| 293 | |
| 294 | ----- Time zone abbreviations ----- |
| 295 | |
| 296 | When this package is installed, it generates time zone abbreviations |
| 297 | like `EST' to be compatible with human tradition and POSIX. |
| 298 | Here are the general rules used for choosing time zone abbreviations, |
| 299 | in decreasing order of importance: |
| 300 | |
| 301 | Use abbreviations that consist of three or more ASCII letters. |
| 302 | Previous editions of this database also used characters like |
| 303 | ' ' and '?', but these characters have a special meaning to |
| 304 | the shell and cause commands like |
| 305 | set `date` |
| 306 | to have unexpected effects. |
| 307 | Previous editions of this rule required upper-case letters, |
| 308 | but the Congressman who introduced Chamorro Standard Time |
| 309 | preferred "ChST", so the rule has been relaxed. |
| 310 | |
| 311 | This rule guarantees that all abbreviations could have |
| 312 | been specified by a POSIX TZ string. POSIX |
| 313 | requires at least three characters for an |
| 314 | abbreviation. POSIX through 2000 says that an abbreviation |
| 315 | cannot start with ':', and cannot contain ',', '-', |
| 316 | '+', NUL, or a digit. POSIX from 2001 on changes this |
| 317 | rule to say that an abbreviation can contain only '-', '+', |
| 318 | and alphanumeric characters from the portable character set |
| 319 | in the current locale. To be portable to both sets of |
| 320 | rules, an abbreviation must therefore use only ASCII |
| 321 | letters. |
| 322 | |
| 323 | Use abbreviations that are in common use among English-speakers, |
| 324 | e.g. `EST' for Eastern Standard Time in North America. |
| 325 | We assume that applications translate them to other languages |
| 326 | as part of the normal localization process; for example, |
| 327 | a French application might translate `EST' to `HNE'. |
| 328 | |
| 329 | For zones whose times are taken from a city's longitude, use the |
| 330 | traditional xMT notation, e.g. `PMT' for Paris Mean Time. |
| 331 | The only name like this in current use is `GMT'. |
| 332 | |
| 333 | If there is no common English abbreviation, abbreviate the English |
| 334 | translation of the usual phrase used by native speakers. |
| 335 | If this is not available or is a phrase mentioning the country |
| 336 | (e.g. ``Cape Verde Time''), then: |
| 337 | |
| 338 | When a country has a single or principal time zone region, |
| 339 | append `T' to the country's ISO code, e.g. `CVT' for |
| 340 | Cape Verde Time. For summer time append `ST'; |
| 341 | for double summer time append `DST'; etc. |
| 342 | When a country has multiple time zones, take the first three |
| 343 | letters of an English place name identifying each zone |
| 344 | and then append `T', `ST', etc. as before; |
| 345 | e.g. `VLAST' for VLAdivostok Summer Time. |
| 346 | |
| 347 | Use UTC (with time zone abbreviation "zzz") for locations while |
| 348 | uninhabited. The "zzz" mnemonic is that these locations are, |
| 349 | in some sense, asleep. |
| 350 | |
| 351 | Application writers should note that these abbreviations are ambiguous |
| 352 | in practice: e.g. `EST' has a different meaning in Australia than |
| 353 | it does in the United States. In new applications, it's often better |
| 354 | to use numeric UTC offsets like `-0500' instead of time zone |
| 355 | abbreviations like `EST'; this avoids the ambiguity. |
| 356 | |
| 357 | |
| 358 | ----- Calendrical issues ----- |
| 359 | |
| 360 | Calendrical issues are a bit out of scope for a time zone database, |
| 361 | but they indicate the sort of problems that we would run into if we |
| 362 | extended the time zone database further into the past. An excellent |
| 363 | resource in this area is Edward M. Reingold and Nachum Dershowitz, |
| 364 | <a href="http://emr.cs.uiuc.edu/home/reingold/calendar-book/second-edition/"> |
| 365 | Calendrical Calculations: The Millennium Edition |
| 366 | </a>, Cambridge University Press (2001). Other information and |
| 367 | sources are given below. They sometimes disagree. |
| 368 | |
| 369 | |
| 370 | France |
| 371 | |
| 372 | Gregorian calendar adopted 1582-12-20. |
| 373 | French Revolutionary calendar used 1793-11-24 through 1805-12-31, |
| 374 | and (in Paris only) 1871-05-06 through 1871-05-23. |
| 375 | |
| 376 | |
| 377 | Russia |
| 378 | |
| 379 | From Chris Carrier (1996-12-02): |
| 380 | On 1929-10-01 the Soviet Union instituted an ``Eternal Calendar'' |
| 381 | with 30-day months plus 5 holidays, with a 5-day week. |
| 382 | On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the |
| 383 | Gregorian calendar while retaining the 6-day week; on 1940-06-27 it |
| 384 | reverted to the 7-day week. With the 6-day week the usual days |
| 385 | off were the 6th, 12th, 18th, 24th and 30th of the month. |
| 386 | (Source: Evitiar Zerubavel, _The Seven Day Circle_) |
| 387 | |
| 388 | |
| 389 | Mark Brader reported a similar story in "The Book of Calendars", edited |
| 390 | by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But: |
| 391 | |
| 392 | From: Petteri Sulonen (via Usenet) |
| 393 | Date: 14 Jan 1999 00:00:00 GMT |
| 394 | ... |
| 395 | |
| 396 | If your source is correct, how come documents between 1929 -- 1940 were |
| 397 | still dated using the conventional, Gregorian calendar? |
| 398 | |
| 399 | I can post a scan of a document dated December 1, 1934, signed by |
| 400 | Yenukidze, the secretary, on behalf of Kalinin, the President of the |
| 401 | Executive Committee of the Supreme Soviet, if you like. |
| 402 | |
| 403 | |
| 404 | |
| 405 | Sweden (and Finland) |
| 406 | |
| 407 | From: Mark Brader |
| 408 | <a href="news:1996Jul6.012937.29190@sq.com"> |
| 409 | Subject: Re: Gregorian reform -- a part of locale? |
| 410 | </a> |
| 411 | Date: 1996-07-06 |
| 412 | |
| 413 | In 1700, Denmark made the transition from Julian to Gregorian. Sweden |
| 414 | decided to *start* a transition in 1700 as well, but rather than have one of |
| 415 | those unsightly calendar gaps :-), they simply decreed that the next leap |
| 416 | year after 1696 would be in 1744 -- putting the whole country on a calendar |
| 417 | different from both Julian and Gregorian for a period of 40 years. |
| 418 | |
| 419 | However, in 1704 something went wrong and the plan was not carried through; |
| 420 | they did, after all, have a leap year that year. And one in 1708. In 1712 |
| 421 | they gave it up and went back to Julian, putting 30 days in February that |
| 422 | year!... |
| 423 | |
| 424 | Then in 1753, Sweden made the transition to Gregorian in the usual manner, |
| 425 | getting there only 13 years behind the original schedule. |
| 426 | |
| 427 | (A previous posting of this story was challenged, and Swedish readers |
| 428 | produced the following references to support it: "Tiderakning och historia" |
| 429 | by Natanael Beckman (1924) and "Tid, en bok om tiderakning och |
| 430 | kalendervasen" by Lars-Olof Lode'n (no date was given).) |
| 431 | |
| 432 | |
| 433 | Grotefend's data |
| 434 | |
| 435 | From: "Michael Palmer" [with one obvious typo fixed] |
| 436 | Subject: Re: Gregorian Calendar (was Re: Another FHC related question |
| 437 | Newsgroups: soc.genealogy.german |
| 438 | Date: Tue, 9 Feb 1999 02:32:48 -800 |
| 439 | ... |
| 440 | |
| 441 | The following is a(n incomplete) listing, arranged chronologically, of |
| 442 | European states, with the date they converted from the Julian to the |
| 443 | Gregorian calendar: |
| 444 | |
| 445 | 04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman |
| 446 | Catholics and Danzig only) |
| 447 | 09/20 Dec 1582 - France, Lorraine |
| 448 | |
| 449 | 21 Dec 1582/ |
| 450 | 01 Jan 1583 - Holland, Brabant, Flanders, Hennegau |
| 451 | 10/21 Feb 1583 - bishopric of Liege (L"uttich) |
| 452 | 13/24 Feb 1583 - bishopric of Augsburg |
| 453 | 04/15 Oct 1583 - electorate of Trier |
| 454 | 05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg, |
| 455 | Salzburg, Brixen |
| 456 | 13/24 Oct 1583 - Austrian Oberelsass and Breisgau |
| 457 | 20/31 Oct 1583 - bishopric of Basel |
| 458 | 02/13 Nov 1583 - duchy of J"ulich-Berg |
| 459 | 02/13 Nov 1583 - electorate and city of K"oln |
| 460 | 04/15 Nov 1583 - bishopric of W"urzburg |
| 461 | 11/22 Nov 1583 - electorate of Mainz |
| 462 | 16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden |
| 463 | 17/28 Nov 1583 - bishopric of M"unster and duchy of Cleve |
| 464 | 14/25 Dec 1583 - Steiermark |
| 465 | |
| 466 | 06/17 Jan 1584 - Austria and Bohemia |
| 467 | 11/22 Jan 1584 - Luzern, Uri, Schwyz, Zug, Freiburg, Solothurn |
| 468 | 12/23 Jan 1584 - Silesia and the Lausitz |
| 469 | 22 Jan/ |
| 470 | 02 Feb 1584 - Hungary (legally on 21 Oct 1587) |
| 471 | Jun 1584 - Unterwalden |
| 472 | 01/12 Jul 1584 - duchy of Westfalen |
| 473 | |
| 474 | 16/27 Jun 1585 - bishopric of Paderborn |
| 475 | |
| 476 | 14/25 Dec 1590 - Transylvania |
| 477 | |
| 478 | 22 Aug/ |
| 479 | 02 Sep 1612 - duchy of Prussia |
| 480 | |
| 481 | 13/24 Dec 1614 - Pfalz-Neuburg |
| 482 | |
| 483 | 1617 - duchy of Kurland (reverted to the Julian calendar in |
| 484 | 1796) |
| 485 | |
| 486 | 1624 - bishopric of Osnabr"uck |
| 487 | |
| 488 | 1630 - bishopric of Minden |
| 489 | |
| 490 | 15/26 Mar 1631 - bishopric of Hildesheim |
| 491 | |
| 492 | 1655 - Kanton Wallis |
| 493 | |
| 494 | 05/16 Feb 1682 - city of Strassburg |
| 495 | |
| 496 | 18 Feb/ |
| 497 | 01 Mar 1700 - Protestant Germany (including Swedish possessions in |
| 498 | Germany), Denmark, Norway |
| 499 | 30 Jun/ |
| 500 | 12 Jul 1700 - Gelderland, Zutphen |
| 501 | 10 Nov/ |
| 502 | 12 Dec 1700 - Utrecht, Overijssel |
| 503 | |
| 504 | 31 Dec 1700/ |
| 505 | 12 Jan 1701 - Friesland, Groningen, Z"urich, Bern, Basel, Geneva, |
| 506 | Turgau, and Schaffhausen |
| 507 | |
| 508 | 1724 - Glarus, Appenzell, and the city of St. Gallen |
| 509 | |
| 510 | 01 Jan 1750 - Pisa and Florence |
| 511 | |
| 512 | 02/14 Sep 1752 - Great Britain |
| 513 | |
| 514 | 17 Feb/ |
| 515 | 01 Mar 1753 - Sweden |
| 516 | |
| 517 | 1760-1812 - Graub"unden |
| 518 | |
| 519 | The Russian empire (including Finland and the Baltic states) did not |
| 520 | convert to the Gregorian calendar until the Soviet revolution of 1917. |
| 521 | |
| 522 | Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen |
| 523 | Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend |
| 524 | (Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28. |
| 525 | |
| 526 | |
| 527 | ----- Time and time zones on Mars ----- |
| 528 | |
| 529 | Some people have adjusted their work schedules to fit Mars time. |
| 530 | Dozens of special Mars watches were built for Jet Propulsion |
| 531 | Laboratory workers who kept Mars time during the Mars Exploration |
| 532 | Rovers mission (2004). These timepieces look like normal Seikos and |
| 533 | Citizens but use Mars seconds rather than terrestrial seconds. |
| 534 | |
| 535 | A Mars solar day is called a "sol" and has a mean period equal to |
| 536 | about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is |
| 537 | divided into a conventional 24-hour clock, so each Mars second equals |
| 538 | about 1.02749125 terrestrial seconds. |
| 539 | |
| 540 | The prime meridian of Mars goes through the center of the crater |
| 541 | Airy-0, named in honor of the British astronomer who built the |
| 542 | Greenwich telescope that defines Earth's prime meridian. Mean solar |
| 543 | time on the Mars prime meridian is called Mars Coordinated Time (MTC). |
| 544 | |
| 545 | Each landed mission on Mars has adopted a different reference for |
| 546 | solar time keeping, so there is no real standard for Mars time zones. |
| 547 | For example, the Mars Exploration Rover project (2004) defined two |
| 548 | time zones "Local Solar Time A" and "Local Solar Time B" for its two |
| 549 | missions, each zone designed so that its time equals local true solar |
| 550 | time at approximately the middle of the nominal mission. Such a "time |
| 551 | zone" is not particularly suited for any application other than the |
| 552 | mission itself. |
| 553 | |
| 554 | Many calendars have been proposed for Mars, but none have achieved |
| 555 | wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a |
| 556 | sequential count of Mars solar days elapsed since about 1873-12-29 |
| 557 | 12:00 GMT. |
| 558 | |
| 559 | The tz database does not currently support Mars time, but it is |
| 560 | documented here in the hopes that support will be added eventually. |
| 561 | |
| 562 | Sources: |
| 563 | |
| 564 | Michael Allison and Robert Schmunk, |
| 565 | "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" |
| 566 | <http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-07-30). |
| 567 | |
| 568 | Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times |
| 569 | (2004-01-14), pp A1, A20-A21. |