mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-25 11:37:56 +00:00
Cleanup (cont)
Remove Theory, which isn't part of the zoneinfo module but came out of /head/usr.sbin/zic (and isn't installed from there neither). Approved by: bde (implicit) MFC after: 1 week
This commit is contained in:
Edwin Groothuis
commit
4920bffd86
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=181413
@ -1,506 +0,0 @@
|
||||
@(#)Theory 7.13
|
||||
|
||||
|
||||
----- Outline -----
|
||||
|
||||
Time and date functions
|
||||
Names of time zone regions
|
||||
Time zone abbreviations
|
||||
Calendrical issues
|
||||
|
||||
|
||||
----- Time and date functions -----
|
||||
|
||||
These time and date functions are upwards compatible with POSIX.1,
|
||||
an international standard for Unix-like systems.
|
||||
As of this writing, the current edition of POSIX.1 is:
|
||||
|
||||
Information technology --Portable Operating System Interface (POSIX (R))
|
||||
-- Part 1: System Application Program Interface (API) [C Language]
|
||||
ISO/IEC 9945-1:1996
|
||||
ANSI/IEEE Std 1003.1, 1996 Edition
|
||||
1996-07-12
|
||||
|
||||
POSIX.1 has the following properties and limitations.
|
||||
|
||||
* In POSIX.1, time display in a process is controlled by the
|
||||
environment variable TZ. Unfortunately, the POSIX.1 TZ string takes
|
||||
a form that is hard to describe and is error-prone in practice.
|
||||
Also, POSIX.1 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.1 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.
|
||||
offset
|
||||
is of the form `[-]hh:[mm[:ss]]' and specifies the
|
||||
offset west of UTC. 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.
|
||||
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).
|
||||
|
||||
* In POSIX.1, when a TZ value like "EST5EDT" is parsed,
|
||||
typically the current US DST rules are used,
|
||||
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.1, 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.1 requires that systems ignore leap seconds.
|
||||
|
||||
These are the extensions that have been made to the POSIX.1 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.1, 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.)
|
||||
|
||||
* These functions can account for leap seconds, thanks to Bradley White
|
||||
(bww@k.cs.cmu.edu).
|
||||
|
||||
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 UTC.
|
||||
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.1, to ensure its broad
|
||||
acceptability. If more powerful time conversion functions can be standardized,
|
||||
so much the better.
|
||||
|
||||
|
||||
----- 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 simplifes 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 `/'). 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'.
|
||||
Include at least one location per time zone rule set per country.
|
||||
One such location is enough. Use ISO 3166 (see the file
|
||||
iso3166.tab) to help decide whether something is a country.
|
||||
If all the clocks in a country's 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 Jose 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 true name (which uses Greek letters).
|
||||
The POSIX file name restrictions encourage this rule.
|
||||
Use the most populous among locations in a country's time 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.
|
||||
|
||||
The file `zone.tab' lists the geographical locations used to name
|
||||
time zone rule files.
|
||||
|
||||
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', `EET' (see the file `europe'),
|
||||
and `Factory' (see the file `factory').
|
||||
|
||||
|
||||
----- Time zone abbreviations -----
|
||||
|
||||
When this package is installed, it generates time zone abbreviations
|
||||
like `EST' to be compatible with human tradition and POSIX.1.
|
||||
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.1 TZ string. POSIX.1
|
||||
requires at least three characters for an
|
||||
abbreviation. POSIX.1-1996 says that an abbreviation
|
||||
cannot start with ':', and cannot contain ',', '-',
|
||||
'+', NUL, or a digit. Draft 7 of POSIX 1003.1-200x
|
||||
changes this rule to say that an abbreviation can
|
||||
contain only '-', '+', and alphanumeric characters in
|
||||
the current locale. To be portable to both sets of
|
||||
rules, an abbreviation must therefore use only ASCII
|
||||
letters, as these are the only letters that are
|
||||
alphabetic in all locales.
|
||||
|
||||
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 has a single or principal time zone region,
|
||||
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.
|
||||
When a country has multiple time zones, take the first three
|
||||
letters of an English place name identifying each zone
|
||||
and then append `T', `ST', etc. as before;
|
||||
e.g. `VLAST' for VLAdivostok Summer Time.
|
||||
|
||||
Use "zzz" for locations while uninhabited. The mnemonic is that
|
||||
these locations are, in some sense, asleep.
|
||||
|
||||
Application writers should note that these abbreviations are ambiguous
|
||||
in practice: e.g. `EST' has a different meaning in Australia than
|
||||
it does in the United States. In new applications, it's often better
|
||||
to use numeric UTC offsets like `-0500' instead of time zone
|
||||
abbreviations like `EST'; 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,
|
||||
<a href="http://emr.cs.uiuc.edu/home/reingold/calendar-book/index.shtml">
|
||||
Calendrical Calculations
|
||||
</a>, Cambridge University Press (1997). 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 <72157.3334@CompuServe.COM> (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
|
||||
Message-ID: <Petteri.Sulonen-1401991626030001@lapin-kulta.in.helsinki.fi>
|
||||
|
||||
If your source is correct, how come documents between 1929 -- 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: msb@sq.com (Mark Brader)
|
||||
<a href="news:1996Jul6.012937.29190@sq.com">
|
||||
Subject: Re: Gregorian reform -- a part of locale?
|
||||
</a>
|
||||
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: "Tiderakning och historia"
|
||||
by Natanael Beckman (1924) and "Tid, en bok om tiderakning och
|
||||
kalendervasen" by Lars-Olof Lode'n (no date was given).)
|
||||
|
||||
|
||||
Grotefend's data
|
||||
|
||||
From: "Michael Palmer" <mpalmer@netcom.com> [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
|
||||
Message-ID: <199902091032.CAA09644@netcom10.netcom.com>
|
||||
|
||||
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"uttich)
|
||||
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 Oberelsass and Breisgau
|
||||
20/31 Oct 1583 - bishopric of Basel
|
||||
02/13 Nov 1583 - duchy of J"ulich-Berg
|
||||
02/13 Nov 1583 - electorate and city of K"oln
|
||||
04/15 Nov 1583 - bishopric of W"urzburg
|
||||
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"unster and duchy of Cleve
|
||||
14/25 Dec 1583 - Steiermark
|
||||
|
||||
06/17 Jan 1584 - Austria and Bohemia
|
||||
11/22 Jan 1584 - Luzern, 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"uck
|
||||
|
||||
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"urich, 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"unden
|
||||
|
||||
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.
|
||||
Loading…
Reference in New Issue
Block a user