Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/external/public-domain/tz/dist Merge tzdata2017c
details: https://anonhg.NetBSD.org/src/rev/715507d6bbb0
branches: trunk
changeset: 827337:715507d6bbb0
user: kre <kre%NetBSD.org@localhost>
date: Tue Oct 24 01:28:18 2017 +0000
description:
Merge tzdata2017c
diffstat:
external/public-domain/tz/dist/TZDATA_VERSION | 2 +-
external/public-domain/tz/dist/Theory | 870 --------------------------
2 files changed, 1 insertions(+), 871 deletions(-)
diffs (truncated from 880 to 300 lines):
diff -r 4c533773b6b1 -r 715507d6bbb0 external/public-domain/tz/dist/TZDATA_VERSION
--- a/external/public-domain/tz/dist/TZDATA_VERSION Tue Oct 24 01:25:55 2017 +0000
+++ b/external/public-domain/tz/dist/TZDATA_VERSION Tue Oct 24 01:28:18 2017 +0000
@@ -1,1 +1,1 @@
-tzdata-2017b
+tzdata-2017c
diff -r 4c533773b6b1 -r 715507d6bbb0 external/public-domain/tz/dist/Theory
--- a/external/public-domain/tz/dist/Theory Tue Oct 24 01:25:55 2017 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,870 +0,0 @@
-Theory and pragmatics of the tz code and data
-
-
------ Outline -----
-
- Scope of the tz database
- Names of time zone rules
- Time zone abbreviations
- Accuracy of the tz database
- Time and date functions
- Interface stability
- Calendrical issues
- Time and time zones on Mars
-
-
------ 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-2008, 2016 Edition
- <http://pubs.opengroup.org/onlinepubs/9699919799/>
-
-
-
------ Names of time zone rules -----
-
-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.
-
-The time zone rule naming conventions attempt to strike a balance
-among the following goals:
-
- * Uniquely identify every region where clocks have agreed since 1970.
- This is essential for the intended use: static clocks keeping local
- civil time.
-
- * Indicate to experts where that region is.
-
- * 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).
-
- * Be portable to a wide variety of implementations.
-
- * Use a consistent naming conventions over the entire world.
-
-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 '/'). 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 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.
-
-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').
-
-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'.
-
-Excluding 'backward' should not affect the other data. If
-'backward' is excluded, excluding 'etcetera' should not affect the
-remaining data.
-
-
------ Time zone abbreviations -----
-
-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:
-
- Use three or more characters that are ASCII alphanumerics or '+' or '-'.
- 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 lower-case letters are now allowed.
- Also, POSIX from 2001 on relaxed the rule to allow '-', '+',
- and alphanumeric characters from the portable character set
- in the current locale. In practice ASCII alphanumerics and
- '+' and '-' are safe in all locales.
-
- In other words, in the C locale the POSIX extended regular
- expression [-+[:alnum:]]{3,} should match the abbreviation.
- This guarantees that all abbreviations could have been
- specified by a POSIX TZ string.
-
- 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'.
-
- Use 'LMT' for local mean time of locations before the introduction
- of standard time; see "Scope of the tz database".
-
- If there is no common English abbreviation, use numeric offsets like
- -05 and +0830 that are generated by zic's %z notation.
-
- Use current abbreviations for older timestamps to avoid confusion.
- For example, in 1910 a common English abbreviation for UT +01
- in central Europe was 'MEZ' (short for both "Middle European
- Zone" and for "Mitteleuropäische Zeit" in German). Nowadays
- 'CET' ("Central European Time") is more common in English, and
- the database uses 'CET' even for circa-1910 timestamps as this
- is less confusing for modern users and avoids the need for
- determining when 'CET' supplanted 'MEZ' in common usage.
-
- Use a consistent style in a zone's history. For example, if a zone's
- history tends to use numeric abbreviations and a particular
- entry could go either way, use a numeric abbreviation.
-
- [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:
-
- 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. 'CHAST' for CHAtham Summer Time.
-
- Use UT (with time zone abbreviation '-00') for locations while
- uninhabited. The leading '-' is a flag that the time
- zone is in some sense undefined; this notation is
- derived from Internet RFC 3339.
-
-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 -----
-
-The tz database is not authoritative, and it surely has errors.
-Corrections are welcome and encouraged; see the file CONTRIBUTING.
-Users requiring authoritative data should consult national standards
-bodies and the references cited in the database's comments.
-
-Errors in the tz database arise from many sources:
-
- * The tz database predicts future time stamps, and current predictions
- will be incorrect after future governments change the rules.
- For example, if today someone schedules a meeting for 13:00 next
- October 1, Casablanca time, and tomorrow Morocco changes its
- daylight saving rules, software can mess up after the rule change
- if it blithely relies on conversions made before the change.
-
- * The pre-1970 entries in this database cover only a tiny sliver of how
- clocks actually behaved; the vast majority of the necessary
- information was lost or never recorded. Thousands more zones would
- be needed if the tz database's scope were extended to cover even
- just the known or guessed history of standard time; for example,
- the current single entry for France would need to split into dozens
- of entries, perhaps hundreds. And in most of the world even this
- approach would be misleading due to widespread disagreement or
- indifference about what times should be observed. In her 2015 book
- "The Global Transformation of Time, 1870-1950", Vanessa Ogle writes
- "Outside of Europe and North America there was no system of time
- zones at all, often not even a stable landscape of mean times,
- prior to the middle decades of the twentieth century". See:
- Timothy Shenk, Booked: A Global History of Time. Dissent 2015-12-17
- https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle
-
- * Most of the pre-1970 data entries come from unreliable sources, often
- astrology books that lack citations and whose compilers evidently
- invented entries when the true facts were unknown, without
Home |
Main Index |
Thread Index |
Old Index