-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.
-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.
-
+
-
-
-
Names of time zone rules
+
+
Names of time zone rulesets
-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:
+
- Uniquely identify every region where clocks have agreed since 1970.
- This is essential for the intended use: static clocks keeping local
- civil time.
+ 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.
+ 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 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.
+ Be portable to a wide variety of implementations.
- Use a consistent naming conventions over the entire world.
+ 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'.
+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:
+
- 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.
+ 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 '/'.
+ 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.
+ 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'.
+ 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.
+ 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.
+ 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 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.
- 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.
+ 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.
- 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 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.
- 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 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'.
- Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
+ 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.
+ 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.
+ Use '_' to represent a space.
- Omit '.' 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'.
- 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.
+ 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.
- If a name is changed, put its old spelling in the
- '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,843 +280,1008 @@ 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').
+'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.
+
-
-
-
-
Time zone abbreviations
+
+
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,
+Here are the general guidelines used for choosing time zone abbreviations,
in decreasing order of importance:
+
+
- 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 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,6} 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'.
+ 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.
-
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.
-
-
- For zones whose times are 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.
+
+ 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.
+
+
+
+ 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'.
-
+ 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.
+
+
+
+
+ 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.
+
-
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.
+
- Use 'LMT' for local mean time of locations before the introduction
- of standard time; see "Scope of the
- tz database".
+ 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.
+ 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 current abbreviations for older timestamps to avoid confusion.
+ For example, in 1910 a common English abbreviation for time
+ 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.
+ Use a consistent style in a 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.
- 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.
+ 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'.
-
-
+
-
-
Accuracy of the tz database
+
+
Accuracy of the 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.
-Errors in the tz database arise from many sources:
+Errors in the tz database arise from many sources:
+
- The 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.
-
-
- 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.
-
-
- 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
- reporting which entries were known and which were invented.
- These books often contradict each other or give implausible entries,
- and on the rare occasions when they are checked they are
- typically found to be incorrect.
-
-
- For the UK the 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.
-
-
- Sometimes, different people in the same city would maintain clocks
- that differed significantly. Railway time was used by railroad
- companies (which did not always agree with each other),
- church-clock time was used for birth certificates, etc.
- Often this was merely common practice, but sometimes it was set by law.
- For example, from 1891 to 1911 the UT offset in France was legally
- 0:09:21 outside train stations and 0:04:21 inside.
-
-
- 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.
-
-
- The tz database does not record the earliest time for which a zone'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 zones the earliest time of validity is
- unknown.
-
-
- The tz database does not record a region's boundaries, and in many
- cases the boundaries are not known. For example, the zone
- America/Kentucky/Louisville represents a region around
- the city of
- Louisville, the boundaries of which are unclear.
-
-
- Changes that are modeled as instantaneous transitions in the tz
- database were often spread out over hours, days, or even decades.
-
-
- Even if the time is specified by law, locations sometimes
- deliberately flout the law.
-
-
- Early timekeeping practices, even assuming perfect clocks, were
- often not specified to the accuracy that the tz database requires.
-
-
- Sometimes historical timekeeping was specified more precisely
- than what the tz database can handle. For example, from 1909 to
- 1937 Netherlands clocks were legally UT +00:19:32.13, but the tz
- database cannot represent the fractional second.
-
-
- Even when all the timestamp transitions recorded by the 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.
-
-
- The tz database models pre-standard time using the proleptic Gregorian
- calendar and local mean time (LMT), but many people used other
- calendars and other timescales. For example, the Roman Empire used
- the Julian calendar, and had 12 varying-length daytime hours with a
- non-hour-based system at night.
-
-
- Early clocks were less reliable, and data entries do not represent
- clock error.
-
-
- The 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.
-
-
- Civil time was not based on atomic time before 1972, and we don't
- know the history of earth's rotation accurately enough to map SI
- seconds to historical solar time to more than about one-hour
- accuracy. See: Stephenson FR, Morrison LV, Hohenkerk CY.
- Measurement
- of the Earth's rotation: 720 BC to AD 2015.
- Proc Royal Soc A. 2016 Dec 7;472:20160404.
- Also see: Espenak F. Uncertainty
- in Delta T (ÎT).
-
-
- The relationship between POSIX time (that is, UTC but ignoring leap
- seconds) and UTC is not agreed upon after 1972. Although the POSIX
- clock officially stops during an inserted leap second, at least one
- proposed standard has it jumping back a second instead; and in
- practice POSIX clocks more typically either progress glacially during
- a leap second, or are slightly slowed while near a leap second.
-
-
- The 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.
+ The 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.
+
+
+ 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 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.
+
+
+ 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
+ reporting which entries were known and which were invented.
+ These books often contradict each other or give implausible entries,
+ and on the rare occasions when they are checked they are
+ typically found to be incorrect.
+
+
+ For the UK the 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.
+
+
+ Sometimes, different people in the same city maintain clocks
+ that differ significantly.
+ Historically, railway time was used by railroad companies (which
+ did not always
+ agree with each other), church-clock time was used for birth
+ certificates, etc.
+ More recently, competing political groups might disagree about
+ clock settings. Often this is merely common practice, but
+ sometimes it is set by law.
+ For example, from 1891 to 1911 the UT offset in France
+ was legally UT +00:09:21 outside train stations and
+ UT +00:04:21 inside. Other examples include
+ Chillicothe in 1920, Palm Springs in 1946/7, and Jerusalem and
+ Ãrümqi to this day.
+
+
+ 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.
+
+
+ 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.
+
+
+ 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.
+
+
+ Changes that are modeled as instantaneous transitions in the
+ tz
+ database were often spread out over hours, days, or even decades.
+
+
+ Even if the time is specified by law, locations sometimes
+ deliberately flout the law.
+
+
+ Early timekeeping practices, even assuming perfect clocks, were
+ often not specified to the accuracy that the
+ tz database requires.
+
+
+ Sometimes historical timekeeping was specified more precisely
+ than what the 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.
+
+
+ Even when all the timestamp transitions recorded by the
+ 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.
+
+
+ The 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.
+
+
+ Early clocks were less reliable, and data entries do not represent
+ clock error.
+
+
+ The 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.
+
+ The relationship between POSIX time (that is, UTC but
+ ignoring leap
+ seconds) and UTC is not agreed upon after 1972.
+ Although the POSIX
+ clock officially stops during an inserted leap second, at least one
+ proposed standard has it jumping back a second instead; and in
+ practice POSIX clocks more typically either progress glacially during
+ a leap second, or are slightly slowed while near a leap second.
+
+
+ The 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.
-
-
-
-
-
Time and date functions
-The tz code contains time and date functions that are upwards
-compatible with those of POSIX.
+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.
+
+
+
Time and date functions
-POSIX has the following properties and limitations.
+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 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:
- 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.
+ 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.
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.
+ 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.
+ specifies the beginning and end of DST.
+ If this is absent, the system supplies its own ruleset
+ for DST, and its rules 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.
+ 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:
+ takes one of the following forms:
Jn (1≤n≤365)
- origin-1 day number not counting February 29
-
+ 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.
+ origin-0 day number counting February 29 if present
+
+ 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 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'
+
+ 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'
+
+
+ This POSIX TZ string is hard to remember, and
+ mishandles some timestamps before 2008.
+ With this package you can use this instead:
+
- 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'
+
+
+ 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.
+
+
+ The TZ environment variable is process-global, which
+ makes it hard to write efficient, thread-safe applications that
+ need access to multiple time zone rulesets.
+
+
+ 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 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.)
+
+
+ POSIX provides no convenient and efficient way to determine
+ the UT offset and time zone abbreviation of arbitrary
+ timestamps, particularly for tz regions
+ that do not fit into the POSIX model.
+
+
+ POSIX requires that systems ignore leap seconds.
+
+
+ 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.
+
+
-
TZ='Pacific/Auckland'
+
Extensions to POSIX in the
+tz code
+
+
+
+ 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 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).
+
- 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.
+ The code supports platforms with a UT offset member
+ in struct tm, e.g., tm_gmtoff.
- The TZ environment variable is process-global, which makes it hard
- to write efficient, thread-safe applications that need access
- to multiple time zones.
+ The code supports platforms with a time zone abbreviation member in
+ struct tm, e.g., tm_zone.
- 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 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.)
+ Functions 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.
- POSIX provides no convenient and efficient way to determine the UT
- offset and time zone abbreviation of arbitrary timestamps,
- particularly for time zone settings that do not fit into the
- POSIX model.
+ 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 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.)
- POSIX requires that systems ignore leap seconds.
+ Negative time_t values are supported, on systems
+ where time_t is signed.
- 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 functions can account for leap seconds, thanks to Bradley White.
+
+
POSIX features no longer needed
-These are the extensions that have been made to the POSIX functions:
+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:
-
- The TZ environment variable is used in generating the name of a file
- from which time zone information is read (or is interpreted a la
- POSIX); TZ is no longer constrained to be a three-letter time zone
- name followed by a number of hours and an optional three-letter
- daylight time zone name. The daylight saving time rules to be used
- for a particular time zone are encoded in the time zone file;
- the format of the file allows U.S., Australian, and other rules to be
- encoded, and allows for situations where more than two time zone
- abbreviations are used.
-
-
- It was recognized that allowing the TZ environment variable to
- take on values such as 'America/New_York' might
- cause "old" programs
- (that expect TZ to have a certain form) to operate incorrectly;
- consideration was given to using some other environment variable
- (for example, TIMEZONE) to hold the string used to generate the
- time zone information file name. In the end, however, it was decided
- to continue using TZ: it is widely used for time zone purposes;
- separately maintaining both TZ and TIMEZONE seemed a nuisance;
- and systems where "new" forms of TZ might cause problems can simply
- use TZ values such as "EST5EDT" which can be used both by
- "new" programs (a la POSIX) and "old" programs (as zone names and
- offsets).
-
-
-
- The code supports platforms with a UT offset member
- in struct tm,
- e.g., tm_gmtoff.
-
-
- The code supports platforms with a time zone abbreviation member in
- struct tm, e.g., tm_zone.
-
-
- 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.)
-
-
- Functions 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.
-
-
- 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.
-
-
- These functions can account for leap seconds, thanks to Bradley White.
-
+ 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.
+
+
+ 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.
+
+
+ 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.
+
-
-Points of interest to folks with other systems:
-
+
+
Other portability notes
- Code compatible with this package is already part of many platforms,
- including GNU/Linux, Android, the BSDs, Chromium OS, Cygwin, AIX, iOS,
- BlackBery 10, macOS, Microsoft Windows, OpenVMS, and Solaris.
- 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 is occasionally extended, and a
- platform may still be shipping an older zic.
-
-
- 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
- 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 4.2BSD gettimeofday function is not used in
- this package.
- This formerly let users obtain the current UTC offset and DST flag,
- but this functionality was removed in later versions of BSD.
-
-
- In SVR2, time conversion fails for near-minimum or near-maximum
- time_t values when doing conversions for places
- that don't use 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
+ UNIXtimezone 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 4.2BSD gettimeofday function is not
+ used in this package.
+ This formerly let users obtain the current UTC offset
+ and DST flag, but this functionality was removed in
+ later versions of BSD.
+
+
+ In SVR2, time conversion fails for near-minimum or
+ near-maximum time_t values when doing conversions
+ for places that don't use UT.
+ This package takes care to do these conversions correctly.
+ A comment in the source code tells how to get compatibly wrong
+ results.
+
+
+ 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 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.
-
+
+
+
Interface stability
-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:
-
-
-
-
Interface stability
-
-The tz code and data supply the following interfaces:
-
- The programs tzselect, zdump,
- and zic, documented in their man pages.
+ The programs tzselect, zdump,
+ and zic, documented in their man pages.
- The format of zic input files, documented in
- the zic man page.
+ The format of zic input files, documented in
+ the zic man page.
- The format of zic output files, documented in
- the tzfile man page.
+ The format of zic output files, documented in
+ the tzfile man page.
- The format of zone table files, documented in zone1970.tab.
+ The format of zone table files, documented in zone1970.tab.
- The format of the country code file, documented in iso3166.tab.
+ The format of the country code file, documented in iso3166.tab.
- The version number of the code and data, as the first line of
- the text file '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.
-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.
-
+
-
+
diff --git a/contrib/tzdata/version b/contrib/tzdata/version
index f6a71fe2f..ae3ff7cb1 100644
--- a/contrib/tzdata/version
+++ b/contrib/tzdata/version
@@ -1 +1 @@
-2018c
+2018d
diff --git a/contrib/tzdata/ziguard.awk b/contrib/tzdata/ziguard.awk
new file mode 100644
index 000000000..6da3691f6
--- /dev/null
+++ b/contrib/tzdata/ziguard.awk
@@ -0,0 +1,62 @@
+# Convert tzdata source into vanguard or rearguard form.
+
+# Contributed by Paul Eggert. This file is in the public domain.
+
+# This is not a general-purpose converter; it is designed for current tzdata.
+#
+# When converting to vanguard form, the output can use negative SAVE
+# values.
+#
+# When converting to rearguard form, the output uses only nonnegative
+# SAVE values. The idea is for the output data to simulate the behavior
+# of the input data as best it can within the constraints of the
+# rearguard format.
+
+BEGIN {
+ dst_type["vanguard.zi"] = 1
+ dst_type["main.zi"] = 1
+ dst_type["rearguard.zi"] = 1
+
+ # The command line should set OUTFILE to the name of the output file.
+ if (!dst_type[outfile]) exit 1
+ vanguard = outfile == "vanguard.zi"
+}
+
+/^Zone/ { zone = $2 }
+
+outfile != "main.zi" {
+ in_comment = /^#/
+
+ # If this line should differ due to Ireland using negative SAVE values,
+ # uncomment the desired version and comment out the undesired one.
+ Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/
+ Zone_Dublin_post_1968 \
+ = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \
+ && (!$(in_comment + 4) || 1968 < $(in_comment + 4)))
+ if (Rule_Eire || Zone_Dublin_post_1968) {
+ if ((Rule_Eire \
+ || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT")) \
+ == vanguard) {
+ sub(/^#/, "")
+ } else if (/^[^#]/) {
+ sub(/^/, "#")
+ }
+ }
+}
+
+# If a Link line is followed by a Zone line for the same data, comment
+# out the Link line. This can happen if backzone overrides a Link
+# with a Zone.
+/^Link/ {
+ linkline[$3] = NR
+}
+/^Zone/ {
+ sub(/^Link/, "#Link", line[linkline[$2]])
+}
+
+{ line[NR] = $0 }
+
+END {
+ for (i = 1; i <= NR; i++)
+ print line[i]
+}
diff --git a/contrib/tzdata/zishrink.awk b/contrib/tzdata/zishrink.awk
index 23d623e99..d617644e9 100644
--- a/contrib/tzdata/zishrink.awk
+++ b/contrib/tzdata/zishrink.awk
@@ -37,7 +37,7 @@ function process_input_line(line, field, end, i, n, startdef)
# Remove comments, normalize spaces, and append a space to each line.
sub(/#.*/, "", line)
line = line " "
- gsub(/[\f\r\t\v ]+/, " ", line)
+ gsub(/[\t ]+/, " ", line)
# Abbreviate keywords. Do not abbreviate "Link" to just "L",
# as pre-2017c zic erroneously diagnoses "Li" as ambiguous.
@@ -148,7 +148,7 @@ BEGIN {
print "# This zic input file is in the public domain."
}
-/^[\f\r\t\v ]*[^#\f\r\t\v ]/ {
+/^[\t ]*[^#\t ]/ {
process_input_line($0)
}
diff --git a/contrib/tzdata/zone.tab b/contrib/tzdata/zone.tab
index e1bfdee2e..f92c919b8 100644
--- a/contrib/tzdata/zone.tab
+++ b/contrib/tzdata/zone.tab
@@ -429,7 +429,7 @@ US +593249-1394338 America/Yakutat Alaska - Yakutat
US +643004-1652423 America/Nome Alaska (west)
US +515248-1763929 America/Adak Aleutian Islands
US +211825-1575130 Pacific/Honolulu Hawaii
-UY -3453-05611 America/Montevideo
+UY -345433-0561245 America/Montevideo
UZ +3940+06648 Asia/Samarkand Uzbekistan (west)
UZ +4120+06918 Asia/Tashkent Uzbekistan (east)
VA +415408+0122711 Europe/Vatican
diff --git a/contrib/tzdata/zone1970.tab b/contrib/tzdata/zone1970.tab
index 7c4793a84..64273f6b4 100644
--- a/contrib/tzdata/zone1970.tab
+++ b/contrib/tzdata/zone1970.tab
@@ -13,7 +13,7 @@
# See the file '/usr/share/misc/iso3166'.
# 2. Latitude and longitude of the zone's principal location
# in ISO 6709 sign-degrees-minutes-seconds format,
-# either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS,
+# either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS,
# first latitude (+ is north), then longitude (+ is east).
# 3. Zone name used in value of TZ environment variable.
# Please see the theory.html file for how zone names are chosen.
@@ -372,7 +372,7 @@ US +593249-1394338 America/Yakutat Alaska - Yakutat
US +643004-1652423 America/Nome Alaska (west)
US +515248-1763929 America/Adak Aleutian Islands
US,UM +211825-1575130 Pacific/Honolulu Hawaii
-UY -3453-05611 America/Montevideo
+UY -345433-0561245 America/Montevideo
UZ +3940+06648 Asia/Samarkand Uzbekistan (west)
UZ +4120+06918 Asia/Tashkent Uzbekistan (east)
VE +1030-06656 America/Caracas
--
2.42.0