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.
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
is used by several implementations,
C Library (used in
Oracle Database, and
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.
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
environment variable to the location's full name,
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.
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
tz database hosted by the
Time Zone Database website
of the Internet Assigned Numbers
Older releases are in files named
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 1999g, each release has been distributed in
ustar interchange format, compressed as described above;
older releases use a nearly-compatible format.
Since version 2016h, each release has contained a text file named
"version" whose first (and currently only) line is the version.
Older releases are archived,
and are also available in an
FTP directory via a
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)
specified by Internet
The code also lets
you read a TZif file and interpret timestamps for that
tz code and data
are by no means authoritative. If you find errors, please
send changes to
the time zone mailing list. You can also subscribe to it
and browse the archive of old
Metadata for mailing list
discussions and corresponding data changes can be
If your government plans to change its time zone boundaries or
daylight saving rules, inform
firstname.lastname@example.org well in
advance, as this will coordinate updates to many cell phones,
computers, and other devices around the world.
The change should be officially announced at least a year before it affects
how clocks operate; otherwise, there is a good chance that some
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.
tz data can represent planned changes
far into the future, and a long-planned change can easily be reverted
or otherwise altered with a year's notice before the change would have
Changes to the
tz code and data are often
propagated to clients via operating system updates, so
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
tz data, you can often short-circuit
the process by tailoring the generic instructions in
tz README file and installing the latest
data yourself. System-specific instructions for installing the
tz data have also been published
Noda Time, and OpenJDK/Oracle JDK.
Sources for the
tz database are
with lines terminated by LF,
which can be modified by common text editors such
as GNU Emacs,
Specialized source-file editing can be done via the
zoneinfo package for Sublime Text and the VSCode
zoneinfo extension for Visual
For further information about updates, please see
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
These are listed roughly in ascending order of complexity and fanciness.
tzdb-derived data in CSV and in SQL form.
Although some of these do not fully support
tz data, in recent
distributions you can generally work around compatibility problems by
running the command
make rearguard_tarballs and compiling
from the resulting tarballs instead.
tzsource into iCalendar-compatible VTIMEZONE files. Vzic is freely available under the GNU General Public License (GPL).
tzsource 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_zdumpthat generates test cases for each clock transition in the
tzsource and from CLDR data (mentioned below) into an ICU-specific format. ICU is freely available under a BSD-style license.
tzsource and exposes APIs for use. It is freely available under the MIT license.
tzsource into the format used by OpenJDK and Oracle JDK. Although its source code is proprietary, its executable is available under the Java SE Timezone Updater License Agreement.
tzsource 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.
tzsource into a binary format. Time4A is available under the Apache License and Time4J is available under the GNU Lesser General Public License (LGPL).
tznatively via the timeZone option of Intl.DateTimeFormat. This can be used as-is or with most of the following libraries, many of which also support runtimes lacking the timeZone option.
tzdbupdates, astronomical and atomic time, a command-line interface, and full TypeScript. Its companion @tubular/time-tzdb can generate TZif and other files, and a companion website Timezone Database Explorer lets you convert timestamps, view transition histories, and download code and data. It is freely available under the MIT license.
tzsource into Julia. It is freely available under the MIT license.
tzsource into Object Pascal as compiled by Delphi and FPC. It is freely available under a BSD-style license.
tzsource into Python. It is freely available under a BSD-style license. In code that can assume Python 3.9 or later it is superseded by
tzsource into Ruby. It is freely available under the MIT license.
tzsource into a time zone repository whose format is either proprietary or an XML-encoded representation.
tzsource into text files, along with a runtime that can read those files. Tcl is freely available under a BSD-style license.
GTimeZoneobject representing sets of UT offsets. It is freely available under the LGPL.
baltzo::TimeZoneUtilcomponent contains a C++ implementation of a TZif file reader. It is freely available under the Apache License.
zoneinfo.ZoneInfoclass that reads TZif data and creates objects that represent
tzdbtimezones. Python is freely available under the Python Software Foundation License. A companion PyPI module
tzdatasupplies TZif data if the underlying system data cannot be found; it is freely available under the Apache License.
tz-based time zone software
tzdatabase in a Go-specific format.
tzdata and CLDR data (mentioned below) used by the Windows Runtime / Universal Windows Platform classes
Calendar. Exploring Windows Time Zones with
System.TimeZoneInfodescribes 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
tznames. These mappings can be performed programmatically via the TimeZoneConverter .NET library, or the ICU Java and C++ libraries mentioned above.
tzdatabase in a Java-specific format.
tzdata, 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.
Geographical boundaries between timezones are available from several Internet geolocation services and other sources.
tzdbtimezones. 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.
Various sources argue for and against daylight saving time and time zone shifts, and many scientific studies have been conducted. This section summarizes reviews and position statements based on scientific literature in the area.
tzcode and data support leap seconds via an optional "
right" configuration where a computer's internal
time_tinteger clock counts every TAI second, as opposed to the default "
posix" configuration where the internal clock ignores leap seconds. The two configurations agree for timestamps starting with 1972-01-01 00:00:00 UTC (
time_t63 072 000) and diverge for timestamps starting with
time_t78 796 800, which corresponds to the first leap second 1972-06-30 23:59:60 UTC in the "
right" configuration, and to 1972-07-01 00:00:00 UTC in the "
posix" configuration. In practice the two configurations also agree for timestamps before 1972 even though the historical situation is messy, partly because neither UTC nor TAI is well-defined for sufficiently-old timestamps.
posix" configuration, is supported by the NTP reference implementation, and is used by major cloud service providers. However, according to §3.7.1 of Network Time Protocol Best Current Practices (Internet RFC 8633), leap smearing is not suitable for applications requiring accurate UTC or civil time, and is intended for use only in single, well-controlled environments.
tzdatabase contains English abbreviations for many timestamps; unfortunately some of these abbreviations were merely the database maintainers' inventions, and these have been removed when possible.
TZenvironment variable uses the opposite convention. For example, one might use
TZ="HST10"for Japan and Hawaii, respectively. If the
tzdatabase is available, it is usually better to use settings like
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
TZto 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".