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