or the file tz-link.html for how to acquire the code and data. Once acquired, read the comments in the file 'Makefile' and make any changes needed to make things right for your system, especially if you are using some platform other than GNU/Linux. Then run the following commands, substituting your desired installation directory for "$HOME/tzdir": make TOPDIR=$HOME/tzdir install $HOME/tzdir/usr/bin/zdump -v America/Los_Angeles This database of historical local time information has several goals: * Provide a compendium of data about the history of civil time that is useful even if not 100% accurate. * Give an idea of the variety of local time rules that have existed in the past and thus may be expected in the future. * Test the generality of the local time rule description system. The information in the time zone data files is by no means authoritative; fixes and enhancements are welcome. Please see the file CONTRIBUTING for details. Thanks to these Time Zone Caballeros who've made major contributions to the time conversion package: Keith Bostic; Bob Devine; Paul Eggert; Robert Elz; Guy Harris; Mark Horton; John Mackin; and Bradley White. Thanks also to Michael Bloom, Art Neilson, Stephen Prince, John Sovereign, and Frank Wales for testing work, and to Gwillim Law for checking local mean time data. Thanks in particular to Arthur David Olson, the project's founder and first maintainer, to whom the time zone community owes the greatest debt of all. None of them are responsible for remaining errors. ----- This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. The other files in this distribution are either public domain or BSD licensed; see the file LICENSE for details. PK8�[��N�N�theory.htmlnuW+A�� Theory and pragmatics of the tz code and data

Theory and pragmatics of the `tz` code and data

Outline

Scope of the `tz` database

The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone 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.

Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970.

Clock transitions before 1970 are recorded for each timezone, because most systems support timestamps before 1970 and could misbehave if data entries were omitted for pre-1970 transitions. However, the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping. Although some information outside the scope of the database is collected in a file backzone that is distributed along with the database proper, this file is less reliable and does not necessarily follow database guidelines.

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-2017, 2018 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 timezone 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 timezone changes its clock, and even the timezone's notional base offset from UTC, are variable. It does not always make sense to talk about a timezone's "base offset", which is not necessarily a single number.

Names of timezones

Each timezone has a unique name. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the timezone name "Europe/Uzhgorod". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. The Unicode Common Locale Data Repository contains data that may be useful for other selection interfaces; it maps timezone names like Europe/Uzhgorod to CLDR names like uauzh which are in turn mapped to locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and "乌日哥罗德".

The naming conventions attempt to strike a balance among the following goals:

Uniquely identify every timezone where clocks have agreed since 1970. This is essential for the intended use: static clocks keeping local civil time.
Indicate to experts where the timezone's clocks typically are.
Be robust in the presence of political changes. For example, names of countries are ordinarily not used, to avoid incompatibilities when countries change their name (e.g., Zaire→Congo) or when locations change countries (e.g., Hong Kong from UK colony to China).
Be portable to a wide variety of implementations.
Use a consistent naming conventions over the entire world.

Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'. Some names are further qualified to help avoid confusion; for example, 'America/Indiana/Petersburg' distinguishes Petersburg, Indiana from other Petersburgs in America.

Here are the general guidelines used for choosing timezone 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 Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below.
A name must not be empty, or contain '//', or start or end with '/'.
Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case.
If one name A is an initial prefix of another name AB (ignoring case), then B must not start with '/', as a regular file cannot have the same name as a directory in POSIX. For example, America/New_York precludes America/New_York/Bronx.
Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there.
There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory.
If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970. Otherwise these tables would become annoyingly large.
If a name is ambiguous, use a less ambiguous alternative; e.g., many cities are named San José and Georgetown, so prefer America/Costa_Rica to America/San_Jose and America/Guyana to America/Georgetown.
Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.
Use mainstream English spelling, e.g., prefer Europe/Rome to Europa/Roma, and prefer Europe/Athens to the Greek Ευρώπη/Αθήνα or the Romanized Evrópi/Athína. The POSIX file name restrictions encourage this guideline.
Use the most populous among locations in a region, e.g., prefer Asia/Shanghai to Asia/Beijing. Among locations with similar populations, pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan.
Use the singular form, e.g., prefer Atlantic/Canary to Atlantic/Canaries.
Omit common suffixes like '_Islands' and '_City', unless that would lead to ambiguity. E.g., prefer America/Cayman to America/Cayman_Islands and America/Guatemala to America/Guatemala_City, but prefer America/Mexico_City to America/Mexico because the country of Mexico has several time zones.
Use '_' to represent a space.
Omit '.' from abbreviations in names. E.g., prefer Atlantic/St_Helena to Atlantic/St._Helena.
Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's.
If a name is changed, put its old spelling in the 'backward' file. This means old spellings will continue to work.

The file 'zone1970.tab' lists geographical locations used to name timezones. It is intended to be an exhaustive list of names for geographic regions as described above; this is a subset of the timezones 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.

Older versions of this package used a different naming scheme, and these older names are still supported. See the file 'backward' for most of these older names (e.g., 'US/Eastern' instead of 'America/New_York'). The other old-fashioned names still supported are 'WET', 'CET', 'MET', and 'EET' (see the file 'europe').

Older versions of this package defined legacy names that are incompatible with the first 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.

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 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 space and '?', but these characters have a special meaning to the UNIX 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.
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/GDT Guam, HST/HDT/HWT/HPT 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, PST/PDT Philippine, 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.

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.
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 +0530 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 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 timezone's history. For example, if a history tends to use numeric abbreviations and a particular entry could go either way, use a numeric abbreviation.
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 '-0600' instead of time zone abbreviations like 'CST'.

Accuracy of the `tz` database

The tz database is not authoritative, and it surely has errors. Corrections are welcome and encouraged; see the file CONTRIBUTING. Users requiring authoritative data should consult national standards bodies and the references cited in the database's comments.

Errors in the tz database arise from many sources:

The tz database predicts future 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 timezones 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 timezone'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 timezones 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 timezone 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. When transitions are known but the historical rules behind them are not, the database contains Zone and Rule entries that are intended to represent only the generated transitions, not any underlying historical rules; however, this intent is recorded at best only in commentary.
The tz database models time using the proleptic Gregorian calendar with days containing 24 equal-length hours numbered 00 through 23, except when clock transitions occur. Pre-standard time is modeled as local mean time. However, historically 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. And even today, some local practices diverge from the Gregorian calendar with 24-hour days. These divergences range from relatively minor, such as Japanese bars giving times like "24:30" for the wee hours of the morning, to more-significant differences such as the east African practice of starting the day at dawn, renumbering the Western 06:00 to be 12:00. These practices are largely outside the scope of the tz code and data, which provide only limited support for date and time localization such as that required by POSIX. If DST is not used a different time zone can often do the trick; for example, in Kenya a TZ setting like <-03>3 or America/Cayenne starts the day six hours later than Africa/Nairobi does.
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 do not 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 is 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 timezones 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. 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 cannot 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:

stdoffset[dst[offset][,date[/time],date[/time]]]

where:

std and dst
are 3 or more characters specifying the standard and daylight saving time (DST) zone abbreviations. 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.

date[/time],date[/time]
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.

date
takes one of the following forms:

Jn (1≤n≤365)
origin-1 day number not counting February 29

n (0≤n≤365)
origin-0 day number counting February 29 if present

Mm.n.d (0[Sunday]≤d≤6[Saturday], 1≤n≤5, 1≤m≤12)
for the dth day of week n of month m of the year, where week 1 is the first week in which day d appears, and '5' stands for the last week in which day d appears (which may be either the 4th or 5th week). Typically, this is the only useful form; the n and Jn forms are rarely used.

Here is an example POSIX TZ string for 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:
```
TZ='Pacific/Auckland'
```
POSIX does not define the DST transitions for TZ values like "EST5EDT". Traditionally the current US DST rules were used to interpret such values, but this meant that the US DST rules were compiled into each program that did time conversion. This meant that when US time conversion rules changed (as in the United States in 1987), all programs that did time conversion had to 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 timezones.
In POSIX, there is 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 timezones 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 system, and POSIX.1-2013 and the tz code both require time_t to be an integer type.

Extensions to POSIX in the `tz` code

The TZ environment variable is used in generating the name of a file from which time-related information is read (or is interpreted à la POSIX); TZ is no longer constrained to be a string containing abbreviations and numeric data as described above. The file's format is TZif, a timezone information format that contains binary data. The daylight saving time rules to be used for a particular timezone are encoded in the TZif file; the format of the file allows US, 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 TZif 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 legacy TZ values such as "EST5EDT" which can be used by "new" programs as well as by "old" programs that assume pre-POSIX TZ values.
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.
Functions tzalloc, tzfree, localtime_rz, and mktime_z for more-efficient thread-safe applications that need to use multiple timezones. 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 do not provide tzsetwall, you will not 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 is no TZ environment variable; portable applications should not, however, rely on this behavior since it is 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.

POSIX features no longer needed

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 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.

Other portability notes

The 7th Edition UNIX timezone function is not present in this package; it is 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 do not 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 those supported by the Time Zone Database Parser, 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.

Interface stability

The tz code and data supply the following interfaces:

A set of timezone names as per "Names of timezones" above.
Library functions described in "Time and date functions" above.
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 output files, documented in the tzfile man page.
The format of zone table files, documented in zone1970.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.

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. 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.

Calendrical issues

Calendrical issues are a bit out of scope for a time zone database, but they indicate the sort of problems that we would run into if we extended the time zone database further into the past. An excellent resource in this area is Edward M. Reingold and Nachum Dershowitz, Calendrical Calculations: The Ultimate Edition, Cambridge University Press (2018). Other information and sources are given in the file 'calendars' in the tz distribution. They sometimes disagree.

Time and time zones on other planets

Some people's work schedules use Mars time. Jet Propulsion Laboratory (JPL) coordinators kept Mars time on and off during the Mars Pathfinder mission. Some of their family members 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.

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 timekeeping, 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.

Many calendars have been proposed for Mars, but none have achieved 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.

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.

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 for time on other planets:

Michael Allison and Robert Schmunk, "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" (2015-06-30).
Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times (2004-01-14), pp A1, A20–A21.
Tom Chmielewski, "Jet Lag Is Worse on Mars", The Atlantic (2015-02-26)
Matt Williams, "How long is a day on the other planets of the solar system?" (2016-01-20).

PK8�[ٺ��tz-link.htmlnuW+A�� Sources for time zone and daylight saving time data

Sources for time zone and daylight saving time data

Time zone and daylight-saving rules are controlled by individual governments. They are sometimes changed with little notice, and their histories and planned futures are often recorded only fitfully. Here is a summary of attempts to organize and record relevant data in this area.

The `tz` database

The public-domain time zone database contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries and daylight saving rules. This database (known as tz, tzdb, or zoneinfo) is used by several implementations, including the GNU C Library (used in GNU/Linux), Android, FreeBSD, NetBSD, OpenBSD, Chromium OS, Cygwin, DJGPP, MINIX, MySQL, webOS, AIX, BlackBerry 10, iOS, macOS, Microsoft Windows, OpenVMS, Oracle Database, and Oracle Solaris.

Each main entry in the database represents a timezone for a set of civil-time clocks that have all agreed since 1970. Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006. To use the database on an extended POSIX implementation set the TZ environment variable to the location's full name, e.g., TZ="America/New_York".

Associated with each timezone is a history of offsets from Universal Time (UT), which is Greenwich Mean Time (GMT) with days beginning at midnight; for timestamps after 1960 this is more precisely Coordinated Universal Time (UTC). The database also records when daylight saving time was in use, along with some time zone abbreviations such as EST for Eastern Standard Time in the US.

Downloading the `tz` database

The following shell commands download the latest release's two tarballs to a GNU/Linux or similar host.

mkdir tzdb
cd tzdb
wget https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz
wget https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
gzip -dc tzcode-latest.tar.gz | tar -xf -
gzip -dc tzdata-latest.tar.gz | tar -xf -

Alternatively, the following shell commands download the same release in a single-tarball format containing extra data useful for regression testing:

wget https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz
lzip -dc tzdb-latest.tar.lz | tar -xf -

These commands use convenience links to the latest release of the tz database hosted by the Time Zone Database website of the Internet Assigned Numbers Authority (IANA). Older releases are in files named tzcodeV.tar.gz, tzdataV.tar.gz, and tzdb-V.tar.lz, where V is the version. Since 1996, each version has been a four-digit year followed by lower-case letter (a through z, then za through zz, then zza through zzz, and so on). Since version 2016h, each release has contained a text file named "version" whose first (and currently only) line is the version. The releases are also available in an FTP directory via a less-secure protocol.

Alternatively, a development repository of code and data can be retrieved from GitHub via the shell command:

git clone https://github.com/eggert/tz

Since version 2012e, each release has been tagged in development repositories. Untagged commits are less well tested and probably contain more errors.

After obtaining the code and data files, see the README file for what to do next. The code lets you compile the tz source files into machine-readable binary files, one for each location. The binary files are in a special timezone information format (TZif). The code also lets you read a TZif file and interpret timestamps for that location.

Changes to the `tz` database

The tz code and data are by no means authoritative. If you find errors, please send changes to tz@iana.org, the time zone mailing list. You can also subscribe to it and browse the archive of old messages.

If your government plans to change its time zone boundaries or daylight saving rules, inform tz@iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see "On the Timing of Time Zone Changes" for examples.

Changes to the tz code and data are often propagated to clients via operating system updates, so client tz data can often be corrected by applying these updates. With GNU/Linux and similar systems, if your maintenance provider has not yet adopted the latest tz data, you can often short-circuit the process by tailoring the generic instructions in the tz README file and installing the latest data yourself. System-specific instructions for installing the latest tz data have also been published for AIX, Android, ICU, IBM and Oracle Java, Joda-Time, MySQL, and Noda Time (see below).

Sources for the tz database are UTF-8 text files with lines terminated by LF, which can be modified by common text editors such as GNU Emacs, gedit, and vim. Specialized source-file editing can be done via the Sublime zoneinfo package for Sublime Text and the VSCode zoneinfo extension for Visual Studio Code.

For further information about updates, please see Procedures for Maintaining the Time Zone Database (Internet RFC 6557). More detail can be found in Theory and pragmatics of the tz code and data. A0 TimeZone Migration displays changes between recent tzdb versions.

Commentary on the `tz` database

The article tz database is an encyclopedic summary.
How to Read the tz Database Source Files explains the tz database format.
A literary appreciation of the Olson/Zoneinfo/tz database comments on the database's style.

Web sites using recent versions of the `tz` database

These are listed roughly in ascending order of complexity and fanciness.

Time.is shows locations' time and zones.
TimeJones.com, Time Zone Converter and The World Clock are time zone converters.
Date and Time Gateway lets you see the TZ values directly.
Current Time in 1000 Places uses descriptions of the values.
Time Zone Converter uses a pulldown menu.
Complete timezone information for all countries displays tables of DST rules.
The World Clock – Worldwide lets you sort zone names and convert times.
24TimeZones has a world time map and a time converter.
Time Difference calculates the current time difference between locations.
Weather Now and The Time Now list the weather too.

Network protocols for `tz` data

The Internet Engineering Task Force's Time Zone Data Distribution Service (tzdist) working group defined TZDIST (Internet RFC 7808), a time zone data distribution service, along with CalDAV (Internet RFC 7809), a calendar access protocol for transferring time zone data by reference. The tzdist-bis mailing list discusses two Internet drafts: TZDIST Geolocate Extension lets a client determine its timezone from its geographic location using a 'geo' URI, and The Time Zone Information Format (TZif) specifies the format of TZif data.
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Internet RFC 5445) covers time zone data; see its VTIMEZONE calendar component. The iCalendar format requires specialized parsers and generators; a variant xCal (Internet RFC 6321) uses XML format, and a variant jCal (Internet RFC 7265) uses JSON format.

Other `tz` compilers

Vzic is a C program that compiles tz source into iCalendar-compatible VTIMEZONE files. Vzic is freely available under the GNU General Public License (GPL).
tziCal – tz database conversion utility is like Vzic, except for the .NET framework and with a BSD-style license.
DateTime::TimeZone contains a script parse_olson that compiles tz source into Perl modules. It is part of the Perl DateTime Project, which is freely available under both the GPL and the Perl Artistic License. DateTime::TimeZone also contains a script tests_from_zdump that generates test cases for each clock transition in the tz database.
The Time Zone Database Parser is a C++ parser and runtime library that is moving forward for inclusion in the next iteration of ISO International Standard ISO/IEC 14882:2017(E) – Programming Language C++. It is freely available under the MIT license.
International Components for Unicode (ICU) contains C/C++ and Java libraries for internationalization that has a compiler from tz source and from CLDR data (mentioned below) into an ICU-specific format. ICU is freely available under a BSD-style license.
The Tzdata package for the Elixir language downloads and compiles tz source and exposes APIs for use. It is freely available under the MIT license.
Java-based compilers and libraries include:
- The TZUpdater tool compiles tz source into the format used by Oracle Java.
- The Java SE java.time API in Java 8 and later can be supplemented by ThreeTen-Extra, which is freely available under a BSD-style license.
- Joda-Time – Java date and time API contains a class org.joda.time.tz.ZoneInfoCompiler that compiles tz source into a binary format. It inspired Java 8 java.time, which its users should migrate to once they can assume Java 8 or later. It is available under the Apache License.
- Time4A: Advanced date and time library for Android and Time4J: Advanced date, time and interval library for Java compile tz source into a binary format. Time4A is available under the Apache License and Time4J is available under the GNU Lesser General Public License (LGPL).
- ICU (mentioned above) contains compilers and Java-based libraries.
Noda Time – Date and time API for .NET is like Joda-Time and Time4J, but for the .NET framework instead of Java. It is freely available under the Apache License.
JavaScript-based compilers and libraries include:
- CompactTimeZoneGenerator compiles time zone data into a compact form designed for JavaScript. It is freely available under a combination of the MIT license and the Apache License.
- Moment Timezone is a plugin for the Moment.js date manipulation library. It is freely available under the MIT license.
- TimezoneJS.Date's API is upward compatible with standard JavaScript Dates. It is freely available under the Apache License.
- Walltime-js translates UT to local time. It is freely available under the MIT license.
JuliaTime contains a compiler from tz source into Julia. It is freely available under the MIT license.
Delphi/FPC Time Zone Database compiles from tz source into Object Pascal as compiled by Delphi and FPC. It is freely available under a BSD-style license.
pytz – World Timezone Definitions for Python compiles tz source into Python. It is freely available under a BSD-style license.
TZInfo – Ruby Timezone Library compiles tz source into Ruby. It is freely available under the MIT license.
The Chronos Date/Time Library is a Smalltalk class library that compiles tz source into a time zone repository whose format is either proprietary or an XML-encoded representation.
Tcl contains a developer-oriented parser that compiles tz source into text files, along with a runtime that can read those files. Tcl is freely available under a BSD-style license.

Other `tz`-based time zone software

FoxClocks is an extension for Google Chrome and for Mozilla Toolkit applications like Firefox and Thunderbird. It displays multiple clocks in the application window, and has a mapping interface to Google Earth. It is freely available under the GPL.
Go programming language implementations contain a copy of a 32-bit subset of a recent tz database in a Go-specific format.
International clock (intclock) is a clock that displays multiple time zones on GNU/Linux and similar systems. It is freely available under the GPL.
Microsoft Windows 8.1 and later has tz data and CLDR data (mentioned below) used by the Windows Runtime / Universal Windows Platform classes DateTimeFormatter and Calendar. Exploring Windows Time Zones with System.TimeZoneInfo describes the older, proprietary method of Microsoft Windows 2000 and later, which stores time zone data in the Windows Registry. The Zone → Tzid table or XML file of the CLDR data maps proprietary zone IDs to tz names. These mappings can be performed programmatically via the TimeZoneConverter .NET library, or the ICU Java and C++ libraries mentioned above.
Oracle Java contains a copy of a subset of a recent tz database in a Java-specific format.
Time Zone Master is a Microsoft Windows clock program that can automatically download, compile and use tz releases. The Basic version is free.
VelaTerra is a macOS program. Its developers offer free licenses to tz contributors.

Other time zone databases

Time-zone Atlas is Astrodienst's Web version of Shanks and Pottenger's out-of-print time zone history atlases for the US and for the world, now published in software form by ACS-Starcrafts. Although these extensive atlases were sources for much of the older tz data, they are unreliable as Shanks appears to have guessed many UT offsets and transitions. The atlases cite no sources and do not indicate which entries are guesswork.
HP-UX has a database in its own tztab(4) format.
Microsoft Windows has proprietary data mentioned above.
World Time Server is another time zone database.
The Standard Schedules Information Manual of the International Air Transport Association gives current time zone rules for airports served by commercial aviation.

Maps

The United States Central Intelligence Agency (CIA) publishes a time zone map; the Perry–Castañeda Library Map Collection of the University of Texas at Austin has copies of recent editions. The pictorial quality is good, but the maps do not indicate daylight saving time, and parts of the data are a few years out of date.
Current time around the world and standard time zones map of the world has several fancy time zone maps; it covers Russia particularly well. The maps' pictorial quality is not quite as good as the CIA's but the maps are more up to date.
How much is time wrong around the world? maps the difference between mean solar and standard time, highlighting areas such as western China where the two differ greatly. It's a bit out of date, unfortunately.

Time zone boundaries

Geographical boundaries between timezones are available from several geolocation services and other sources.

Timezone Boundary Builder extracts Open Street Map data to build boundaries of tzdb timezones. Its code is freely available under the MIT license, and its data entries are freely available under the Open Data Commons Open Database License. The maps' borders appear to be quite accurate.
Programmatic interfaces that map geographical coordinates via tz_world to tzdb timezones include:
- GeoTimeZone is written in C# and is freely available under the MIT license.
- The latlong package is written in Go and is freely available under the Apache License.
- LatLongToTimezone, in both Java and Swift form, is freely available under the MIT license.
- For Node.js, the geo-tz module is freely available under the MIT license, and the tz-lookup module is in the public domain.
- The timezonefinder library for Python is freely available under the MIT license.
- The timezone_finder library for Ruby is freely available under the MIT license.
Free access via a network API, if you register a key, is provided by the GeoNames Timezone web service, the Google Maps Time Zone API, and the Time Zone Database & API. Commercial network API access is provided by AskGeo and GeoGarage.
"How to get a time zone from a location using latitude and longitude coordinates?" discusses other geolocation possibilities.
Administrative Divisions of Countries ("Statoids") lists political subdivision data related to time zones.
Time zone boundaries for multizone countries summarizes legal boundaries between time zones within countries.
Manifold Software – GIS and Database Tools includes a Manifold-format map of world time zone boundaries distributed under the GPL.
A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UT−12 and UT+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common.

Civil time concepts and history

A Walk through Time surveys the evolution of timekeeping.
The history of daylight saving time is surveyed in About Daylight Saving Time – History, rationale, laws & dates and summarized in A Brief History of Daylight Saving Time.
Time Lords discusses how authoritarians manipulate civil time.
Working with Time Zones contains guidelines and best practices for software applications that deal with civil time.
A History of the International Date Line tells the story of the most important time zone boundary.
Basic Time Zone Concepts discusses terminological issues behind time zones.

National histories of legal time

Australia: The Parliamentary Library has commissioned a research paper on daylight saving time in Australia. The Bureau of Meteorology publishes a list of Implementation Dates of Daylight Savings Time within Australia.
Belgium: The Royal Observatory of Belgium maintains a table of time in Belgium (in Dutch).
Brazil: The Time Service Department of the National Observatory records Brazil's daylight saving time decrees (in Portuguese).
Canada: National Research Council Canada publishes current and some older information about time zones & daylight saving time.
Chile: The Hydrographic and Oceanographic Service of the Chilean Navy publishes a history of Chile's official time (in Spanish).
China: The Hong Kong Observatory maintains a history of summer time in Hong Kong, and Macau's Meteorological and Geophysical Bureau maintains a similar history for Macau. Unfortunately the latter is incomplete and has errors.
Czech Republic: When daylight saving time starts and ends (in Czech) summarizes and cites historical DST regulations.
Germany: The National Institute for Science and Technology maintains the Realisation of Legal Time in Germany.
Israel: The Interior Ministry periodically issues announcements (in Hebrew).
Italy: The National Institute of Metrological Research maintains a table of civil time (in Italian).
Malaysia: See Singapore below.
Mexico: The Investigation and Analysis Service of the Mexican Library of Congress has published a history of Mexican local time (in Spanish).
Netherlands: Legal time in the Netherlands (in Dutch) covers the history of local time in the Netherlands from ancient times.
New Zealand: The Department of Internal Affairs maintains a brief History of Daylight Saving. The privately-maintained History of New Zealand time has more details.
Singapore: Why is Singapore in the "Wrong" Time Zone? details the history of legal time in Singapore and Malaysia.
United Kingdom: History of legal time in Britain discusses in detail the country with perhaps the best-documented history of clock adjustments. The National Physical Laboratory also maintains an Archive of Summer time dates.
United States: The Department of Transportation's Recent Time Zone Proceedings lists changes to time zone boundaries.
Uruguay: The Oceanography, Hydrography, and Meteorology Service of the Uruguayan Navy (SOHMA) publishes an annual almanac (in Spanish).

Precision timekeeping

The Science of Timekeeping is a thorough introduction to the theory and practice of precision timekeeping.
The Science of Time 2016 contains several freely-readable papers.
NTP: The Network Time Protocol (Internet RFC 5905) discusses how to synchronize clocks of Internet hosts.
The Huygens family of software algorithms can achieve accuracy to a few tens of nanoseconds in scalable server farms without special hardware.
The Precision Time Protocol (IEEE 1588) can achieve submicrosecond clock accuracy on a local area network with special-purpose hardware.
Timezone Options for DHCP (Internet RFC 4833) specifies a DHCP option for a server to configure a client's time zone and daylight saving settings automatically.
Astronomical Times explains more abstruse astronomical time scales like TDT, TCG, and TDB. Time Scales goes into more detail, particularly for historical variants.
The IAU's SOFA collection contains C and Fortran code for converting among time scales like TAI, TDB, TDT and UTC.
Mars24 Sunclock – Time on Mars describes Airy Mean Time (AMT) and the diverse local time scales used by each landed mission on Mars.
LeapSecond.com is dedicated not only to leap seconds but to precise time and frequency in general. It covers the state of the art in amateur timekeeping, and how the art has progressed over the past few decades.
IERS Bulletins contains official publications of the International Earth Rotation and Reference Systems Service, which decides when leap seconds occur. The tz code and data support leap seconds via an optional "right" configuration, as opposed to the default "posix" configuration.
Leap Smear discusses how to gradually adjust POSIX clocks near a leap second so that they disagree with UTC by at most a half second, even though every POSIX minute has exactly sixty seconds. This approach works with the default tz "posix" configuration, is supported by the NTP reference implementation, and is used by major cloud service providers.
The Leap Second Discussion List covers McCarthy and Klepczynski's 1999 proposal to discontinue leap seconds, discussed further in The leap second: its history and possible future. UTC might be redefined without Leap Seconds gives pointers on this contentious issue, which was active until 2015 and could become active again.

Time notation

The Unicode Common Locale Data Repository (CLDR) Project has localizations for time zone names, abbreviations, identifiers, and formats. For example, it contains French translations for "Eastern European Summer Time", "EEST", and "Bucharest". Its by-type charts show these values for many locales. Data values are available in both LDML (an XML format) and JSON.
A summary of the international standard date and time notation is a good summary of ISO 8601:2004 – Data elements and interchange formats – Information interchange – Representation of dates and times.
XML Schema: Datatypes – dateTime specifies a format inspired by ISO 8601 that is in common use in XML data.
§3.3 of Internet Message Format (Internet RFC 5322) specifies the time notation used in email and HTTP headers.
Date and Time on the Internet: Timestamps (Internet RFC 3339) specifies an ISO 8601 profile for use in new Internet protocols.
Date & Time Formats on the Web surveys web- and Internet-oriented date and time formats.
Alphabetic time zone abbreviations should not be used as unique identifiers for UT offsets as they are ambiguous in practice. For example, in English-speaking North America "CST" denotes 6 hours behind UT, but in China it denotes 8 hours ahead of UT, and French-speaking North Americans prefer "HNC" to "CST". The tz database contains English abbreviations for many timestamps; unfortunately some of these abbreviations were merely the database maintainers' inventions, and these have been removed when possible.
Numeric time zone abbreviations typically count hours east of UT, e.g., +09 for Japan and −10 for Hawaii. However, the POSIX TZ environment variable uses the opposite convention. For example, one might use TZ="JST-9" and TZ="HST10" for Japan and Hawaii, respectively. If the tz database is available, it is usually better to use settings like TZ="Asia/Tokyo" and TZ="Pacific/Honolulu" instead, as this should avoid confusion, handle old timestamps better, and insulate you better from any future changes to the rules. One should never set POSIX TZ to a value like "GMT-9", though, since this would incorrectly imply that local time is nine hours ahead of UT and the time zone is called "GMT".

Artist	Karrin Allyson
CD	I Didn't Know About You
Copyright Date	1993
Label	Concord Jazz, Inc.
ID	CCD-4543
Track Time	3:44
Personnel	Karrin Allyson, vocal; Russ Long, piano; Gerald Spaits, bass; Todd Strait, drums
Notes	CD notes "additional lyric by Karrin Allyson; arranged by Russ Long and Karrin Allyson"
ADO Rating	1 star
AMG Rating	4 stars
Penguin Rating	3.5 stars

Artist	Kevin Mahogany
CD	Double Rainbow
Copyright Date	1993
Label	Enja Records
ID	ENJ-7097 2
Track Time	6:27
Personnel	Kevin Mahogany, vocal; Kenny Barron, piano; Ray Drummond, bass; Ralph Moore, tenor saxophone; Lewis Nash, drums
ADO Rating	1.5 stars
AMG Rating	3 stars
Penguin Rating	3 stars

Artist	Joe Williams
CD	Here's to Life
Copyright Date	1994
Label	Telarc International Corporation
ID	CD-83357
Track Time	3:58
Personnel	Joe Williams, vocal The Robert Farnon [39 piece] Orchestra
Notes	This CD is also available as part of a 3-CD package from Telarc, "Triple Play" (CD-83461)
ADO Rating	black dot
AMG Rating	2 stars
Penguin Rating	3 stars

Artist	Charles Fambrough
CD	Keeper of the Spirit
Copyright Date	1995
Label	AudioQuest Music
ID	AQ-CD1033
Track Time	7:07
Personnel	Charles Fambrough, bass; Joel Levine, tenor recorder; Edward Simon, piano; Lenny White, drums; Marion Simon, percussion
ADO Rating	2 stars
AMG Rating	unrated
Penguin Rating	3 stars

Artist	Holly Cole Trio
CD	Blame It On My Youth
Copyright Date	1992
Label	Manhattan
ID	CDP 7 97349 2
Total Time	37:45
Personnel	Holly Cole, voice; Aaron Davis, piano; David Piltch, string bass
Notes	Lyrical reference to "Eastern Standard Time" in Tom Waits' "Purple Avenue"
ADO Rating	2.5 stars
AMG Rating	3 stars
Penguin Rating	unrated

Artist	Milt Hinton
CD	Old Man Time
Copyright Date	1990
Label	Chiaroscuro
ID	CR(D) 310
Total Time	149:38 (two CDs)
Personnel	Milt Hinton, bass; Doc Cheatham, Dizzy Gillespie, Clark Terry, trumpet; Al Grey, trombone; Eddie Barefield, Joe Camel (Flip Phillips), Buddy Tate, clarinet and saxophone; John Bunch, Red Richards, Norman Simmons, Derek Smith, Ralph Sutton, piano; Danny Barker, Al Casey, guitar; Gus Johnson, Gerryck King, Bob Rosengarden, Jackie Williams, drums; Lionel Hampton, vibraphone; Cab Calloway, Joe Williams, vocal; Buck Clayton, arrangements
Notes	tunes include Old Man Time, Time After Time, Sometimes I'm Happy, A Hot Time in the Old Town Tonight, Four or Five Times, Now's the Time, Time on My Hands, This Time It's Us, and Good Time Charlie. Album info is available.
ADO Rating	3 stars
AMG Rating	4.5 stars
Penguin Rating	3 stars

Artist	Alan Broadbent
CD	Pacific Standard Time
Copyright Date	1995
Label	Concord Jazz, Inc.
ID	CCD-4664
Total Time	62:42
Personnel	Alan Broadbent, piano; Putter Smith, Bass; Frank Gibson, Jr., drums
Notes	The CD cover features an analemma for equation-of-time fans
ADO Rating	1 star
AMG Rating	4 stars
Penguin Rating	3.5 stars

Artist	Anthony Braxton/Richard Teitelbaum
CD	Silence/Time Zones
Copyright Date	1996
Label	Black Lion
ID	BLCD 760221
Total Time	72:58
Personnel	Anthony Braxton, sopranino and alto saxophones, contrebasse clarinet, miscellaneous instruments; Leo Smith, trumpet and miscellaneous instruments; Leroy Jenkins, violin and miscellaneous instruments; Richard Teitelbaum, modular moog and micromoog synthesizer
ADO Rating	black dot
AMG Rating	4 stars

Artist	Charles Gayle
CD	Time Zones
Copyright Date	2006
Label	Tompkins Square
ID	TSQ2839
Total Time	49:06
Personnel	Charles Gayle, piano
ADO Rating	1 star
AMG Rating	4.5 stars

Artist	The Get Up Kids
CD	Eudora
Copyright Date	2001
Label	Vagrant
ID	357
Total Time	65:12
Notes	Includes the song "Central Standard Time." Thanks to Colin Bowern for this information.
AMG Rating	2.5 stars

Artist	Coldplay
Song	Clocks
Copyright Date	2003
Label	Capitol Records
ID	52608
Total Time	4:13
Notes	Won the 2004 Record of the Year honor at the Grammy Awards. Co-written and performed by Chris Martin, great-great-grandson of DST inventor William Willett. The song's first line is "Lights go out and I can't be saved".

Artist	Jaime Guevara
Song	Qué hora es
Date	1993
Total Time	3:04
Notes	The song protested "Sixto Hour" in Ecuador (1992–3). Its lyrics include "Amanecía en mitad de la noche, los guaguas iban a clase sin sol" ("It was dawning in the middle of the night, the buses went to class without sun").

Artist	Irving Kahal and Harry Richman
Song	There Ought to be a Moonlight Saving Time
Copyright Date	1931
Notes	This musical standard was a No. 1 hit for Guy Lombardo in 1931, and was also performed by Maurice Chevalier, Blossom Dearie and many others. The phrase "Moonlight saving time" also appears in the 1995 country song "Not Enough Hours in the Night" written by Aaron Barker, Kim Williams and Rob Harbin and performed by Doug Supernaw.

Artist	The Microscopic Septet
CD	Lobster Leaps In
Copyright Date	2008
Label	Cuneiform
ID	272
Total Time	73:05
Notes	Includes the song "Twilight Time Zone."
AMG Rating	3.5 stars
ADO Rating	2 stars

Artist	Bob Dylan
CD	The Times They Are a-Changin'
Copyright Date	1964
Label	Columbia
ID	CK-8905
Total Time	45:36
AMG Rating	4.5 stars
ADO Rating	1.5 stars
Notes	The title song is also available on "Bob Dylan's Greatest Hits" and "The Essential Bob Dylan."

Artist	Luciana Souza
CD	Tide
Copyright Date	2009
Label	Universal Jazz France
ID	B0012688-02
Total Time	42:31
AMG Rating	3.5 stars
ADO Rating	2.5 stars
Notes	Includes the song "Fire and Wood" with the lyric "The clocks were turned back you remember/Think it's still November."

Artist	Ken Nordine
CD	You're Getting Better: The Word Jazz Dot Masters
Copyright Date	2005
Label	Geffen
ID	B0005171-02
Total Time	156:22
ADO Rating	1 star
AMG Rating	4.5 stars
Notes	Includes the piece "What Time Is It" ("He knew what time it was everywhere...that counted").

Time and the Arts

Documentaries

Movies

TV episodes

Books, plays, and magazines

Music

Comics

Jokes

See also

Theory and pragmatics of the tz code and data