From 7d150a8685ded9b6d17a804713d890243837e486 Mon Sep 17 00:00:00 2001 From: Edwin Groothuis Date: Fri, 8 Aug 2008 02:44:04 +0000 Subject: [PATCH 1/2] Cleanup (cont) Remove Makefile, which isn't part of the distributed sources. Remove Theory, which isn't part of the distributed source but came out of /vendor/tzcode/. Approved by: bde (mentor, implicit) --- Makefile | 138 --------------- Theory | 506 ------------------------------------------------------- 2 files changed, 644 deletions(-) delete mode 100644 Makefile delete mode 100644 Theory diff --git a/Makefile b/Makefile deleted file mode 100644 index 710c0d27083b..000000000000 --- a/Makefile +++ /dev/null @@ -1,138 +0,0 @@ -# @(#)Makefile 8.1 (Berkeley) 6/8/93 - -# Change the line below for your time zone (after finding the zone you want in -# the time zone files, or adding it to a time zone file). -# Alternately, if you discover you've got the wrong time zone, you can just -# zic -l rightzone - -LOCALTIME= US/Pacific - -# If you want something other than Eastern United States time as a template -# for handling POSIX-style time zone environment variables, -# change the line below (after finding the zone you want in the -# time zone files, or adding it to a time zone file). -# Alternately, if you discover you've got the wrong time zone, you can just -# zic -p rightzone - -POSIXRULES= US/Pacific - -# Use an absolute path name for TZDIR unless you're just testing the software. - -TZDIR= ${DESTDIR}/usr/share/zoneinfo - -# If you always want time values interpreted as "seconds since the epoch -# (not counting leap seconds)", use -# REDO= posix_only -# below. If you always want right time values interpreted as "seconds since -# the epoch" (counting leap seconds)", use -# REDO= right_only -# below. If you want both sets of data available, with leap seconds not -# counted normally, use -# REDO= posix_right -# below. If you want both sets of data available, with leap seconds counted -# normally, use -# REDO= right_posix -# below. - -REDO= right_only - -# If you're running on a System V-style system and don't want lint grief, -# add -# -DUSG -# to the end of the "CFLAGS=" line. -# -# If you're running on a system where "strchr" is known as "index", -# (for example, a 4.[012]BSD system), add -# -Dstrchr=index -# to the end of the "CFLAGS=" line. -# -# If you're running on a system with a "mkdir" function, feel free to add -# -Demkdir=mkdir -# to the end of the "CFLAGS=" line -# -# If you want to use System V compatibility code, add -# -DUSG_COMPAT -# to the end of the "CFLAGS=" line. -# -# If your system has a "GMT offset" field in its "struct tm"s -# (or if you decide to add such a field in your system's "time.h" file), -# add the name to a define such as -# -DTM_GMTOFF=tm_gmtoff -# or -# -DTM_GMTOFF=_tm_gmtoff -# to the end of the "CFLAGS=" line. -# -# If your system has a "GMT offset" field in its "struct tm"s -# (or if you decide to add such a field in your system's "time.h" file), -# add the name to a define such as -# -DTM_ZONE=tm_zone -# or -# -DTM_ZONE=_tm_zone -# to the end of the "CFLAGS=" line. -# -# If you want code inspired by certain emerging standards, add -# -DSTD_INSPIRED -# to the end of the "CFLAGS=" line. -# -# If you want Source Code Control System ID's left out of object modules, add -# -DNOID -# to the end of the "CFLAGS=" line. -# -# If you'll never want to handle solar-time-based time zones, add -# -DNOSOLAR -# to the end of the "CFLAGS=" line -# (and comment out the "SDATA=" line below). -# -# If you want to allocate state structures in localtime, add -# -DALL_STATE -# to the end of the "CFLAGS=" line. -# -# If you want an "altzone" variable (a la System V Release 3.1), add -# -DALTZONE -# to the end of the "CFLAGS=" line. -# -# If you want a "gtime" function (a la MACH), add -# -DCMUCS -# to the end of the "CFLAGS=" line - -.PATH: ${.CURDIR}/datfiles -CFLAGS= -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -PROG= zic -MAN5= tzfile.0 - -SRCS= zic.c scheck.c ialloc.c - -YDATA= africa antarctica asia australasia europe northamerica \ - southamerica pacificnew etcetera factory -NDATA= systemv -#SDATA= solar87 solar88 solar89 -TDATA= ${YDATA} ${NDATA} ${SDATA} -DATA= ${YDATA} ${NDATA} ${SDATA} leapseconds -USNO= usno1988 usno1989 - -posix_only: ${TDATA} - (cd ${.CURDIR}/datfiles; \ - ../obj/zic -d ${TZDIR} -L /dev/null ${TDATA}) - -right_only: leapseconds ${TDATA} - (cd ${.CURDIR}/datfiles; \ - ../obj/zic -d ${TZDIR} -L leapseconds ${TDATA}) - -other_two: leapseconds ${TDATA} - (cd ${.CURDIR}/datfiles; \ - ../obj/zic -d ${TZDIR}/posix -L /dev/null ${TDATA}) - (cd ${.CURDIR}/datfiles; \ - ../obj/zic -d ${TZDIR}/right -L leapseconds ${TDATA}) - -posix_right: posix_only other_two - -right_posix: right_only other_two - -install: maninstall ${DATA} ${REDO} - (cd ${.CURDIR}/datfiles && ../obj/zic -d ${TZDIR} -p ${POSIXRULES}) - install -c -o ${BINOWN} -g ${BINGRP} -m 444 \ - ${TZDIR}/${LOCALTIME} ${DESTDIR}/etc/localtime - chown -R ${BINOWN}.${BINGRP} ${TZDIR} - chmod -R a-w ${TZDIR} - -.include diff --git a/Theory b/Theory deleted file mode 100644 index 6d5efa0decab..000000000000 --- a/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, - -Calendrical Calculations -, 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: - -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) - -Subject: Re: Gregorian reform -- a part of locale? - -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" [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. From c1ca882a0a1e0df7602757acf772f5a861680612 Mon Sep 17 00:00:00 2001 From: Edwin Groothuis Date: Fri, 8 Aug 2008 03:35:34 +0000 Subject: [PATCH 2/2] Vendor import of tzdata2008c - Africa/Morocco will have DST in 2008. - Asia/Choibalsan should be GMT+08:00. - Asia/Pakistan will have DST in 2008. Also set all the svn:eol-style properties to native. Approved by: bde (mentor, implicit), des --- africa | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- asia | 63 +++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 136 insertions(+), 4 deletions(-) diff --git a/africa b/africa index 434110ccd78c..3e15cba16fcd 100644 --- a/africa +++ b/africa @@ -1,4 +1,4 @@ -# @(#)africa 8.10 +# @(#)africa 8.11 # 
 
 # This data is by no means authoritative; if you think you know better,
@@ -400,6 +400,77 @@ Zone	Indian/Mayotte	3:00:56 -	LMT	1911 Jul	# Mamoutzou
 
 # Morocco
 # See the `europe' file for Spanish Morocco (Africa/Ceuta).
+
+# From Alex Krivenyshev (2008-05-09):
+# Here is an article that Morocco plan to introduce Daylight Saving Time between
+# 1 June, 2008 and 27 September, 2008.
+#
+# "... Morocco is to save energy by adjusting its clock during summer so it will
+# be one hour ahead of GMT between 1 June and 27 September, according to
+# Communication Minister and Gov ernment Spokesman, Khalid Naciri...."
+#
+# 
+# http://www.worldtimezone.net/dst_news/dst_news_morocco01.html
+# 
+# OR
+# 
+# http://en.afrik.com/news11892.html
+# 
+
+# From Alex Krivenyshev (2008-05-09):
+# The Morocco time change can be confirmed on Morocco web site Maghreb Arabe Presse:
+# 
+# http://www.map.ma/eng/sections/box3/morocco_shifts_to_da/view
+# 
+#
+# Morocco shifts to daylight time on June 1st through September 27, Govt.
+# spokesman.
+
+# From Patrice Scattolin (2008-05-09):
+# According to this article:
+# 
+# http://www.avmaroc.com/actualite/heure-dete-comment-a127896.html
+# 
+# (and republished here:
+# 
+# http://www.actu.ma/heure-dete-comment_i127896_0.html
+# 
+# )
+# the changes occurs at midnight:
+#
+# saturday night may 31st at midnight (which in french is to be
+# intrepreted as the night between saturday and sunday)
+# sunday night the 28th  at midnight
+#
+# Seeing that the 28th is monday, I am guessing that she intends to say
+# the midnight of the 28th which is the midnight between sunday and
+# monday, which jives with other sources that say that it's inclusive
+# june1st to sept 27th.
+#
+# The decision was taken by decree *2-08-224 *but I can't find the decree
+# published on the web.
+#
+# It's also confirmed here:
+# 
+# http://www.maroc.ma/NR/exeres/FACF141F-D910-44B0-B7FA-6E03733425D1.htm
+# 
+# on a government portal as being  between june 1st and sept 27th (not yet
+# posted in english).
+#
+# The following google query will generate many relevant hits:
+# 
+# http://www.google.com/search?hl=en&q=Conseil+de+gouvernement+maroc+heure+avance&btnG=Search
+# 
+
+# From Alex Krivenyshev (2008-05-09):
+# Is Western Sahara (part which administrated by Morocco) going to follow
+# Morocco DST changes?  Any information?  What about other part of
+# Western Sahara - under administration of POLISARIO Front (also named
+# SADR Saharawi Arab Democratic Republic)?
+
+# From Arthur David Olson (2008-05-09):
+# XXX--guess that it is only Morocco for now; guess only 2008 for now.
+
 # RULE	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
 Rule	Morocco	1939	only	-	Sep	12	 0:00	1:00	S
 Rule	Morocco	1939	only	-	Nov	19	 0:00	0	-
@@ -416,11 +487,13 @@ Rule	Morocco	1976	only	-	Aug	 1	 0:00	0	-
 Rule	Morocco	1977	only	-	Sep	28	 0:00	0	-
 Rule	Morocco	1978	only	-	Jun	 1	 0:00	1:00	S
 Rule	Morocco	1978	only	-	Aug	 4	 0:00	0	-
+Rule	Morocco	2008	only	-	Jun	 1	 0:00	1:00	S
+Rule	Morocco	2008	only	-	Sep	28	 0:00	0	-
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
 Zone Africa/Casablanca	-0:30:20 -	LMT	1913 Oct 26
 			 0:00	Morocco	WE%sT	1984 Mar 16
 			 1:00	-	CET	1986
-			 0:00	-	WET
+			 0:00	Morocco	WE%sT
 # Western Sahara
 Zone Africa/El_Aaiun	-0:52:48 -	LMT	1934 Jan
 			-1:00	-	WAT	1976 Apr 14
diff --git a/asia b/asia
index 70f15153214d..b72cfc843d06 100644
--- a/asia
+++ b/asia
@@ -1,4 +1,4 @@
-# @(#)asia	8.18
+# @(#)asia	8.20
 # 
 
 # This data is by no means authoritative; if you think you know better,
@@ -1376,6 +1376,42 @@ Zone	Indian/Maldives	4:54:00 -	LMT	1880	# Male
 # They decided not to adopt daylight-saving time....
 # http://www.mongolnews.mn/index.php?module=unuudur&sec=view&id=15742
 
+# From Deborah Goldsmith (2008-03-30):
+# We received a bug report claiming that the tz database UTC offset for
+# Asia/Choibalsan (GMT+09:00) is incorrect, and that it should be GMT
+# +08:00 instead. Different sources appear to disagree with the tz
+# database on this, e.g.:
+#
+# 
+# http://www.timeanddate.com/worldclock/city.html?n=1026
+# 
+# 
+# http://www.worldtimeserver.com/current_time_in_MN.aspx
+# 
+#
+# both say GMT+08:00.
+
+# From Steffen Thorsen (2008-03-31):
+# eznis airways, which operates several domestic flights, has a flight
+# schedule here:
+# 
+# (click the English flag for English)
+#
+# There it appears that flights between Choibalsan and Ulaanbatar arrive
+# about 1:35 - 1:50 hours later in local clock time, no matter the
+# direction, while Ulaanbaatar-Khvod takes 2 hours in the Eastern
+# direction and 3:35 back, which indicates that Ulaanbatar and Khvod are
+# in different time zones (like we know about), while Choibalsan and
+# Ulaanbatar are in the same time zone (correction needed).
+
+# From Arthur David Olson (2008-05-19):
+# Assume that Choibalsan is indeed offset by 8:00.
+# XXX--in the absence of better information, assume that transition
+# was at the start of 2008-03-31 (the day of Steffen Thorsen's report);
+# this is almost surely wrong.
+
 # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
 Rule	Mongol	1983	1984	-	Apr	1	0:00	1:00	S
 Rule	Mongol	1983	only	-	Oct	1	0:00	0	-
@@ -1411,7 +1447,8 @@ Zone	Asia/Ulaanbaatar 7:07:32 -	LMT	1905 Aug
 Zone	Asia/Choibalsan	7:38:00 -	LMT	1905 Aug
 			7:00	-	ULAT	1978
 			8:00	-	ULAT	1983 Apr
-			9:00	Mongol	CHO%sT	# Choibalsan Time
+			9:00	Mongol	CHO%sT	2008 Mar 31 # Choibalsan Time
+			8:00	Mongol	CHO%sT
 
 # Nepal
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
@@ -1461,10 +1498,32 @@ Zone	Asia/Muscat	3:54:20 -	LMT	1920
 # The minister told a news conference that the experiment had rather
 # shown 8 per cent higher consumption of electricity.
 
+# From Alex Krivenyshev (2008-05-15):
+# 
+# Here is an article that Pakistan plan to introduce Daylight Saving Time 
+# on June 1, 2008 for 3 months.
+# 
+# "... The federal cabinet on Wednesday announced a new conservation plan to help 
+# reduce load shedding by approving the closure of commercial centres at 9pm and 
+# moving clocks forward by one hour for the next three months. 
+# ...."
+# 
+# 
+# http://www.worldtimezone.net/dst_news/dst_news_pakistan01.html
+# 
+# OR
+# 
+# http://www.dailytimes.com.pk/default.asp?page=2008%5C05%5C15%5Cstory_15-5-2008_pg1_4
+# 
+
+# From Arthur David Olson (2008-05-19):
+# XXX--midnight transitions is a guess; 2008 only is a guess.
 
 # Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
 Rule Pakistan	2002	only	-	Apr	Sun>=2	0:01	1:00	S
 Rule Pakistan	2002	only	-	Oct	Sun>=2	0:01	0	-
+Rule Pakistan	2008	only	-	Jun	1	0:00	1:00	S
+Rule Pakistan	2008	only	-	Sep	1	0:00	0	-
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
 Zone	Asia/Karachi	4:28:12 -	LMT	1907
 			5:30	-	IST	1942 Sep