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

1 files changed, 0 insertions, 506 deletions

diff --git a/share/zoneinfo/Theory b/share/zoneinfo/Theory
deleted file mode 100644
index 6d5efa0..0000000
--- a/share/zoneinfo/Theory
+++ /dev/null
@@ -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.