Sync zoneinfo database with tzdata2015f from ftp://ftp.iana.org/tz/releases
authorSascha Wildner <saw@online.de>
Thu, 13 Aug 2015 16:15:56 +0000 (18:15 +0200)
committerSascha Wildner <saw@online.de>
Thu, 13 Aug 2015 16:15:56 +0000 (18:15 +0200)
* asia: North Korea switches to +0830 on 2015-08-15. (Thanks to
    Steffen Thorsen.) The abbreviation remains "KST". (Thanks to
    Robert Elz.)

* europe: Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
    (Thanks to Roman Tudos.) Also mention that Herbert Samuel
    introduced the term "Summer Time".

* northamerica: Comments for America/Halifax and America/Glace_Bay have
    been improved. (Thanks to Brian Inglis.)

* southamerica: Uruguay no longer observes DST. (Thanks to
    Steffen Thorsen and Pablo Camargo.)

* Theory: The Theory file mentions naming issues earlier, as these seem
    to be poorly publicized (thanks to Gilmore Davidson for reporting
    the problem).

* Various: Data entries have been simplified for Atlantic/Canary,
    Europe/Simferopol, Europe/Sofia, and Europe/Tallinn.  This yields
    slightly smaller installed data files for Europe/Simferopol and
    Europe/Tallinn. It does not affect timestamps. (Thanks to
    Howard Hinnant.)

share/zoneinfo/NEWS
share/zoneinfo/Theory
share/zoneinfo/africa
share/zoneinfo/asia
share/zoneinfo/europe
share/zoneinfo/leapseconds
share/zoneinfo/northamerica
share/zoneinfo/southamerica
share/zoneinfo/zone.tab

index 7b0e0b5..b477250 100644 (file)
@@ -1,5 +1,71 @@
 News for the tz database
 
+Release 2015f - 2015-08-10 18:06:56 -0700
+
+  Changes affecting future time stamps
+
+    North Korea switches to +0830 on 2015-08-15.  (Thanks to Steffen Thorsen.)
+    The abbreviation remains "KST".  (Thanks to Robert Elz.)
+
+    Uruguay no longer observes DST.  (Thanks to Steffen Thorsen
+    and Pablo Camargo.)
+
+  Changes affecting past and future time stamps
+
+    Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
+    (Thanks to Roman Tudos.)
+
+  Changes affecting data format and code
+
+    zic's '-y YEARISTYPE' option is no longer documented.  The TYPE
+    field of a Rule line should now be '-'; the old values 'even',
+    'odd', 'uspres', 'nonpres', 'nonuspres' were already undocumented.
+    Although the implementation has not changed, these features do not
+    work in the default installation, they are not used in the data,
+    and they are now considered obsolescent.
+
+    zic now checks that two rules don't take effect at the same time.
+    (Thanks to Jon Skeet and Arthur David Olson.)  Constraints on
+    simultaneity are now documented.
+
+    The two characters '%z' in a zone format now stand for the UTC
+    offset, e.g., '-07' for seven hours behind UTC and '+0530' for
+    five hours and thirty minutes ahead.  This better supports time
+    zone abbreviations conforming to POSIX.1-2001 and later.
+
+  Changes affecting installed data files
+
+    Comments for America/Halifax and America/Glace_Bay have been improved.
+    (Thanks to Brian Inglis.)
+
+    Data entries have been simplified for Atlantic/Canary, Europe/Simferopol,
+    Europe/Sofia, and Europe/Tallinn.  This yields slightly smaller
+    installed data files for Europe/Simferopol and Europe/Tallinn.
+    It does not affect timestamps.  (Thanks to Howard Hinnant.)
+
+  Changes affecting code
+
+    zdump and zic no longer warn about valid time zone abbreviations
+    like '-05'.
+
+    Some Visual Studio 2013 warnings have been suppressed.
+    (Thanks to Kees Dekker.)
+
+    'date' no longer sets the time of day and its -a, -d, -n and -t
+    options have been removed.  Long obsolescent, the implementation
+    of these features had porting problems.  Builders no longer need
+    to configure HAVE_ADJTIME, HAVE_SETTIMEOFDAY, or HAVE_UTMPX_H.
+    (Thanks to Kees Dekker for pointing out the problem.)
+
+  Changes affecting documentation
+
+    The Theory file mentions naming issues earlier, as these seem to be
+    poorly publicized (thanks to Gilmore Davidson for reporting the problem).
+
+    tz-link.htm mentions Time Zone Database Parser (thanks to Howard Hinnant).
+
+    Mention that Herbert Samuel introduced the term "Summer Time".
+
 
 Release 2015e - 2015-06-13 10:56:02 -0700
 
index 9861a4f..96cba51 100644 (file)
-This file is in the public domain, so clarified as of
-2009-05-17 by Arthur David Olson.
+Theory and pragmatics of the tz code and data
+
 
 ----- Outline -----
 
-       Time and date functions
        Scope of the tz database
-       Names of time zone rule files
+       Names of time zone rules
        Time zone abbreviations
+       Accuracy of the tz database
+       Time and date functions
        Calendrical issues
        Time and time zones on Mars
 
------ Time and date functions -----
 
-These time and date functions are upwards compatible with those of POSIX,
-an international standard for UNIX-like systems.
-As of this writing, the current edition of POSIX is:
+----- Scope of the tz database -----
+
+The tz database attempts to record the history and predicted future of
+all computer-based clocks that track civil time.  To represent this
+data, the world is partitioned into regions whose clocks all agree
+about time stamps that occur after the somewhat-arbitrary cutoff point
+of the POSIX Epoch (1970-01-01 00:00:00 UTC).  For each such region,
+the database records all known clock transitions, and labels the region
+with a notable location.  Although 1970 is a somewhat-arbitrary
+cutoff, there are significant challenges to moving the cutoff earlier
+even by a decade or two, due to the wide variety of local practices
+before computer timekeeping became prevalent.
+
+Clock transitions before 1970 are recorded for each such location,
+because most systems support time stamps before 1970 and could
+misbehave if data entries were omitted for pre-1970 transitions.
+However, the database is not designed for and does not suffice for
+applications requiring accurate handling of all past times everywhere,
+as it would take far too much effort and guesswork to record all
+details of pre-1970 civil timekeeping.
+
+As described below, reference source code for using the tz database is
+also available.  The tz code is upwards compatible with POSIX, an
+international standard for UNIX-like systems.  As of this writing, the
+current edition of POSIX is:
 
   The Open Group Base Specifications Issue 7
   IEEE Std 1003.1, 2013 Edition
   <http://pubs.opengroup.org/onlinepubs/9699919799/>
 
-POSIX has the following properties and limitations.
 
-*      In POSIX, time display in a process is controlled by the
-       environment variable TZ.  Unfortunately, the POSIX TZ string takes
-       a form that is hard to describe and is error-prone in practice.
-       Also, POSIX 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 TZ string takes the following form:
 
-               stdoffset[dst[offset][,date[/time],date[/time]]]
+----- Names of time zone rules -----
 
-       where:
+Each of the database's time zone rules has a unique name.
+Inexperienced users are not expected to select these names unaided.
+Distributors should provide documentation and/or a simple selection
+interface that explains the names; for one example, see the 'tzselect'
+program in the tz code.  The Unicode Common Locale Data Repository
+<http://cldr.unicode.org/> contains data that may be useful for other
+selection interfaces.
 
-       std and dst
-               are 3 or more characters specifying the standard
-               and daylight saving time (DST) zone names.
-               Starting with POSIX.1-2001, std and dst may also be
-               in a quoted form like "<UTC+10>"; this allows
-               "+" and "-" in the names.
-       offset
-               is of the form '[+-]hh:[mm[:ss]]' and specifies the
-               offset west of UT.  'hh' may be a single digit; 0<=hh<=24.
-               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.
-               This is the same format as the offset, except that a
-               leading '+' or '-' is not allowed.
-       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).
-                       Typically, this is the only useful form;
-                       the n and Jn forms are rarely used.
-
-       Here is an example POSIX TZ string, for US Pacific time using rules
-       appropriate from 1987 through 2006:
-
-               TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00'
+The time zone rule naming conventions attempt to strike a balance
+among the following goals:
 
-       This POSIX TZ string is hard to remember, and mishandles time stamps
-       before 1987 and after 2006.  With this package you can use this
-       instead:
+ * Uniquely identify every region where clocks have agreed since 1970.
+   This is essential for the intended use: static clocks keeping local
+   civil time.
 
-               TZ='America/Los_Angeles'
+ * Indicate to experts where that region is.
 
-*      POSIX does not define the exact meaning of TZ values like "EST5EDT".
-       Typically the current US DST rules are used to interpret such values,
-       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.
+ * Be robust in the presence of political changes.  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).
 
-*      In POSIX, 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.)
+ * Be portable to a wide variety of implementations.
 
-*      POSIX requires that systems ignore leap seconds.
+ * Use a consistent naming conventions over the entire world.
 
-*      The tz code attempts to support all the time_t implementations
-       allowed by POSIX.  The time_t type represents a nonnegative count of
-       seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds.
-       In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit
-       signed time_t values stop working after 2038-01-19 03:14:07 UTC, so
-       new implementations these days typically use a signed 64-bit integer.
-       Unsigned 32-bit integers are used on one or two platforms,
-       and 36-bit and 40-bit integers are also used occasionally.
-       Although earlier POSIX versions allowed time_t to be a
-       floating-point type, this was not supported by any practical
-       systems, and POSIX.1-2013 and the tz code both require time_t
-       to be an integer type.
+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'.
 
-These are the extensions that have been made to the POSIX functions:
+Here are the general rules used for choosing location names,
+in decreasing order of importance:
 
-*      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.
+       Use only valid POSIX file name components (i.e., the parts of
+               names other than '/').  Do not use the file name
+               components '.' and '..'.  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'.  Exceptions: see the discussion
+               of legacy names below.
+       A name must not be empty, or contain '//', or start or end with '/'.
+       Do not use names that differ only in case.  Although the reference
+               implementation is case-sensitive, some other implementations
+               are not, and they would mishandle names differing only in case.
+       If one name A is an initial prefix of another name AB (ignoring case),
+               then B must not start with '/', as a regular file cannot have
+               the same name as a directory in POSIX.  For example,
+               'America/New_York' precludes 'America/New_York/Bronx'.
+       Uninhabited regions like the North Pole and Bouvet Island
+               do not need locations, since local time is not defined there.
+       There should typically be at least one name for each ISO 3166-1
+               officially assigned two-letter code for an inhabited country
+               or territory.
+       If all the clocks in a 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 José 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 Greek 'Αθήνα' or the Romanized 'Athína'.
+               The POSIX file name restrictions encourage this rule.
+       Use the most populous among locations in a 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.
+               This means old spellings will continue to work.
 
-       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).
+The file 'zone1970.tab' lists geographical locations used to name time
+zone rules.  It is intended to be an exhaustive list of names for
+geographic regions as described above; this is a subset of the names
+in the data.  Although a 'zone1970.tab' location's longitude
+corresponds to its LMT offset with one hour for every 15 degrees east
+longitude, this relationship is not exact.
 
-*      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, where the elements
-       of tzname are only changed as a result of calls to tzset.
+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', and 'EET' (see the file 'europe').
 
-*      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.")
+Older versions of this package defined legacy names that are
+incompatible with the first rule of location names, but which are
+still supported.  These legacy names are mostly defined in the file
+'etcetera'.  Also, the file 'backward' defines the legacy names
+'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file
+'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
+'MST7MDT', and 'PST8PDT'.
 
-*      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).
+Excluding 'backward' should not affect the other data.  If
+'backward' is excluded, excluding 'etcetera' should not affect the
+remaining data.
 
-*      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.)
 
-*      Negative time_t values are supported, on systems where time_t is signed.
+----- Time zone abbreviations -----
 
-*      These functions can account for leap seconds, thanks to Bradley White.
+When this package is installed, it generates time zone abbreviations
+like 'EST' to be compatible with human tradition and POSIX.
+Here are the general rules used for choosing time zone abbreviations,
+in decreasing order of importance:
 
-Points of interest to folks with other systems:
+       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 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.
+               This rule guarantees that all abbreviations could have
+               been specified by a POSIX TZ string.  POSIX
+               requires at least three characters for an
+               abbreviation.  POSIX through 2000 says that an abbreviation
+               cannot start with ':', and cannot contain ',', '-',
+               '+', NUL, or a digit.  POSIX from 2001 on changes this
+               rule to say that an abbreviation can contain only '-', '+',
+               and alphanumeric characters from the portable character set
+               in the current locale.  To be portable to both sets of
+               rules, an abbreviation must therefore use only ASCII
+               letters.
 
-*      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.
+       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'.
 
-*      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.
+       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'.
 
-*      In SVR2, time conversion fails for near-minimum or near-maximum
-       time_t values when doing conversions for places that don't use UT.
-       This package takes care to do these conversions correctly.
+       Use 'LMT' for local mean time of locations before the introduction
+               of standard time; see "Scope of the tz database".
 
-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.
+       If there is no common English abbreviation, use numeric offsets like
+               -05 and +0830 that are generated by zic's %z notation.
 
-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, to ensure its broad acceptability.  If
-more powerful time conversion functions can be standardized, so much the
-better.
+    [The remaining guidelines predate the introduction of %z.
+    They are problematic as they mean tz data entries invent
+    notation rather than record it.  These guidelines are now
+    deprecated and the plan is to gradually move to %z for
+    inhabited locations and to "-00" for uninhabited locations.]
 
+       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:
 
------ Scope of the tz database -----
+               When a country is identified with a single or principal zone,
+                       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.
+               Otherwise, take the first three letters of an English place
+                       name identifying each zone and append 'T', 'ST', etc.
+                       as before; e.g. 'VLAST' for VLAdivostok Summer Time.
 
-The tz database attempts to record the history and predicted future of
-all computer-based clocks that track civil time.  To represent this
-data, the world is partitioned into regions whose clocks all agree
-about time stamps that occur after the somewhat-arbitrary cutoff point
-of the POSIX Epoch (1970-01-01 00:00:00 UTC).  For each such region,
-the database records all known clock transitions, and labels the region
-with a notable location.  Although 1970 is a somewhat-arbitrary
-cutoff, there are significant challenges to moving the cutoff earlier
-even by a decade or two, due to the wide variety of local practices
-before computer timekeeping became prevalent.
+       Use UT (with time zone abbreviation 'zzz') for locations while
+               uninhabited.  The 'zzz' mnemonic is that these locations are,
+               in some sense, asleep.
 
-Clock transitions before 1970 are recorded for each such location,
-because most POSIX-compatible systems support negative time stamps and
-could misbehave if data entries were omitted for pre-1970 transitions.
-However, the database is not designed for and does not suffice for
-applications requiring accurate handling of all past times everywhere,
-as it would take far too much effort and guesswork to record all
-details of pre-1970 civil timekeeping.
+Application writers should note that these abbreviations are ambiguous
+in practice: e.g. 'CST' has a different meaning in China than
+it does in the United States.  In new applications, it's often better
+to use numeric UT offsets like '-0600' instead of time zone
+abbreviations like 'CST'; this avoids the ambiguity.
 
 
 ----- Accuracy of the tz database -----
@@ -358,194 +369,197 @@ creation of zones merely because two locations differ in LMT or
 transitioned to standard time at different dates.
 
 
------ Names of time zone rule files -----
+----- Time and date functions -----
 
-The time zone rule file naming conventions attempt to strike a balance
-among the following goals:
+The tz code contains time and date functions that are upwards
+compatible with those of POSIX.
+
+POSIX has the following properties and limitations.
+
+*      In POSIX, time display in a process is controlled by the
+       environment variable TZ.  Unfortunately, the POSIX TZ string takes
+       a form that is hard to describe and is error-prone in practice.
+       Also, POSIX 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 TZ string takes the following form:
+
+               stdoffset[dst[offset][,date[/time],date[/time]]]
 
- * 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.
+       where:
+
+       std and dst
+               are 3 or more characters specifying the standard
+               and daylight saving time (DST) zone names.
+               Starting with POSIX.1-2001, std and dst may also be
+               in a quoted form like "<UTC+10>"; this allows
+               "+" and "-" in the names.
+       offset
+               is of the form '[+-]hh:[mm[:ss]]' and specifies the
+               offset west of UT.  'hh' may be a single digit; 0<=hh<=24.
+               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.
+               This is the same format as the offset, except that a
+               leading '+' or '-' is not allowed.
+       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).
+                       Typically, this is the only useful form;
+                       the n and Jn forms are rarely used.
 
- * Indicate to humans as to where that region is.  This simplifies use.
+       Here is an example POSIX TZ string, for US Pacific time using rules
+       appropriate from 1987 through 2006:
 
- * 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).
+               TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00'
 
- * Be portable to a wide variety of implementations.
-   This promotes use of the technology.
+       This POSIX TZ string is hard to remember, and mishandles time stamps
+       before 1987 and after 2006.  With this package you can use this
+       instead:
 
- * Use a consistent naming convention over the entire world.
-   This simplifies both use and maintenance.
+               TZ='America/Los_Angeles'
 
-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.
+*      POSIX does not define the exact meaning of TZ values like "EST5EDT".
+       Typically the current US DST rules are used to interpret such values,
+       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.
 
-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'.
+*      In POSIX, 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.)
 
-Here are the general rules used for choosing location names,
-in decreasing order of importance:
+*      POSIX requires that systems ignore leap seconds.
 
-       Use only valid POSIX file name components (i.e., the parts of
-               names other than '/').  Do not use the file name
-               components '.' and '..'.  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'.  Exceptions: see the discussion
-               of legacy names below.
-       A name must not be empty, or contain '//', or start or end with '/'.
-       Do not use names that differ only in case.  Although the reference
-               implementation is case-sensitive, some other implementations
-               are not, and they would mishandle names differing only in case.
-       If one name A is an initial prefix of another name AB (ignoring case),
-               then B must not start with '/', as a regular file cannot have
-               the same name as a directory in POSIX.  For example,
-               'America/New_York' precludes 'America/New_York/Bronx'.
-       Uninhabited regions like the North Pole and Bouvet Island
-               do not need locations, since local time is not defined there.
-       There should typically be at least one name for each ISO 3166-1
-               officially assigned two-letter code for an inhabited country
-               or territory.
-       If all the clocks in a 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 José 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 Greek 'Αθήνα' or the Romanized 'Athína'.
-               The POSIX file name restrictions encourage this rule.
-       Use the most populous among locations in a 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.
-               This means old spellings will continue to work.
+*      The tz code attempts to support all the time_t implementations
+       allowed by POSIX.  The time_t type represents a nonnegative count of
+       seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds.
+       In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit
+       signed time_t values stop working after 2038-01-19 03:14:07 UTC, so
+       new implementations these days typically use a signed 64-bit integer.
+       Unsigned 32-bit integers are used on one or two platforms,
+       and 36-bit and 40-bit integers are also used occasionally.
+       Although earlier POSIX versions allowed time_t to be a
+       floating-point type, this was not supported by any practical
+       systems, and POSIX.1-2013 and the tz code both require time_t
+       to be an integer type.
 
-The file 'zone1970.tab' lists geographical locations used to name time
-zone rule files.  It is intended to be an exhaustive list of names
-for geographic regions as described above; this is a subset of the
-names in the data.  Although a 'zone1970.tab' location's longitude
-corresponds to its LMT offset with one hour for every 15 degrees east
-longitude, this relationship is not exact.
+These are the extensions that have been made to the POSIX functions:
 
-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', and 'EET' (see the file 'europe').
+*      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.
 
-Older versions of this package defined legacy names that are
-incompatible with the first rule of location names, but which are
-still supported.  These legacy names are mostly defined in the file
-'etcetera'.  Also, the file 'backward' defines the legacy names
-'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file
-'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
-'MST7MDT', and 'PST8PDT'.
+       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).
 
-Excluding 'backward' should not affect the other data.  If
-'backward' is excluded, excluding 'etcetera' should not affect the
-remaining data.
+*      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, 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.")
 
------ Time zone abbreviations -----
+*      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).
 
-When this package is installed, it generates time zone abbreviations
-like 'EST' to be compatible with human tradition and POSIX.
-Here are the general rules used for choosing time zone abbreviations,
-in decreasing order of importance:
+*      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.)
 
-       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.
+*      Negative time_t values are supported, on systems where time_t is signed.
 
-               This rule guarantees that all abbreviations could have
-               been specified by a POSIX TZ string.  POSIX
-               requires at least three characters for an
-               abbreviation.  POSIX through 2000 says that an abbreviation
-               cannot start with ':', and cannot contain ',', '-',
-               '+', NUL, or a digit.  POSIX from 2001 on changes this
-               rule to say that an abbreviation can contain only '-', '+',
-               and alphanumeric characters from the portable character set
-               in the current locale.  To be portable to both sets of
-               rules, an abbreviation must therefore use only ASCII
-               letters.
+*      These functions can account for leap seconds, thanks to Bradley White.
 
-       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'.
+Points of interest to folks with other systems:
 
-       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'.
+*      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.
 
-       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:
+*      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.
 
-               When a country is identified with a single or principal zone,
-                       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.
-               Otherwise, take the first three letters of an English place
-                       name identifying each zone and append 'T', 'ST', etc.
-                       as before; e.g. 'VLAST' for VLAdivostok Summer Time.
+*      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.
 
-       Use 'LMT' for local mean time of locations before the introduction
-               of standard time; see "Scope of the tz database".
+*      In SVR2, time conversion fails for near-minimum or near-maximum
+       time_t values when doing conversions for places that don't use UT.
+       This package takes care to do these conversions correctly.
 
-       Use UT (with time zone abbreviation 'zzz') for locations while
-               uninhabited.  The 'zzz' mnemonic is that these locations are,
-               in some sense, asleep.
+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.
 
-Application writers should note that these abbreviations are ambiguous
-in practice: e.g. 'CST' has a different meaning in China than
-it does in the United States.  In new applications, it's often better
-to use numeric UT offsets like '-0600' instead of time zone
-abbreviations like 'CST'; this avoids the ambiguity.
+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, to ensure its broad acceptability.  If
+more powerful time conversion functions can be standardized, so much the
+better.
 
 
 ----- Calendrical issues -----
@@ -765,6 +779,11 @@ Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times
 Tom Chmielewski, "Jet Lag Is Worse on Mars", The Atlantic (2015-02-26)
 <http://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/>
 
+-----
+
+This file is in the public domain, so clarified as of 2009-05-17 by
+Arthur David Olson.
+
 -----
 Local Variables:
 coding: utf-8
index 5ad47e3..f20d216 100644 (file)
@@ -538,7 +538,7 @@ Zone        Africa/Tripoli  0:52:44 -       LMT     1920
 
 # From Alex Krivenyshev (2008-07-11):
 # Seems that English language article "The revival of daylight saving
-# time: Energy conservation?"-# No. 16578 (07/11/2008) was originally
+# time: Energy conservation?"- No. 16578 (07/11/2008) was originally
 # published on Monday, June 30, 2008...
 #
 # I guess that article in French "Le gouvernement avance l'introduction
@@ -670,7 +670,7 @@ Zone Indian/Mauritius       3:50:00 -       LMT     1907 # Port Louis
 # Here is a link to official document from Royaume du Maroc Premier Ministre,
 # Ministère de la Modernisation des Secteurs Publics
 #
-# Under Article 1 of Royal Decree No. 455-67 of Act 23 safar 1387 (2 june 1967)
+# Under Article 1 of Royal Decree No. 455-67 of Act 23 safar 1387 (2 June 1967)
 # concerning the amendment of the legal time, the Ministry of Modernization of
 # Public Sectors announced that the official time in the Kingdom will be
 # advanced 60 minutes from Sunday 31 May 2009 at midnight.
index 756e3d0..4f8756b 100644 (file)
@@ -6,7 +6,7 @@
 # tz@iana.org for general use in the future).  For more, please see
 # the file CONTRIBUTING in the tz distribution.
 
-# From Paul Eggert (2014-10-31):
+# From Paul Eggert (2015-08-08):
 #
 # Unless otherwise specified, the source for data through 1990 is:
 # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th edition),
@@ -43,7 +43,7 @@
 #      2:00 EET  EEST  Eastern European Time
 #      2:00 IST  IDT   Israel
 #      3:00 AST  ADT   Arabia*
-#      3:30 IRST IRDT  Iran
+#      3:30 IRST IRDT  Iran*
 #      4:00 GST        Gulf*
 #      5:30 IST        India
 #      7:00 ICT        Indochina, most times and locations*
 #      8:00 CST        China
 #      8:00 IDT        Indochina, 1943-45, 1947-55, 1960-75 (some locations)*
 #      8:00 JWST       Western Standard Time (Japan, 1896/1937)*
+#      8:30 KST  KDT   Korea when at +0830*
 #      9:00 JCST       Central Standard Time (Japan, 1896/1937)
 #      9:00 WIT        east Indonesia (Waktu Indonesia Timur)
 #      9:00 JST  JDT   Japan
-#      9:00 KST  KDT   Korea
+#      9:00 KST  KDT   Korea when at +09
 #      9:30 ACST       Australian Central Standard Time
 #
 # See the 'europe' file for Russia and Turkey in Asia.
@@ -1027,7 +1028,7 @@ Zone Asia/Jayapura        9:22:48 -       LMT     1932 Nov
 #
 # From Roozbeh Pournader (2007-11-05):
 # This is quoted from Official Gazette of the Islamic Republic of
-# Iran, Volume 63, Number 18242, dated Tuesday 1386/6/24
+# Iran, Volume 63, No. 18242, dated Tuesday 1386/6/24
 # [2007-10-16]. I am doing the best translation I can:...
 # The official time of the country will be moved forward for one hour
 # on the 24 hours of the first day of the month of Farvardin and will
@@ -1557,7 +1558,7 @@ Zone      Asia/Amman      2:23:44 -       LMT     1931
 # - Qyzylorda switched from +5:00 to +6:00 on 1992-01-19 02:00.
 # - Oral switched from +5:00 to +4:00 in spring 1989.
 
-# From Kazakhstan Embassy's News Bulletin #11
+# From Kazakhstan Embassy's News Bulletin No. 11
 # <http://www.kazsociety.org.uk/news/2005/03/30.htm> (2005-03-21):
 # The Government of Kazakhstan passed a resolution March 15 abolishing
 # daylight saving time citing lack of economic benefits and health
@@ -1711,6 +1712,17 @@ Rule     ROK     1987    1988    -       Oct     Sun>=8  3:00    0       S
 #
 # For Pyongyang we have no information; guess no changes since World War II.
 
+# From Steffen Thorsen (2015-08-07):
+# According to many news sources, North Korea is going to change to
+# the 8:30 time zone on August 15, one example:
+# http://www.bbc.com/news/world-asia-33815049
+#
+# From Paul Eggert (2015-08-07):
+# No transition time is specified; assume 00:00.
+# There is no common English-language abbreviation for this time zone.
+# Use %z rather than invent one.  We can't assume %z works everywhere yet,
+# so for now substitute its output manually.
+
 # Zone NAME            GMTOFF  RULES   FORMAT  [UNTIL]
 Zone   Asia/Seoul      8:27:52 -       LMT     1908 Apr  1
                        8:30    -       KST     1912 Jan  1
@@ -1723,7 +1735,8 @@ Zone      Asia/Pyongyang  8:23:00 -       LMT     1908 Apr  1
                        8:30    -       KST     1912 Jan  1
                        9:00    -       JCST    1937 Oct  1
                        9:00    -       JST     1945 Aug 24
-                       9:00    -       KST
+                       9:00    -       KST     2015 Aug 15
+                       8:30    -       KST
 
 ###############################################################################
 
index c64c41b..6b89b6e 100644 (file)
 #      republished in Finest Hour (Spring 2002) 1(114):26
 #      http://www.winstonchurchill.org/images/finesthour/Vol.01%20No.114.pdf
 
-# From Paul Eggert (1996-09-03):
+# From Paul Eggert (2015-08-08):
 # The OED Supplement says that the English originally said "Daylight Saving"
 # when they were debating the adoption of DST in 1908; but by 1916 this
 # term appears only in quotes taken from DST's opponents, whereas the
 # proponents (who eventually won the argument) are quoted as using "Summer".
+# The term "Summer Time" was introduced by Herbert Samuel, Home Secretary; see:
+# Viscount Samuel. Leisure in a Democracy. Cambridge University Press
+# ISBN 978-1-107-49471-8 (1949, reissued 2015), p 8.
 
 # From Arthur David Olson (1989-01-19):
 # A source at the British Information Office in New York avers that it's
 
 # From an anonymous contributor (1996-06-02):
 # The law governing time in Ireland is under Statutory Instrument SI 395/94,
-# which gives force to European Union 7th Council Directive # 94/21/EC.
+# which gives force to European Union 7th Council Directive No. 94/21/EC.
 # Under this directive, the Minister for Justice in Ireland makes appropriate
 # regulations. I spoke this morning with the Secretary of the Department of
 # Justice (tel +353 1 678 9711) who confirmed to me that the correct name is
@@ -592,11 +595,11 @@ Rule      Russia  1921    only    -       Feb     14      23:00   1:00    MSD
 Rule   Russia  1921    only    -       Mar     20      23:00   2:00    MSM  # Midsummer
 Rule   Russia  1921    only    -       Sep      1       0:00   1:00    MSD
 Rule   Russia  1921    only    -       Oct      1       0:00   0       -
-# Act No.925 of the Council of Ministers of the USSR (1980-10-24):
+# Act No. 925 of the Council of Ministers of the USSR (1980-10-24):
 Rule   Russia  1981    1984    -       Apr      1       0:00   1:00    S
 Rule   Russia  1981    1983    -       Oct      1       0:00   0       -
-# Act No.967 of the Council of Ministers of the USSR (1984-09-13), repeated in
-# Act No.227 of the Council of Ministers of the USSR (1989-03-14):
+# Act No. 967 of the Council of Ministers of the USSR (1984-09-13), repeated in
+# Act No. 227 of the Council of Ministers of the USSR (1989-03-14):
 Rule   Russia  1984    1991    -       Sep     lastSun  2:00s  0       -
 Rule   Russia  1985    1991    -       Mar     lastSun  2:00s  1:00    S
 #
@@ -828,7 +831,7 @@ Zone        Europe/Brussels 0:17:30 -       LMT     1880
 # Bulgaria
 #
 # From Plamen Simenov via Steffen Thorsen (1999-09-09):
-# A document of Government of Bulgaria (No.94/1997) says:
+# A document of Government of Bulgaria (No. 94/1997) says:
 # EET -> EETDST is in 03:00 Local time in last Sunday of March ...
 # EETDST -> EET is in 04:00 Local time in last Sunday of October
 #
@@ -845,7 +848,7 @@ Zone        Europe/Sofia    1:33:16 -       LMT     1880
                        1:00    C-Eur   CE%sT   1945
                        1:00    -       CET     1945 Apr  2  3:00
                        2:00    -       EET     1979 Mar 31 23:00
-                       2:00    Bulg    EE%sT   1982 Sep 26  2:00
+                       2:00    Bulg    EE%sT   1982 Sep 26  3:00
                        2:00    C-Eur   EE%sT   1991
                        2:00    E-Eur   EE%sT   1997
                        2:00    EU      EE%sT
@@ -1062,8 +1065,8 @@ Zone America/Thule        -4:35:08 -      LMT     1916 Jul 28 # Pituffik air base
 # after that.
 
 # From Mart Oruaas (2000-01-29):
-# Regulation no. 301 (1999-10-12) obsoletes previous regulation
-# no. 206 (1998-09-22) and thus sticks Estonia to +02:00 GMT for all
+# Regulation No. 301 (1999-10-12) obsoletes previous regulation
+# No. 206 (1998-09-22) and thus sticks Estonia to +02:00 GMT for all
 # the year round.  The regulation is effective 1999-11-01.
 
 # From Toomas Soome (2002-02-21):
@@ -1084,7 +1087,7 @@ Zone      Europe/Tallinn  1:39:00 -       LMT     1880
                        3:00    Russia  MSK/MSD 1989 Mar 26  2:00s
                        2:00    1:00    EEST    1989 Sep 24  2:00s
                        2:00    C-Eur   EE%sT   1998 Sep 22
-                       2:00    EU      EE%sT   1999 Nov  1
+                       2:00    EU      EE%sT   1999 Oct 31  4:00
                        2:00    -       EET     2002 Feb 21
                        2:00    EU      EE%sT
 
@@ -1527,21 +1530,21 @@ Link    Europe/Rome     Europe/San_Marino
 # correct data in juridical acts and I found some juridical documents about
 # changes in the counting of time in Latvia from 1981....
 #
-# Act No.35 of the Council of Ministers of Latvian SSR of 1981-01-22 ...
-# according to the Act No.925 of the Council of Ministers of USSR of 1980-10-24
+# Act No. 35 of the Council of Ministers of Latvian SSR of 1981-01-22 ...
+# according to the Act No. 925 of the Council of Ministers of USSR of 1980-10-24
 # ...: all year round the time of 2nd time zone + 1 hour, in addition turning
 # the hands of the clock 1 hour forward on 1 April at 00:00 (GMT 31 March 21:00)
 # and 1 hour backward on the 1 October at 00:00 (GMT 30 September 20:00).
 #
-# Act No.592 of the Council of Ministers of Latvian SSR of 1984-09-24 ...
-# according to the Act No.967 of the Council of Ministers of USSR of 1984-09-13
+# Act No. 592 of the Council of Ministers of Latvian SSR of 1984-09-24 ...
+# according to the Act No. 967 of the Council of Ministers of USSR of 1984-09-13
 # ...: all year round the time of 2nd time zone + 1 hour, in addition turning
 # the hands of the clock 1 hour forward on the last Sunday of March at 02:00
 # (GMT 23:00 on the previous day) and 1 hour backward on the last Sunday of
 # September at 03:00 (GMT 23:00 on the previous day).
 #
-# Act No.81 of the Council of Ministers of Latvian SSR of 1989-03-22 ...
-# according to the Act No.227 of the Council of Ministers of USSR of 1989-03-14
+# Act No. 81 of the Council of Ministers of Latvian SSR of 1989-03-22 ...
+# according to the Act No. 227 of the Council of Ministers of USSR of 1989-03-14
 # ...: since the last Sunday of March 1989 in Lithuanian SSR, Latvian SSR,
 # Estonian SSR and Kaliningrad region of Russian Federation all year round the
 # time of 2nd time zone (Moscow time minus one hour). On the territory of Latvia
@@ -1558,7 +1561,7 @@ Link      Europe/Rome     Europe/San_Marino
 # From Andrei Ivanov (2000-03-06):
 # This year Latvia will not switch to Daylight Savings Time (as specified in
 # The Regulations of the Cabinet of Ministers of the Rep. of Latvia of
-# 29-Feb-2000 (#79) <http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm>,
+# 29-Feb-2000 (No. 79) <http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm>,
 # in Latvian for subscribers only).
 
 # From RFE/RL Newsline
@@ -1763,6 +1766,18 @@ Zone     Europe/Malta    0:58:04 -       LMT     1893 Nov  2  0:00s # Valletta
 # News from Moldova (in russian):
 # http://ru.publika.md/link_317061.html
 
+# From Roman Tudos (2015-07-02):
+# http://lex.justice.md/index.php?action=view&view=doc&lang=1&id=355077
+# From Paul Eggert (2015-07-01):
+# The abovementioned official link to IGO1445-868/2014 states that
+# 2014-10-26's fallback transition occurred at 03:00 local time.  Also,
+# http://www.trm.md/en/social/la-30-martie-vom-trece-la-ora-de-vara
+# says the 2014-03-30 spring-forward transition was at 02:00 local time.
+# Guess that since 1997 Moldova has switched one hour before the EU.
+
+# Rule NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
+Rule   Moldova 1997    max     -       Mar     lastSun  2:00   1:00    S
+Rule   Moldova 1997    max     -       Oct     lastSun  3:00   0       -
 
 # Zone NAME            GMTOFF  RULES   FORMAT  [UNTIL]
 Zone   Europe/Chisinau 1:55:20 -       LMT     1880
@@ -1777,7 +1792,7 @@ Zone      Europe/Chisinau 1:55:20 -       LMT     1880
                        2:00    Russia  EE%sT   1992
                        2:00    E-Eur   EE%sT   1997
 # See Romania commentary for the guessed 1997 transition to EU rules.
-                       2:00    EU      EE%sT
+                       2:00    Moldova EE%sT
 
 # Monaco
 # Shanks & Pottenger give 0:09:20 for Paris Mean Time; go with Howse's
@@ -2123,7 +2138,7 @@ Zone Europe/Bucharest     1:44:24 -       LMT     1891 Oct
 # Russia
 
 # From Alexander Krivenyshev (2011-09-15):
-# Based on last Russian Government Decree # 725 on August 31, 2011
+# Based on last Russian Government Decree No. 725 on August 31, 2011
 # (Government document
 # http://www.government.ru/gov/results/16355/print/
 # in Russian)
@@ -2133,7 +2148,7 @@ Zone Europe/Bucharest     1:44:24 -       LMT     1891 Oct
 # http://www.worldtimezone.com/dst_news/dst_news_russia36.htm
 
 # From Sanjeev Gupta (2011-09-27):
-# Scans of [Decree #23 of January 8, 1992] are available at:
+# Scans of [Decree No. 23 of January 8, 1992] are available at:
 # http://government.consultant.ru/page.aspx?1223966
 # They are in Cyrillic letters (presumably Russian).
 
@@ -2144,19 +2159,19 @@ Zone Europe/Bucharest   1:44:24 -       LMT     1891 Oct
 # One source is
 # http://government.ru/gov/results/16355/
 # which, according to translate.google.com, begins "Decree of August 31,
-# 2011 No 725" and contains no other dates or "effective date" information.
+# 2011 No. 725" and contains no other dates or "effective date" information.
 #
 # Another source is
 # http://www.rg.ru/2011/09/06/chas-zona-dok.html
 # which, according to translate.google.com, begins "Resolution of the
 # Government of the Russian Federation on August 31, 2011 N 725" and also
 # contains "Date first official publication: September 6, 2011 Posted on:
-# in the 'RG' - Federal Issue number 5573 September 6, 2011" but which
+# in the 'RG' - Federal Issue No. 5573 September 6, 2011" but which
 # does not contain any "effective date" information.
 #
 # Another source is
 # http://en.wikipedia.org/wiki/Oymyakonsky_District#cite_note-RuTime-7
-# which, in note 8, contains "Resolution #725 of August 31, 2011...
+# which, in note 8, contains "Resolution No. 725 of August 31, 2011...
 # Effective as of after 7 days following the day of the official publication"
 # but which does not contain any reference to September 6, 2011.
 #
@@ -2364,7 +2379,7 @@ Zone Europe/Simferopol     2:16:24 -      LMT     1880
 # changed in May.
                         2:00   E-Eur   EE%sT   1994 May
 # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev.
-                        3:00   E-Eur   MSK/MSD 1996 Mar 31  3:00s
+                        3:00   E-Eur   MSK/MSD 1996 Mar 31  0:00s
                         3:00   1:00    MSD     1996 Oct 27  3:00s
 # IATA SSIM (1997-09) says Crimea switched to EET/EEST.
 # Assume it happened in March by not changing the clocks.
@@ -2499,7 +2514,7 @@ Zone Asia/Novosibirsk      5:31:40 -      LMT     1919 Dec 14  6:00
 # from current Russia Zone 6 - Krasnoyarsk Time Zone (KRA) UTC +0700
 # to Russia Zone 5 - Novosibirsk Time Zone (NOV) UTC +0600
 #
-# This is according to Government of Russia decree # 740, on September
+# This is according to Government of Russia decree No. 740, on September
 # 14, 2009 "Application in the territory of the Kemerovo region the Fifth
 # time zone." ("Russia Zone 5" or old "USSR Zone 5" is GMT +0600)
 #
@@ -2922,7 +2937,7 @@ Zone      Africa/Ceuta    -0:21:16 -      LMT     1901
 Zone   Atlantic/Canary -1:01:36 -      LMT     1922 Mar # Las Palmas de Gran C.
                        -1:00   -       CANT    1946 Sep 30  1:00 # Canaries T
                         0:00   -       WET     1980 Apr  6  0:00s
-                        0:00   1:00    WEST    1980 Sep 28  0:00s
+                        0:00   1:00    WEST    1980 Sep 28  1:00u
                         0:00   EU      WE%sT
 # IATA SSIM (1996-09) says the Canaries switch at 2:00u, not 1:00u.
 # Ignore this for now, as the Canaries are part of the EU.
@@ -3212,7 +3227,7 @@ Link      Europe/Istanbul Asia/Istanbul   # Istanbul is in both continents.
 # From Igor Karpov, who works for the Ukrainian Ministry of Justice,
 # via Garrett Wollman (2003-01-27):
 # BTW, I've found the official document on this matter. It's government
-# regulations number 509, May 13, 1996. In my poor translation it says:
+# regulations No. 509, May 13, 1996. In my poor translation it says:
 # "Time in Ukraine is set to second timezone (Kiev time). Each last Sunday
 # of March at 3am the time is changing to 4am and each last Sunday of
 # October the time at 4am is changing to 3am"
@@ -3221,7 +3236,7 @@ Link      Europe/Istanbul Asia/Istanbul   # Istanbul is in both continents.
 # On September 20, 2011 the deputies of the Verkhovna Rada agreed to
 # abolish the transfer clock to winter time.
 #
-# Bill number 8330 of MP from the Party of Regions Oleg Nadoshi got
+# Bill No. 8330 of MP from the Party of Regions Oleg Nadoshi got
 # approval from 266 deputies.
 #
 # Ukraine abolishes transfer back to the winter time (in Russian)
index 5c39e62..70ec6d1 100644 (file)
@@ -56,5 +56,5 @@ Leap  2008    Dec     31      23:59:60        +       S
 Leap   2012    Jun     30      23:59:60        +       S
 Leap   2015    Jun     30      23:59:60        +       S
 
-#      Updated through IERS Bulletin C49
-#      File expires on:  28 December 2015
+#      Updated through IERS Bulletin C50
+#      File expires on:  28 June 2016
index 88423e6..660a920 100644 (file)
@@ -1235,10 +1235,19 @@ Zone America/Goose_Bay  -4:01:40 -      LMT     1884 # Happy Valley-Goose Bay
 
 # west Labrador, Nova Scotia, Prince Edward I
 
-# From Paul Eggert (2006-03-22):
+# From Brian Inglis (2015-07-20):
+# From the historical weather station records available at:
+# https://weatherspark.com/history/28351/1971/Sydney-Nova-Scotia-Canada
+# Sydney shares the same time history as Glace Bay, so was
+# likely to be the same across the island....
+# Sydney, as the capital and most populous location, or Cape Breton, would
+# have been better names for the zone had we known this in 1996.
+
+# From Paul Eggert (2015-07-20):
 # Shanks & Pottenger write that since 1970 most of this region has been like
 # Halifax.  Many locales did not observe peacetime DST until 1972;
-# Glace Bay, NS is the largest that we know of.
+# the Cape Breton area, represented by Glace Bay, is the largest we know of
+# (Glace Bay was perhaps not the best name choice but no point changing now).
 # Shanks & Pottenger also write that Liverpool, NS was the only town
 # in Canada to observe DST in 1971 but not 1970; for now we'll assume
 # this is a typo.
@@ -1796,13 +1805,13 @@ Zone America/Edmonton   -7:33:52 -      LMT     1906 Sep
 # Exact date in October unknown; Sunday October 1 is a reasonable guess.
 # 3. June 1918: switch to Pacific Daylight Time (GMT-7)
 # Exact date in June unknown; Sunday June 2 is a reasonable guess.
-# note#1:
+# note 1:
 # On Oct 27/1918 when daylight saving ended in the rest of Canada,
 # Creston did not change its clocks.
-# note#2:
+# note 2:
 # During WWII when the Federal Government legislated a mandatory clock change,
 # Creston did not oblige.
-# note#3:
+# note 3:
 # There is no guarantee that Creston will remain on Mountain Standard Time
 # (UTC-7) forever.
 # The subject was debated at least once this year by the town Council.
index 6bbc2c8..50d118e 100644 (file)
@@ -131,7 +131,7 @@ Rule        Arg     2000    only    -       Mar     3       0:00    0       -
 # Timezone Law (which never was effectively applied) will (would?) be
 # in effect.... The article is at
 # http://ar.clarin.com/diario/2001-06-06/e-01701.htm
-# ... The Law itself is "Ley No 25155", sanctioned on 1999-08-25, enacted
+# ... The Law itself is "Ley No. 25155", sanctioned on 1999-08-25, enacted
 # 1999-09-17, and published 1999-09-21.  The official publication is at:
 # http://www.boletin.jus.gov.ar/BON/Primera/1999/09-Septiembre/21/PDF/BO21-09-99LEG.PDF
 # Regretfully, you have to subscribe (and pay) for the on-line version....
@@ -175,15 +175,11 @@ Rule      Arg     2000    only    -       Mar     3       0:00    0       -
 # http://www.worldtimezone.com/dst_news/dst_news_argentina03.html
 # http://www.impulsobaires.com.ar/nota.php?id=57832 (in spanish)
 
-# From Rodrigo Severo (2008-10-06):
-# Here is some info available at a Gentoo bug related to TZ on Argentina's DST:
-# ...
-# ------- Comment #1 from [jmdocile]  2008-10-06 16:28 0000 -------
-# Hi, there is a problem with timezone-data-2008e and maybe with
-# timezone-data-2008f
-# Argentinian law [Number] 25.155 is no longer valid.
+# From Juan Manuel Docile in https://bugs.gentoo.org/240339 (2008-10-07)
+# via Rodrigo Severo:
+# Argentinian law No. 25.155 is no longer valid.
 # http://www.infoleg.gov.ar/infolegInternet/anexos/60000-64999/60036/norma.htm
-# The new one is law [Number] 26.350
+# The new one is law No. 26.350
 # http://www.infoleg.gov.ar/infolegInternet/anexos/135000-139999/136191/norma.htm
 # So there is no summer time in Argentina for now.
 
@@ -771,7 +767,7 @@ Zone        America/La_Paz  -4:32:36 -      LMT     1890
 #       [ and in a second message (same day): ]
 # I found the decree.
 #
-# DECRETO No- 7.584, DE 13 DE OUTUBRO DE 2011
+# DECRETO No. 7.584, DE 13 DE OUTUBRO DE 2011
 # Link :
 # http://www.in.gov.br/visualiza/index.jsp?data=13/10/2011&jornal=1000&pagina=6&totalArquivos=6
 
@@ -1125,7 +1121,7 @@ Zone America/Rio_Branco   -4:31:12 -      LMT     1914
 # Conflicts between [1] and [2] were resolved as follows:
 #
 #  - [1] says the 1910 transition was Jan 1, [2] says Jan 10 and cites
-#    Boletín Nº 1, Aviso Nº 1 (1910).  Go with [2].
+#    Boletín No. 1, Aviso No. 1 (1910).  Go with [2].
 #
 #  - [1] says SMT was -4:42:45, [2] says Chile's official time from
 #    1916 to 1919 was -4:42:46.3, the meridian of Chile's National
@@ -1133,7 +1129,7 @@ Zone America/Rio_Branco   -4:31:12 -      LMT     1914
 #    Quinta Normal in Santiago.  Go with [2], rounding it to -4:42:46.
 #
 #  - [1] says the 1918 transition was Sep 1, [2] says Sep 10 and cites
-#    Boletín Nº 22, Aviso Nº 129/1918 (1918-08-23).  Go with [2].
+#    Boletín No. 22, Aviso No. 129/1918 (1918-08-23).  Go with [2].
 #
 #  - [1] does not give times for transitions; assume they occur
 #    at midnight mainland time, the current common practice.  However,
@@ -1533,7 +1529,7 @@ Rule      Para    1997    only    -       Feb     lastSun 0:00    0       -
 # (1999-09) reports no date; go with above sources and Gerd Knops (2001-02-27).
 Rule   Para    1998    2001    -       Mar     Sun>=1  0:00    0       -
 # From Rives McDow (2002-02-28):
-# A decree was issued in Paraguay (no. 16350) on 2002-02-26 that changed the
+# A decree was issued in Paraguay (No. 16350) on 2002-02-26 that changed the
 # dst method to be from the first Sunday in September to the first Sunday in
 # April.
 Rule   Para    2002    2004    -       Apr     Sun>=1  0:00    0       -
@@ -1713,8 +1709,19 @@ Rule     Uruguay 2005    only    -       Oct      9       2:00   1:00    S
 Rule   Uruguay 2006    only    -       Mar     12       2:00   0       -
 # From Jesper Nørgaard Welen (2006-09-06):
 # http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006_00001.PDF
-Rule   Uruguay 2006    max     -       Oct     Sun>=1   2:00   1:00    S
-Rule   Uruguay 2007    max     -       Mar     Sun>=8   2:00   0       -
+#
+# From Steffen Thorsen (2015-06-30):
+# ... it looks like they will not be using DST the coming summer:
+# http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horario-verano-n656787
+# http://www.republica.com.uy/este-ano-no-se-modificara-el-huso-horario-en-uruguay/523760/
+# From Paul Eggert (2015-06-30):
+# Apparently restaurateurs complained that DST caused people to go to the beach
+# instead of out to dinner.
+# From Pablo Camargo (2015-07-13):
+# http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf
+# [dated 2015-06-29; repeals Decree 311/006 dated 2006-09-04]
+Rule   Uruguay 2006    2014    -       Oct     Sun>=1   2:00   1:00    S
+Rule   Uruguay 2007    2015    -       Mar     Sun>=8   2:00   0       -
 # Zone NAME            GMTOFF  RULES   FORMAT  [UNTIL]
 Zone America/Montevideo        -3:44:44 -      LMT     1898 Jun 28
                        -3:44:44 -      MMT     1920 May  1 # Montevideo MT
@@ -1723,6 +1730,10 @@ Zone America/Montevideo  -3:44:44 -      LMT     1898 Jun 28
 
 # Venezuela
 #
+# From Paul Eggert (2015-07-28):
+# For the 1965 transition see Gaceta Oficial No. 27.619 (1964-12-15), p 205.533
+# http://www.pgr.gob.ve/dmdocuments/1964/27619.pdf
+#
 # From John Stainforth (2007-11-28):
 # ... the change for Venezuela originally expected for 2007-12-31 has
 # been brought forward to 2007-12-09.  The official announcement was
@@ -1734,6 +1745,6 @@ Zone America/Montevideo   -3:44:44 -      LMT     1898 Jun 28
 # Zone NAME            GMTOFF  RULES   FORMAT  [UNTIL]
 Zone   America/Caracas -4:27:44 -      LMT     1890
                        -4:27:40 -      CMT     1912 Feb 12 # Caracas Mean Time?
-                       -4:30   -       VET     1965        # Venezuela Time
+                       -4:30   -       VET     1965 Jan  1  0:00 # Venezuela T.
                        -4:00   -       VET     2007 Dec  9  3:00
                        -4:30   -       VET
index f418e7f..381f245 100644 (file)
@@ -106,8 +106,8 @@ BW  -2439+02555     Africa/Gaborone
 BY     +5354+02734     Europe/Minsk
 BZ     +1730-08812     America/Belize
 CA     +4734-05243     America/St_Johns        Newfoundland Time, including SE Labrador
-CA     +4439-06336     America/Halifax Atlantic Time - Nova Scotia (most places), PEI
-CA     +4612-05957     America/Glace_Bay       Atlantic Time - Nova Scotia - places that did not observe DST 1966-1971
+CA     +4439-06336     America/Halifax Atlantic Time - Nova Scotia (peninsula), PEI
+CA     +4612-05957     America/Glace_Bay       Atlantic Time - Nova Scotia (Cape Breton)
 CA     +4606-06447     America/Moncton Atlantic Time - New Brunswick
 CA     +5320-06025     America/Goose_Bay       Atlantic Time - Labrador - most locations
 CA     +5125-05707     America/Blanc-Sablon    Atlantic Standard Time - Quebec - Lower North Shore