tz code and datatz 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 timestamps 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.
++The tz
++database attempts to record the history and predicted future of
++all computer-based clocks that track civil time.
++It organizes time zone and daylight saving time
++data by partitioning the world into regions
++whose clocks all agree about timestamps that occur after the of the POSIX Epoch
++(1970-01-01 00:00:00 UTC).
++The database labels each such region with a notable location and
++records all known clock transitions for that 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.
+
+@@ -59,193 +60,218 @@ +
+ +
+-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.
++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.
++Because the database's scope encompasses real-world changes to civil
++timekeeping, its model for describing time is more complex than the
++standard and daylight saving times supported by POSIX.
++A tz region corresponds to a ruleset that can
++have more than two changes per year, these changes need not merely
++flip back and forth between two alternatives, and the rules themselves
++can change at times.
++Whether and when a tz region changes its
++clock, and even the region's notional base offset from UTC, are variable.
++It doesn't even really make sense to talk about a region's
++"base offset", since it is not necessarily a single number.
+
+-Each of the database's time zone rules has a unique name.
++Each tz region has a unique name that
++corresponds to a set of time zone rules.
+ 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 contains data that may be useful for other
+-selection interfaces.
++program in the tz code.
++The Unicode Common Locale Data
++Repository contains data that may be useful for other selection
++interfaces.
+
+-The time zone rule naming conventions attempt to strike a balance ++The naming conventions attempt to strike a balance + among the following goals: +
++ +
+-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'.
++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,
++Here are the general guidelines used for
++choosing tz region names,
+ in decreasing order of importance:
+
/'). 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.
++ 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.
+ //', or
+- start or end with '/'.
++ A name must not be empty, or contain '//', or
++ start or end 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'.
++ 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'.
+ Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.
++ 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'.
+ Paris' to 'France', since
+- France has had multiple time zones.
++ Keep locations compact.
++ Use cities or small islands, not countries or regions, so that any
++ future changes do not split individual locations into different
++ tz regions.
++ E.g., prefer 'Paris' to 'France', since
++ France
++ has had multiple time zones.
+ Rome' to 'Roma', and prefer
+- 'Athens' to the Greek
+- 'Αθήνα' or the Romanized
+- 'Athína'.
+- The POSIX file name restrictions encourage this rule.
++ 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 guideline.
+ Shanghai' to
+- 'Beijing'. Among locations with
+- similar populations, pick the best-known location,
+- e.g. prefer 'Rome' to 'Milan'.
++ Use the most populous among locations in a region,
++ e.g., prefer 'Shanghai' to
++ 'Beijing'.
++ Among locations with similar populations, pick the best-known
++ location, e.g., prefer 'Rome' to
++ 'Milan'.
+ Canary' to 'Canaries'.
++ Use the singular form, e.g., prefer 'Canary' to
++ 'Canaries'.
+ _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.
++ 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.
+ _' to represent a space.
++ Use '_' to represent a space.
+ .' from abbreviations in names, e.g. prefer
+- 'St_Helena' to 'St._Helena'.
++ Omit '.' from abbreviations in names.
++ E.g., prefer 'St_Helena' to 'St._Helena'.
+ Rome' to
+- 'Milan' merely because
+- Milan's population has grown to be somewhat greater
+- than Rome's.
++ Do not change established names if they only marginally violate
++ the above guidelines.
++ 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.
+ backward' file.
+- This means old spellings will continue to work.
++ 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° east
+-longitude, this relationship is not exact.
++to name tz regions.
++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 local mean
++time (LMT) offset with one hour for every 15°
++east longitude, this relationship is not exact.
+
+@@ -254,202 +280,233 @@
+ 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').
++'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' and 'GMT+0', and the file 'northamerica' defines the
+-legacy names 'EST5EDT', 'CST6CDT', 'MST7MDT', and 'PST8PDT'.
++incompatible with the first guideline 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' and 'GMT+0',
++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.
++Excluding 'backward' should not affect the other data.
++If 'backward' is excluded, excluding
++'etcetera' should not affect the remaining data.
+
+ 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,
++Here are the general guidelines used for choosing time zone abbreviations,
+ in decreasing order of importance:
++
+' 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.
++ Use three to six 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 guideline 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,6} should match
+- the abbreviation.
+- This guarantees that all abbreviations could have been
+- specified by a POSIX TZ string.
++
++ In other words, in the C locale the POSIX extended regular
++ expression [-+[:alnum:]]{3,6} should match the
++ abbreviation.
++ This guarantees that all abbreviations could have been specified by a
++ POSIX TZ string.
++
These abbreviations (for standard/daylight/etc. time) are: +-ACST/ACDT Australian Central, +-AST/ADT/APT/AWT/ADDT Atlantic, +-AEST/AEDT Australian Eastern, +-AHST/AHDT Alaska-Hawaii, +-AKST/AKDT Alaska, +-AWST/AWDT Australian Western, +-BST/BDT Bering, +-CAT/CAST Central Africa, +-CET/CEST/CEMT Central European, +-ChST Chamorro, +-CST/CDT/CWT/CPT/CDDT Central [North America], +-CST/CDT China, +-GMT/BST/IST/BDST Greenwich, +-EAT East Africa, +-EST/EDT/EWT/EPT/EDDT Eastern [North America], +-EET/EEST Eastern European, +-GST Guam, +-HST/HDT Hawaii, +-HKT/HKST Hong Kong, +-IST India, +-IST/GMT Irish, +-IST/IDT/IDDT Israel, +-JST/JDT Japan, +-KST/KDT Korea, +-MET/MEST Middle European (a backward-compatibility alias for Central European), +-MSK/MSD Moscow, +-MST/MDT/MWT/MPT/MDDT Mountain, +-NST/NDT/NWT/NPT/NDDT Newfoundland, +-NST/NDT/NWT/NPT Nome, +-NZMT/NZST New Zealand through 1945, +-NZST/NZDT New Zealand 1946–present, +-PKT/PKST Pakistan, +-PST/PDT/PWT/PPT/PDDT Pacific, +-SAST South Africa, +-SST Samoa, +-WAT/WAST West Africa, +-WET/WEST/WEMT Western European, +-WIB Waktu Indonesia Barat, +-WIT Waktu Indonesia Timur, +-WITA Waktu Indonesia Tengah, +-YST/YDT/YWT/YPT/YDDT Yukon.
++++ These abbreviations (for standard/daylight/etc. time) are: ++ ACST/ACDT Australian Central, ++ AST/ADT/APT/AWT/ADDT Atlantic, ++ AEST/AEDT Australian Eastern, ++ AHST/AHDT Alaska-Hawaii, ++ AKST/AKDT Alaska, ++ AWST/AWDT Australian Western, ++ BST/BDT Bering, ++ CAT/CAST Central Africa, ++ CET/CEST/CEMT Central European, ++ ChST Chamorro, ++ CST/CDT/CWT/CPT/CDDT Central [North America], ++ CST/CDT China, ++ GMT/BST/IST/BDST Greenwich, ++ EAT East Africa, ++ EST/EDT/EWT/EPT/EDDT Eastern [North America], ++ EET/EEST Eastern European, ++ GST Guam, ++ HST/HDT Hawaii, ++ HKT/HKST Hong Kong, ++ IST India, ++ IST/GMT Irish, ++ IST/IDT/IDDT Israel, ++ JST/JDT Japan, ++ KST/KDT Korea, ++ MET/MEST Middle European (a backward-compatibility alias for ++ Central European), ++ MSK/MSD Moscow, ++ MST/MDT/MWT/MPT/MDDT Mountain, ++ NST/NDT/NWT/NPT/NDDT Newfoundland, ++ NST/NDT/NWT/NPT Nome, ++ NZMT/NZST New Zealand through 1945, ++ NZST/NZDT New Zealand 1946–present, ++ PKT/PKST Pakistan, ++ PST/PDT/PWT/PPT/PDDT Pacific, ++ SAST South Africa, ++ SST Samoa, ++ WAT/WAST West Africa, ++ WET/WEST/WEMT Western European, ++ WIB Waktu Indonesia Barat, ++ WIT Waktu Indonesia Timur, ++ WITA Waktu Indonesia Tengah, ++ YST/YDT/YWT/YPT/YDDT Yukon. ++
+-004430' for MMT) would
+-cause trouble here, as the numeric strings would exceed the POSIX length limit.
++
++ For times taken from a city's longitude, use the
++ traditional xMT notation.
++ The only abbreviation like this in current use is 'GMT'.
++ The others are for timestamps before 1960,
++ except that Monrovia Mean Time persisted until 1972.
++ Typically, numeric abbreviations (e.g., '-004430' for
++ MMT) would cause trouble here, as the numeric strings would exceed
++ the POSIX length limit.
++
These abbreviations are: +-AMT Amsterdam, Asunción, Athens; +-BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels, Bucharest; +-CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba; +-DMT Dublin/Dunsink; +-EMT Easter; +-FFMT Fort-de-France; +-FMT Funchal; +-GMT Greenwich; +-HMT Havana, Helsinki, Horta, Howrah; +-IMT Irkutsk, Istanbul; +-JMT Jerusalem; +-KMT Kaunas, Kiev, Kingston; +-LMT Lima, Lisbon, local, Luanda; +-MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, +- Moscow; +-PLMT Phù Liễn; +-PMT Paramaribo, Paris, Perm, Pontianak, Prague; +-PMMT Port Moresby; +-QMT Quito; +-RMT Rangoon, Riga, Rome; +-SDMT Santo Domingo; +-SJMT San José; +-SMT Santiago, Simferopol, Singapore, Stanley; +-TBMT Tbilisi; +-TMT Tallinn, Tehran; +-WMT Warsaw.
++++ These abbreviations are: ++ AMT Amsterdam, Asunción, Athens; ++ BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels, ++ Bucharest; ++ CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba; ++ DMT Dublin/Dunsink; ++ EMT Easter; ++ FFMT Fort-de-France; ++ FMT Funchal; ++ GMT Greenwich; ++ HMT Havana, Helsinki, Horta, Howrah; ++ IMT Irkutsk, Istanbul; ++ JMT Jerusalem; ++ KMT Kaunas, Kiev, Kingston; ++ LMT Lima, Lisbon, local, Luanda; ++ MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, ++ Moratuwa, Moscow; ++ PLMT Phù Liễn; ++ PMT Paramaribo, Paris, Perm, Pontianak, Prague; ++ PMMT Port Moresby; ++ QMT Quito; ++ RMT Rangoon, Riga, Rome; ++ SDMT Santo Domingo; ++ SJMT San José; ++ SMT Santiago, Simferopol, Singapore, Stanley; ++ TBMT Tbilisi; ++ TMT Tallinn, Tehran; ++ WMT Warsaw. ++
+ +-A few abbreviations also follow the pattern that +-GMT/BST established for time in the UK. They are: +- +-CMT/BST for Calamarca Mean Time and Bolivian Summer Time +-1890–1932, DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time +-1880–1916, MMT/MST/MDST for Moscow 1880–1919, and RMT/LST +-for Riga Mean Time and Latvian Summer time 1880–1926. +-An extra-special case is SET for Swedish Time (svensk +-normaltid) 1879–1899, 3° west of the Stockholm +-Observatory.
++++ A few abbreviations also follow the pattern that ++ GMT/BST established for time in the UK. ++ They are: ++ CMT/BST for Calamarca Mean Time and Bolivian Summer Time ++ 1890–1932, ++ DMT/IST for Dublin/Dunsink Mean Time and Irish Summer Time ++ 1880–1916, ++ MMT/MST/MDST for Moscow 1880–1919, and ++ RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926. ++ An extra-special case is SET for Swedish Time (svensk ++ normaltid) 1879–1899, 3° west of the Stockholm ++ Observatory. ++
+tz database".
+ -05 and +0830 that are
+- generated by zic's %z notation.
++ If there is no common English abbreviation, use numeric offsets like
++ -05 and +0830 that are generated
++ by zic's %z notation.
+ tz region's history.
++ For example, if history tends to use numeric
++ abbreviations and a particular entry could go either way, use a
++ numeric 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.
++ Use
++ Universal Time
++ (UT) (with time zone abbreviation '-00') for
++ locations while uninhabited.
++ The leading '-' is a flag that the UT offset 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' means one thing in China and something else
+ in North America, and 'IST' can refer to time in India, Ireland or
+-Israel. To avoid ambiguity, use numeric UT offsets like
++Israel.
++To avoid ambiguity, use numeric UT offsets like
+ '-0600' instead of time zone abbreviations like 'CST'.
+
tz database
+-The tz database is not authoritative, and it surely has errors.
++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.
+@@ -456,641 +513,775 @@
+
+-Errors in the tz database arise from many sources:
++Errors in the tz database arise from many sources:
+
tz database predicts future
++ timestamps, 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.
+ tz regions 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.
+ tz database relies on
++ years of first-class work done by
++ Joseph Myers and others; see
++ "History of
++ legal time in Britain".
++ Other countries are not done nearly as well.
+ Europe/London
+- stands for the United Kingdom, but its pre-1847 times are valid
+- only for locations that have London's exact meridian, and its 1847
+- transition to GMT is known to be valid only for the L&NW and the
+- Caledonian railways.
++ Although a named location in the tz
++ database stands for the containing region, its pre-1970 data
++ entries are often accurate for only a small subset of that region.
++ For example, Europe/London stands for the United
++ Kingdom, but its pre-1847 times are valid only for locations that
++ have London's exact meridian, and its 1847 transition
++ to GMT is known to be valid only for the L&NW and
++ the Caledonian railways.
+ Europe/London is valid for all locations in its
+- region after GMT was made the standard time, but the date of
+- standardization (1880-08-02) is not in the tz database, other than
+- in commentary. For many zones the earliest time of validity is
+- unknown.
++ The tz database does not record the
++ earliest time for which a tz region's
++ data entries are thereafter valid for every location in the region.
++ For example, Europe/London is valid for all locations
++ in its region after GMT was made the standard time,
++ but the date of standardization (1880-08-02) is not in the
++ tz database, other than in commentary.
++ For many tz regions the earliest time of
++ validity is unknown.
+ America/Kentucky/Louisville represents a region around
+- the city of
+- Louisville, the boundaries of which are unclear.
++ The tz database does not record a
++ region's boundaries, and in many cases the boundaries are not known.
++ For example, the tz region
++ America/Kentucky/Louisville represents a region
++ around the city of Louisville, the boundaries of which are
++ unclear.
+ tz
++ database were often spread out over hours, days, or even decades.
+ tz database requires.
+ tz code can handle.
++ For example, from 1909 to 1937 Netherlands clocks were legally Amsterdam Mean
++ Time (estimated to be UT
++ +00:19:32.13), but the tz
++ code cannot represent the fractional second.
++ In practice these old specifications were rarely if ever
++ implemented to subsecond precision.
+ tz database are correct, the
++ tz rules that generate them may not
++ faithfully reflect the historical rules.
++ For example, from 1922 until World War II the UK moved clocks
++ forward the day following the third Saturday in April unless that
++ was Easter, in which case it moved clocks forward the previous
++ Sunday.
++ Because the tz database has no
++ way to specify Easter, these exceptional years are entered as
++ separate tz Rule lines, even though the
++ legal rules did not change.
+ tz database models pre-standard time
++ using the proleptic
++ Gregorian calendar and local mean time, but many people used
++ other calendars and other timescales.
++ For example, the Roman Empire used
++ the Julian
++ calendar,
++ and Roman
++ timekeeping had twelve varying-length daytime hours with a
++ non-hour-based system at night.
+ tz database assumes Universal Time
++ (UT) as an origin, even though UT is not
++ standardized for older timestamps.
++ In the tz database commentary,
++ UT denotes a family of time standards that includes
++ Coordinated Universal Time (UTC) along with other
++ variants such as UT1 and GMT,
++ with days starting at midnight.
++ Although UT equals UTC for modern
++ timestamps, UTC was not defined until 1960, so
++ commentary uses the more-general abbreviation UT for
++ timestamps that might predate 1960.
++ Since UT, UT1, etc. disagree slightly,
++ and since pre-1972 UTC seconds varied in length,
++ interpretation of older timestamps can be problematic when
++ subsecond accuracy is needed.
+ tz database does not represent how
++ uncertain its information is.
++ Ideally it would contain information about when data entries are
++ incomplete or dicey.
++ Partial temporal knowledge is a field of active research, though,
++ and it's not clear how to apply it here.
+
+-In short, many, perhaps most, of the tz database's pre-1970 and future
+-timestamps are either wrong or misleading. Any attempt to pass the
+-tz database off as the definition of time should be unacceptable to
+-anybody who cares about the facts. In particular, the tz database's
+-LMT offsets should not be considered meaningful, and should not prompt
+-creation of zones merely because two locations differ in LMT or
+-transitioned to standard time at different dates.
++In short, many, perhaps most, of the tz
++database's pre-1970 and future timestamps are either wrong or
++misleading.
++Any attempt to pass the
++tz database off as the definition of time
++should be unacceptable to anybody who cares about the facts.
++In particular, the tz database's
++LMT offsets should not be considered meaningful, and
++should not prompt creation of tz regions
++merely because two locations
++differ in LMT or transitioned to standard time at
++different dates.
+
+-The tz code contains time and date functions that are upwards
+-compatible with those of POSIX.
++The tz code contains time and date functions
++that are upwards compatible with those of POSIX.
++Code compatible with this package is already
++part of many platforms, where the
++primary use of this package is to update obsolete time-related files.
++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 is occasionally extended, and a platform may still be shipping
++an older zic.
+
+-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.
++ 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 daylight
++ saving time rules not based on the Gregorian calendar (as in
++ Iran), or with situations where more than two time zone
++ abbreviations or UT offsets are used in an area.
+
+- The POSIX TZ string takes the following form:
++ The POSIX TZ string takes the following form:
+
+- stdoffset[dst[offset][,date[/time],date[/time]]]
++ stdoffset[dst[offset][,date[/time],date[/time]]]
+
+- where: ++ where: ++
++ +<+09>'; this allows
+- "+" and "-" in the names.
++ 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 '<+09>';
++ this allows "+" and "-" in the names.
+ [±]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.
++ 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.
+ /time],date[/time]:[mm[:ss]]'
+- and defaults to 02:00.
+- This is the same format as the offset, except that a
+- leading '+' or '-' is not allowed.
++ 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.
+ Mm.n.d (0[Sunday]≤d≤6[Saturday], 1≤n≤5, 1≤m≤12)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.
++ origin-0 day number counting February 29 if present
+ Mm.n.d
++ (0[Sunday]≤d≤6[Saturday], 1≤n≤5,
++ 1≤m≤12)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.
++ TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'
++ Here is an example POSIX TZ string for New
++ Zealand after 2007.
++ It says that standard time (NZST) is 12 hours ahead
++ of UT, and that daylight saving time
++ (NZDT) is observed from September's last Sunday at
++ 02:00 until April's first Sunday at 03:00:
++
TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'TZ='Pacific/Auckland'
++ This POSIX TZ string is hard to remember, and
++ mishandles some timestamps before 2008.
++ With this package you can use this instead:
++
TZ='Pacific/Auckland'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.
++ 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.
+ TZ environment variable is process-global, which
++ makes it hard to write efficient, thread-safe applications that
++ need access to multiple time zone rulesets.
+ TZ environment variable.
++ While an administrator can "do everything in UT" 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.)
+ tz regions
++ that do not fit into the POSIX model.
+ 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 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.
+ +-These are the extensions that have been made to the POSIX functions: +-
++ ++tz code
+- 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.
++ The TZ environment variable is used in generating
++ the name of a binary file from which time-related information is read
++ (or is interpreted à la POSIX); TZ is no longer
++ constrained to be a three-letter time zone
++ abbreviation followed by a number of hours and an optional three-letter
++ daylight time zone abbreviation.
++ The daylight saving time rules to be used for a
++ particular tz region are encoded in the
++ binary file; the format of the file
++ allows U.S., Australian, and other rules to be encoded, and
++ allows for situations where more than two time zone
++ abbreviations are used.
+
+- It was recognized that allowing the TZ environment variable to
+- take on values such as 'America/New_York' might
+- cause "old" programs
+- (that expect TZ to have a certain form) to operate incorrectly;
+- consideration was given to using some other environment variable
+- (for example, TIMEZONE) to hold the string used to generate the
+- time zone information file name. In the end, however, it was decided
+- to continue using TZ: it is widely used for time zone purposes;
+- separately maintaining both TZ and TIMEZONE seemed a nuisance;
+- and systems where "new" forms of TZ might cause problems can simply
+- use TZ values such as "EST5EDT" which can be used both by
+- "new" programs (a la POSIX) and "old" programs (as zone names and
+- offsets).
++ 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 binary file's 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 (à la POSIX) and "old"
++ programs (as zone names and offsets).
+
struct tm,
+- e.g., tm_gmtoff.
+-struct tm, e.g., tm_zone.
+-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.)
+-tzalloc, tzfree,
+- localtime_rz, and mktime_z for
+- more-efficient thread-safe applications that need to use
+- multiple time zones. The tzalloc
+- and tzfree functions allocate and free objects of
+- type timezone_t, and localtime_rz
+- and mktime_z are like localtime_r
+- and mktime with an extra
+- timezone_t argument. The functions were inspired
+- by NetBSD.
+-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.)
+-time_t values are supported, on systems
+- where time_t is signed.
+-struct tm, e.g., tm_gmtoff.
++ struct tm, e.g., tm_zone.
++ tzalloc, tzfree,
++ localtime_rz, and mktime_z for
++ more-efficient thread-safe applications that need to use multiple
++ time zone rulesets.
++ The tzalloc and tzfree functions
++ allocate and free objects of type timezone_t,
++ and localtime_rz and mktime_z are
++ like localtime_r and mktime with an
++ extra timezone_t argument.
++ The functions were inspired by NetBSD.
++ 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 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.)
++ time_t values are supported, on systems
++ where time_t is signed.
++
+-Points of interest to folks with other systems:
++POSIX and ISO C
++define some APIs that are vestigial:
++they are not needed, and are relics of a too-simple model that does
++not suffice to handle many real-world timestamps.
++Although the tz code supports these
++vestigial APIs for backwards compatibility, they should
++be avoided in portable applications.
++The vestigial APIs are:
+
zic' supplied with this package instead of using
+- the system 'zic', since the format
+- of zic's input is occasionally extended, and a
+- platform may still be shipping an older zic.
++ The POSIX tzname variable does not suffice and is no
++ longer needed.
++ To get a timestamp's time zone abbreviation, consult
++ the tm_zone member if available; otherwise,
++ use strftime's "%Z" conversion
++ specification.
+ 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
+- localtime(&clock)->tm_zone
+- (if TM_ZONE is defined) or
+- tzname[localtime(&clock)->tm_isdst]
+- (if HAVE_TZNAME is defined)
+- to learn the correct time zone abbreviation to use.
++ The POSIX daylight and timezone
++ variables do not suffice and are no longer needed.
++ To get a timestamp's UT offset, consult
++ the tm_gmtoff member if available; otherwise,
++ subtract values returned by localtime
++ and gmtime using the rules of the Gregorian calendar,
++ or use strftime's "%z" conversion
++ specification if a string like "+0900" suffices.
+ 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.
++ The tm_isdst member is almost never needed and most of
++ its uses should be discouraged in favor of the abovementioned
++ APIs.
++ Although it can still be used in arguments to
++ mktime to disambiguate timestamps near
++ a DST transition when the clock jumps back, this
++ disambiguation does not work when standard time itself jumps back,
++ which can occur when a location changes to a time zone with a
++ lesser UT offset.
+ time_t values when doing conversions for places
+- that don't use UT.
+- This package takes care to do these conversions correctly.
+- A comment in the source code tells how to get compatibly wrong
+- results.
++ The 7th Edition
++ UNIX 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 localtime(&clock)->tm_zone
++ (if TM_ZONE is defined) or
++ tzname[localtime(&clock)->tm_isdst]
++ (if HAVE_TZNAME is defined) to learn the correct time
++ zone abbreviation to use.
+ 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.
++ time_t values when doing conversions
++ for places that don't use UT.
++ This package takes care to do these conversions correctly.
++ A comment in the source code tells how to get compatibly wrong
++ results.
++ 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.
++
+-The functions that are conditionally compiled
+-if STD_INSPIRED is defined
+-should, at this point, be looked on primarily as food for thought. They are
+-not in any sense "standard compatible" – some are not, in fact,
+-specified in any standard. They do, however, represent responses of
+-various authors to
+-standardization proposals.
+-
+-Other time conversion proposals, in particular the one developed by folks at
+-Hewlett Packard, offer a wider selection of functions that provide capabilities
+-beyond those provided here. The absence of such functions from this package
+-is not meant to discourage the development, standardization, or use of such
+-functions. Rather, their absence reflects the decision to make this package
+-contain valid extensions to POSIX, to ensure its broad acceptability. If
+-more powerful time conversion functions can be standardized, so much the
+-better.
++The tz code and data supply the following interfaces:
+
+-The tz code and data supply the following interfaces: +-
+tz region names as per
++ "Names of time zone rulesets" above.
+ tzselect, zdump,
+- and zic, documented in their man pages.
++ The programs tzselect, zdump,
++ and zic, documented in their man pages.
+ zic input files, documented in
+- the zic man page.
++ The format of zic input files, documented in
++ the zic man page.
+ zic output files, documented in
+- the tzfile man page.
++ The format of zic output files, documented in
++ the tzfile man page.
+ zone1970.tab.
++ The format of zone table files, documented in zone1970.tab.
+ iso3166.tab.
++ The format of the country code file, documented in iso3166.tab.
+ version' in each release.
++ The version number of the code and data, as the first line of
++ the text file 'version' in each release.
+
+ Interface changes in a release attempt to preserve compatibility with
+-recent releases. For example, tz data files typically do not rely on
+-recently-added zic features, so that users can run
+-older zic versions to process newer data
+-files. Sources for time zone and daylight
+-saving time data describes how
+-releases are tagged and distributed.
++recent releases.
++For example, tz data files typically do not
++rely on recently-added zic features, so that users can
++run older zic versions to process newer data files.
++Downloading
++the tz database describes how releases
++are tagged and distributed.
+
+-Interfaces not listed above are less stable. For example, users +-should not rely on particular UT offsets or abbreviations for +-timestamps, as data entries are often based on guesswork and these +-guesses may be corrected or improved. ++Interfaces not listed above are less stable. ++For example, users should not rely on particular UT ++offsets or abbreviations for timestamps, as data entries are often ++based on guesswork and these guesses may be corrected or improved. +
+-
+ Calendrical issues are a bit out of scope for a time zone database,
+ but they indicate the sort of problems that we would run into if we
+-extended the time zone database further into the past. An excellent
+-resource in this area is Nachum Dershowitz and Edward M. Reingold,
+-Calendrical
++extended the time zone database further into the past.
++An excellent resource in this area is Nachum Dershowitz and Edward M.
++Reingold, Calendrical
+ Calculations: Third Edition, Cambridge University Press (2008).
+-Other information and sources are given in the file 'calendars'
+-in the tz distribution. They sometimes disagree.
++Other information and sources are given in the file 'calendars'
++in the tz distribution.
++They sometimes disagree.
+
+-Some people's work schedules use Mars time. Jet Propulsion Laboratory +-(JPL) coordinators have kept Mars time on and off at least since 1997 +-for the Mars Pathfinder mission. Some of their family members have +-also adapted to Mars time. Dozens of special Mars watches were built +-for JPL workers who kept Mars time during the Mars Exploration +-Rovers mission (2004). These timepieces look like normal Seikos and +-Citizens but use Mars seconds rather than terrestrial seconds. ++Some people's work schedules ++use Mars time. ++Jet Propulsion Laboratory (JPL) coordinators have kept Mars time on ++and off at least since 1997 for the ++Mars ++Pathfinder mission. ++Some of their family members have also adapted to Mars time. ++Dozens of special Mars watches were built for JPL workers who kept ++Mars time during the Mars Exploration Rovers mission (2004). ++These timepieces look like normal Seikos and Citizens but use Mars ++seconds rather than terrestrial seconds. +
+ ++ A Mars solar day is called a "sol" and has a mean period equal to +-about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is +-divided into a conventional 24-hour clock, so each Mars second equals +-about 1.02749125 terrestrial seconds. ++about 24 hours 39 minutes 35.244 seconds in terrestrial time. ++It is divided into a conventional 24-hour clock, so each Mars second ++equals about 1.02749125 terrestrial seconds. +
+ ++-The prime meridian of Mars goes through the center of the crater +-Airy-0, named in honor of the British astronomer who built the +-Greenwich telescope that defines Earth's prime meridian. Mean solar +-time on the Mars prime meridian is called Mars Coordinated Time (MTC). ++The prime ++meridian of Mars goes through the center of the crater ++Airy-0, named in ++honor of the British astronomer who built the Greenwich telescope that ++defines Earth's prime meridian. ++Mean solar time on the Mars prime meridian is ++called Mars ++Coordinated Time (MTC). +
+ ++ Each landed mission on Mars has adopted a different reference for + solar time keeping, so there is no real standard for Mars time zones. +-For example, the Mars Exploration Rover project (2004) defined two +-time zones "Local Solar Time A" and "Local Solar Time B" for its two +-missions, each zone designed so that its time equals local true solar +-time at approximately the middle of the nominal mission. Such a "time +-zone" is not particularly suited for any application other than the +-mission itself. ++For example, the ++Mars ++Exploration Rover project (2004) defined two time zones "Local ++Solar Time A" and "Local Solar Time B" for its two missions, each zone ++designed so that its time equals local true solar time at ++approximately the middle of the nominal mission. ++Such a "time zone" is not particularly suited for any application ++other than the mission itself. +
+ ++ Many calendars have been proposed for Mars, but none have achieved +-wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a ++wide acceptance. ++Astronomers often use Mars Sol Date (MSD) which is a + sequential count of Mars solar days elapsed since about 1873-12-29 +-12:00 GMT. ++12:00 GMT. +
+ ++ In our solar system, Mars is the planet with time and calendar most +-like Earth's. On other planets, Sun-based time and calendars would +-work quite differently. For example, although Mercury's sidereal +-rotation period is 58.646 Earth days, Mercury revolves around the Sun +-so rapidly that an observer on Mercury's equator would see a sunrise +-only every 175.97 Earth days, i.e., a Mercury year is 0.5 of a Mercury +-day. Venus is more complicated, partly because its rotation is +-slightly retrograde: its year is 1.92 of its days. Gas giants like +-Jupiter are trickier still, as their polar and equatorial regions +-rotate at different rates, so that the length of a day depends on +-latitude. This effect is most pronounced on Neptune, where the day is +-about 12 hours at the poles and 18 hours at the equator. ++like Earth's. ++On other planets, Sun-based time and calendars would work quite ++differently. ++For example, although Mercury's ++sidereal ++rotation period is 58.646 Earth days, Mercury revolves around the ++Sun so rapidly that an observer on Mercury's equator would see a ++sunrise only every 175.97 Earth days, i.e., a Mercury year is 0.5 of a ++Mercury day. ++Venus is more complicated, partly because its rotation is slightly ++retrograde: ++its year is 1.92 of its days. ++Gas giants like Jupiter are trickier still, as their polar and ++equatorial regions rotate at different rates, so that the length of a ++day depends on latitude. ++This effect is most pronounced on Neptune, where the day is about 12 ++hours at the poles and 18 hours at the equator. +
+ +
+-Although the tz database does not support time on other planets, it is
+-documented here in the hopes that support will be added eventually.
++Although the tz database does not support
++time on other planets, it is documented here in the hopes that support
++will be added eventually.
+
+-Sources: ++Sources for time on other planets: +
++ +