tz code and datatz database
The tz
database attempts to record the history and predicted future of
civil time scales.
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).
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.
Most timezones correspond to a notable location and the database
records all known clock transitions for that location;
some timezones correspond instead to a fixed UTC offset.
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 (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 location-based timezones,
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
POSIX.1-2024
(The Open Group Base Specifications Issue 8, IEEE Std 1003.1-2024).
Unlike its predecessors
POSIX.1-1988 through
POSIX.1-2017,
POSIX.1-2024 requires support for the
tz database, which has a
model for describing civil time that is more complex than the
standard and daylight saving times required by earlier POSIX editions.
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.
Each timezone has a name that uniquely identifies the timezone.
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
“Czech Republic” instead of the timezone name “Europe/Prague”.
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.
Unicode’s Common Locale Data
Repository (CLDR)
contains data that may be useful for other selection
interfaces; it maps timezone names like Europe/Prague to
locale-dependent strings like “Prague”, “Praha”, “Прага”, and “布拉格”.
The naming conventions attempt to strike a balance among the following goals:
Names normally have the format
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:
/").
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’s
proleptic TZ strings.
A file name component must not exceed 14 characters or start with
"-".
E.g., prefer America/Noronha to
America/Fernando_de_Noronha.
Exceptions: see the discussion of legacy names below.
//", or
start or end with "/".
Also, a name must not be "Etc/Unknown", as
CLDR uses that string for an unknown or invalid timezone.
/", as a regular file cannot have the
same name as a directory in POSIX.
For example, America/New_York precludes
America/New_York/Bronx.
Indian/Crozet
as a near-duplicate or alias of Asia/Dubai
merely because they are different countries or territories,
or their clocks disagreed before 1970, or the
Crozet Islands
are notable in their own right,
or the Crozet Islands are not adjacent to other locations
that use Asia/Dubai.
America/Costa_Rica to
America/San_Jose and America/Guyana
to America/Georgetown.
Europe/Paris to Europe/France,
since
France
has had multiple time zones.
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.
Asia/Shanghai to
Asia/Beijing.
Among locations with similar populations, pick the best-known
location, e.g., prefer Europe/Rome to
Europe/Milan.
Atlantic/Canary to
Atlantic/Canaries.
_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.
_" to represent a space.
." from abbreviations in names.
E.g., prefer Atlantic/St_Helena to
Atlantic/St._Helena.
Europe/Rome to
Europe/Milan merely because Milan’s population has grown
to be somewhat greater than Rome’s.
backward" file as a link to the new spelling.
This means old spellings will continue to work.
Ordinarily a name change should occur only in the rare case when
a location’s consensus English-language spelling changes; for example,
in 2008 Asia/Calcutta was renamed to Asia/Kolkata
due to long-time widespread use of the new city name instead of the old.
Guidelines have evolved with time, and names following old versions of these guidelines might not follow the current version. When guidelines have changed, old names continue to be supported. Guideline changes have included the following:
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").
etcetera".
Also, the file "backward" defines the legacy names
Etc/GMT0, Etc/GMT-0, Etc/GMT+0,
GMT0, GMT-0 and GMT+0,
and the file "northamerica" defines the legacy names
EST5EDT, CST6CDT,
MST7MDT, and PST8PDT.
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.
The backward-compatibility file zone.tab is similar
but conforms to the older-version guidelines related to ISO 3166-1;
it lists only one country code per entry and unlike zone1970.tab
it can list names defined in backward.
Applications that process only timestamps from now on can instead use the file
zonenow.tab, which partitions the world more coarsely,
into regions where clocks agree now and in the predicted future;
this file is smaller and simpler than zone1970.tab
and zone.tab.
The database defines each timezone name to be a zone, or a link to a zone.
The source file backward defines links for backward
compatibility; it does not define zones.
Although backward was originally designed to be optional,
nowadays distributions typically use it
and no great weight should be attached to whether a link
is defined in backward or in some other file.
The source file etcetera defines names that may be useful
on platforms that do not support proleptic TZ strings
like <+08>-8;
no other source file other than backward
contains links to its zones.
One of etcetera’s names is Etc/UTC,
used by functions like gmtime to obtain leap
second information on platforms that support leap seconds.
Another etcetera name, GMT,
is used by older code releases.
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:
+" 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
explicitly by a POSIX proleptic TZ string.
These abbreviations (for standard/daylight/etc. time) are: ACST/ACDT Australian Central, AST/ADT/APT/AWT/ADDT Atlantic, AEST/AEDT Australian Eastern, AHST/AHDT Alaska-Hawaii, AKST/AKDT Alaska, AWST/AWDT Australian Western, BST/BDT Bering, CAT/CAST Central Africa, CET/CEST/CEMT Central European, ChST Chamorro, CST/CDT/CWT/CPT Central [North America], CST/CDT China, GMT/BST/IST/BDST Greenwich, EAT East Africa, EST/EDT/EWT/EPT Eastern [North America], EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, HKT/HKST/HKWT 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 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 Pacific, PST/PDT Philippine, SAST South Africa, SST Samoa, UTC Universal, 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 Asunción, Athens; BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Brussels, Bucharest; CMT Calamarca, Caracas, Chisinau, Colón, 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, Kyiv, Kingston; LMT Lima, Lisbon, local; MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, Moscow; PLMT Phù Liễn; PMT Paramaribo, Paris, Perm, Pontianak, Prague; PMMT Port Moresby; PPMT Port-au-Prince; 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: BMT/BST for Bermuda 1890–1930, 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.
tz database”.
-05 and +0530 that are generated
by zic’s %z notation.
-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.
(The abbreviation Z that
Internet
RFC 9557 uses for this concept
would violate the POSIX requirement
of at least three characters in an abbreviation.)
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.
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:
tz database predicts future
timestamps, and current predictions
will be incorrect after future governments change the rules.
For example, if today someone schedules a meeting for 13:00 next
October 1, Casablanca time, and tomorrow Morocco changes its
daylight saving rules, software can mess up after the rule change
if it blithely relies on conversions made before the change.
tz database’s scope were extended to
cover even just the known or guessed history of standard time; for
example, the current single entry for France would need to split
into dozens of entries, perhaps hundreds.
And in most of the world even this approach would be misleading
due to widespread disagreement or indifference about what times
should be observed.
In her 2015 book
The
Global Transformation of Time, 1870–1950,
Vanessa Ogle writes
“Outside of Europe and North America there was no system of time
zones at all, often not even a stable landscape of mean times,
prior to the middle decades of the twentieth century”.
See: Timothy Shenk, Booked:
A Global History of Time. Dissent 2015-12-17.
tz database relies on
years of first-class work done by
Joseph Myers and others; see
“History of
legal time in Britain”.
Other countries are not done nearly as well.
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.
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.
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.
tz
database were often spread out over hours, days, or even decades.
tz database requires.
tz database cannot represent stopped clocks.
However, on 1911-03-11 at 00:00, some public-facing French clocks
were changed by stopping them for a few minutes to effect a transition.
The tz database models this via a
backward transition; the relevant French legislation does not
specify exactly how the transition was to occur.
tz code can handle.
For example, from 1880 to 1916 clocks in Ireland observed Dublin Mean
Time (estimated to be UT
−00:25:21.1); although the tz
source data can represent the .1 second, TZif files and the code cannot.
In practice these old specifications were rarely if ever
implemented to subsecond precision.
tz database are correct, the
tz rules that generate them may not
faithfully reflect the historical rules.
For example, from 1922 until World War II the UK moved clocks
forward the day following the third Saturday in April unless that
was Easter, in which case it moved clocks forward the previous
Sunday.
Because the tz database has no
way to specify Easter, these exceptional years are entered as
separate tz Rule lines, even though the
legal rules did not change.
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.
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.
tz database assumes Universal Time
(UT) as an origin, even though UT is not
standardized for older timestamps.
In the tz database commentary,
UT denotes a family of time standards that includes
Coordinated Universal Time (UTC) along with other
variants such as UT1 and GMT,
with days starting at midnight.
Although UT equals UTC for modern
timestamps, UTC was not defined until 1960, so
commentary uses the more general abbreviation UT for
timestamps that might predate 1960.
Since UT, UT1, etc. disagree slightly,
and since pre-1972 UTC seconds varied in length,
interpretation of older timestamps can be problematic when
subsecond accuracy is needed.
tz database does not represent how
uncertain its information is.
Ideally it would contain information about when data entries are
incomplete or dicey.
Partial temporal knowledge is a field of active research, though,
and it 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.
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.
In POSIX, time display in a process is controlled by the
environment variable TZ, which can have two forms:
TZ value
like CET-1CEST,M3.5.0,M10.5.0/3 uses a complex
notation that specifies a single standard time along with daylight
saving rules that apply to all years past, present, and future.
TZ value
like Europe/Berlin names a location that stands for
civil time near that location, which can have more than
one standard time and more than one set of daylight saving rules,
to record timekeeping practice more accurately.
These names are defined by the tz database.
Some platforms support only the features required by POSIX.1-2017 and earlier editions, and have not yet upgraded to POSIX.1-2024. Code intended to be portable to these platforms must deal with problems that were fixed in later POSIX editions.
TZ,
and there is 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.
The proleptic TZ string,
which is all that POSIX.1-2017 requires,
has a format that is hard to describe and is error-prone in practice.
Also, proleptic TZ strings cannot deal with daylight
saving time rules not based on the Gregorian calendar (as in
Morocco), or with situations where more than two time zone
abbreviations or UT offsets are used in an area.
A proleptic TZ string has the following format:
stdoffset[dst[offset][,date[/time],date[/time]]]
where:
<+09>;
this allows "+" and "-" in the names.
[±]hh:[mm[:ss]]
and specifies the offset west of UT.
hh may be a single digit;
0≤hh≤24.
The default DST offset is one hour ahead of
standard time.
/time],date[/time]:[mm[:ss]]
and defaults to 02:00.
This is the same format as the offset, except that a
leading "+" or "-" is not allowed.
Mm.n.d
(0[Sunday]≤d≤6[Saturday], 1≤n≤5,
1≤m≤12)5" stands for the last week in which
day d appears (which may be either the 4th or
5th week).
Typically, this is the only useful form; the n
and Jn forms are rarely used.
Here is an example proleptic 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 proleptic TZ string is hard to remember, and
mishandles some timestamps before 2008.
With this package you can use a geographical TZ instead:
TZ='Pacific/Auckland'POSIX.1-2017 also has the limitations of POSIX.1-2024, discussed in the next section.
POSIX.1-2024 extends POSIX.1-2017 in the following significant ways:
TZ.
Earlier POSIX editions require support only for proleptic TZ.
struct tm
to have a UT offset member tm_gmtoff
and a time zone abbreviation member tm_zone.
Earlier POSIX editions lack this requirement.
"<-02>2<-01>,M3.5.0/-1,M10.5.0/0"
where the transition time −1:00 means 23:00 the previous day.
However POSIX.1-2024, like earlier POSIX editions, has some limitations:
TZ environment variable is process-global, which
makes it hard to write efficient, thread-safe applications that
need access to multiple timezones.
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.
time_t clock counts exclude leap
seconds.
TZ='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
time conversion package, and when
US time conversion rules changed (as in the United
States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated
to ensure proper results.
tz code
The tz code defines some properties
left unspecified by POSIX, and attempts to support some
extensions to POSIX.
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.
If the TZ environment variable uses the geographical format,
it is used in generating
the name of a file from which time-related information is read.
The file’s format is TZif,
a timezone information format that contains binary data; see
Internet
RFC 9636.
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.
When the tz code was developed in the 1980s,
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 format) 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 settings such as TZ='EST5EDT' which
can be used by new programs as well as by old programs that
assume pre-POSIX TZ values.
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.
time_t values are supported, on systems
where time_t is signed.
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:
tzname variable does not suffice and is no
longer needed.
It is planned to be removed in a future edition of POSIX.
To get a timestamp’s time zone abbreviation, consult
the tm_zone member if available; otherwise,
use strftime’s "%Z" conversion
specification.
daylight and timezone
variables do not suffice and are no longer needed.
They are planned to be removed in a future edition of POSIX.
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.
tm_isdst member is almost never needed and most of
its uses should be discouraged in favor of the abovementioned
APIs.
It was intended as an index into the tzname variable,
but as mentioned previously that usage is obsolete.
Although it can still be used in arguments to
mktime to disambiguate timestamps near
a DST transition when the clock jumps back on
platforms lacking tm_gmtoff, this
disambiguation works only for proleptic TZ strings;
it does not work in general for geographical timezones,
such as when a location changes to a time zone with a
lesser UT offset.
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
use strftime with a %Z conversion specification
to learn the correct time
zone abbreviation to use.
gettimeofday function is not
used in this package.
This formerly let users obtain the current UTC offset
and DST flag, but this functionality was removed in
later versions of BSD.
time_t values when doing conversions
for places that 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.
STD_INSPIRED is nonzero should, at this point, be
looked on primarily as food for thought.
They are not in any sense “standard compatible” – some are
not, in fact, specified in any standard.
They do, however, represent responses of various authors to
standardization proposals.
The tz code and data supply the following interfaces:
tzselect, zdump,
and zic, documented in their man pages.
zic input files, documented in
the zic man page.
zic output files, documented in
the tzfile man page.
zone1970.tab.
iso3166.tab.
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.
Timezone boundaries are not part of the stable interface. For example, even though the Asia/Bangkok timezone currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part of the stable interface and the timezone can split at any time. If a calendar application records a future event in some location other than Bangkok by putting Asia/Bangkok in the event’s record, the application should be robust in the presence of timezone splits between now and the future time.
Leap seconds were introduced in 1972 to accommodate the difference between atomic time and the less regular rotation of the earth. Unfortunately they have caused so many problems with civil timekeeping that there are plans to discontinue them by 2035. Even if these plans come to fruition, a record of leap seconds will still be needed to resolve timestamps from 1972 through 2035, and there may also be a need to record whatever mechanism replaces them.
The tz code and data can account for leap seconds,
thanks to code contributed by Bradley White.
However, the leap second support of this package is rarely used directly
because POSIX requires leap seconds to be excluded and many
software packages would mishandle leap seconds if they were present.
Instead, leap seconds are more commonly handled by occasionally adjusting
the operating system kernel clock as described in
Precision timekeeping,
and this package by default installs a leapseconds file
commonly used by
NTP
software that adjusts the kernel clock.
However, kernel-clock twiddling approximates UTC only roughly,
and systems needing more precise UTC can use this package’s leap
second support directly.
The directly supported mechanism assumes that time_t
counts of seconds since the POSIX epoch normally include leap seconds,
as opposed to POSIX time_t counts which exclude leap seconds.
This modified timescale is converted to UTC
at the same point that time zone and DST
adjustments are applied –
namely, at calls to localtime and analogous functions –
and the process is driven by leap second information
stored in alternate versions of the TZif files.
Because a leap second adjustment may be needed even
if no time zone correction is desired,
calls to gmtime-like functions
also need to consult a TZif file,
conventionally named Etc/UTC
(GMT in previous versions),
to see whether leap second corrections are needed.
To convert an application’s time_t timestamps to or from
POSIX time_t timestamps (for use when, say,
embedding or interpreting timestamps in portable
tar
files),
the application can call the utility functions
time2posix and posix2time
included with this package.
If the POSIX-compatible TZif file set is installed
in a directory whose basename is zoneinfo, the
leap-second-aware file set is by default installed in a separate
directory zoneinfo-leaps.
Although each process can have its own time zone by setting
its TZ environment variable, there is no support for some
processes being leap-second aware while other processes are
POSIX-compatible; the leap-second choice is system-wide.
So if you configure your kernel to count leap seconds, you should also
discard zoneinfo and rename zoneinfo-leaps
to zoneinfo.
Alternatively, you can install just one set of TZif files
in the first place; see the REDO variable in this package’s
makefile.
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.
The European Space Agency is considering the establishment of a reference timescale for the Moon, which has days roughly equivalent to 29.5 Earth days, and where relativistic effects cause clocks to tick slightly faster than on Earth. Also, NASA has been ordered to consider the establishment of Coordinated Lunar Time (LTC). It is not yet known whether the US and European efforts will result in multiple timescales on the Moon.
Some people’s work schedules have used Mars time. Jet Propulsion Laboratory (JPL) coordinators kept Mars time on and off during the Mars Pathfinder mission (1997). 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 (MER) mission (2004–2018). These timepieces looked like normal Seikos and Citizens but were adjusted to use Mars seconds rather than terrestrial seconds, although unfortunately the adjusted watches were unreliable and appear to have had only limited use.
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. (One MER worker noted, “If I am working Mars hours, and Mars hours are 2.5% more than Earth hours, shouldn’t I get an extra 2.5% pay raise?”)
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 MER mission 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. The A and B zones differ enough so that an MER worker assigned to the A zone might suffer “Mars lag” when switching to work in the B zone. 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:
Europe/Prague".
d127 1
a127 1
Unicode's Common Locale Data
d131 1
a131 1
locale-dependent strings like "Prague", "Praha", "Прага", and "布拉格".
d146 1
a146 1
Indicate to experts where the timezone's clocks typically are.
d152 1
a152 1
Swaziland→Eswatini) or when locations change countries (e.g., Hong
d170 3
a172 3
North and South America share the same area, 'America'.
Typical names are 'Africa/Cairo',
'America/New_York', and 'Pacific/Honolulu'.
d174 1
a174 1
'America/Indiana/Petersburg' distinguishes Petersburg,
d187 3
a189 3
names other than '/').
Do not use the file name components '.' and
'..'.
d192 1
a192 1
'.', '-' and '_'.
d194 2
a195 2
href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX's proleptic
TZ strings.
d197 1
a197 1
'-'.
d203 3
a205 3
A name must not be empty, or contain '//', or
start or end with '/'.
Also, a name must not be 'Etc/Unknown', as
d217 1
a217 1
start with '/', as a regular file cannot have the
d284 2
a285 2
Omit common suffixes like '_Islands' and
'_City', unless that would lead to ambiguity.
d296 1
a296 1
Use '_' to represent a space.
d299 1
a299 1
Omit '.' from abbreviations in names.
d307 2
a308 2
Europe/Milan merely because Milan's population has grown
to be somewhat greater than Rome's.
d312 1
a312 1
'backward' file as a link to the new spelling.
d315 1
a315 1
a location's consensus English-language spelling changes; for example,
d331 2
a332 2
See the file 'backward' for most of these older names
(e.g., 'US/Eastern' instead of 'America/New_York').
d334 2
a335 2
'WET', 'CET', 'MET', and
'EET' (see the file 'europe').
d343 7
a349 7
'etcetera'.
Also, the file 'backward' defines the legacy names
'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0',
'GMT0', 'GMT-0' and 'GMT+0',
and the file 'northamerica' defines the legacy names
'EST5EDT', 'CST6CDT',
'MST7MDT', and 'PST8PDT'.
d369 1
a369 1
Although a zone1970.tab location's
d373 1
a373 1
time (LMT) offset with one hour for every 15°
d399 1
a399 1
One of etcetera's names is Etc/UTC,
d411 1
a411 1
like 'EST' to be compatible with human tradition and POSIX.
d419 1
a419 1
'+' or '-'.
d421 1
a421 1
space and '?', but these characters have a
d425 2
a426 2
'set
`date`'
d431 3
a433 4
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
d435 2
a436 2
In practice ASCII alphanumerics and '+' and
'-' are safe in all locales.
d448 1
a448 1
e.g., 'EST' for Eastern Standard Time in North America.
d451 1
a451 1
a French application might translate 'EST' to 'HNE'.
d486 1
a486 1
NZST/NZDT New Zealand 1946–present,
d503 1
a503 1
For times taken from a city's longitude, use the
d505 1
a505 1
The only abbreviation like this in current use is 'GMT'.
d508 1
a508 1
Typically, numeric abbreviations (e.g., '-004430' for
d549 1
a549 1
BMT/BST for Bermuda 1890–1930,
d551 1
a551 1
1890–1932,
d553 3
a555 3
1880–1916,
MMT/MST/MDST for Moscow 1880–1919, and
RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926.
d560 3
a562 3
Use 'LMT' for local mean time of locations before the
introduction of standard time; see "Scope of the
tz database".
d567 1
a567 1
by zic's %z notation.
d572 4
a575 4
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
d577 1
a577 1
the need for determining when 'CET' supplanted 'MEZ' in common
d581 1
a581 1
Use a consistent style in a timezone's history.
d589 1
a589 1
(UT) (with time zone abbreviation '-00') for
d591 1
a591 1
The leading '-' is a flag that the UT offset is in
d595 1
a595 1
(The abbreviation 'Z' that
d605 2
a606 2
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
d609 1
a609 1
'-0600' instead of time zone abbreviations like 'CST'.
d620 1
a620 1
bodies and the references cited in the database's comments.
d642 1
a642 1
the tz database's scope were extended to
d652 1
a652 1
Global Transformation of Time, 1870–1950,
d654 1
a654 1
"Outside of Europe and North America there was no system of time
d656 1
a656 1
prior to the middle decades of the twentieth century".
d674 2
a675 2
"History of
legal time in Britain".
d700 1
a700 1
have London's exact meridian, and its 1847 transition
d706 1
a706 1
earliest time for which a timezone's
d717 1
a717 1
region's boundaries, and in many cases the boundaries are not known.
d750 1
a750 1
−00:25:21.1); although the tz
d790 1
a790 1
relatively minor, such as Japanese bars giving times like "24:30" for the
d828 1
a828 1
earth's
d834 4
a837 4
See: Stephenson FR, Morrison LV, Hohenkerk CY.
Measurement of
the Earth's rotation: 720 BC to AD 2015.
Proc Royal Soc A. 2016;472:20160404.
d846 1
a846 1
This affects time stamps during the leap second era (1972–2035).
d865 1
a865 1
database's pre-1970 and future timestamps are either wrong or
d870 1
a870 1
In particular, the tz database's
d889 1
a889 1
system zic, since the format of zic's
d917 2
a918 1
Some platforms support only the features required by POSIX.1-2017,
d960 1
a960 1
may also be in a quoted form like '<+09>';
d965 1
a965 1
'[±]hh:[mm[:ss]]'
d967 1
a967 1
'hh' may be a single digit;
d980 1
a980 1
'hh:[mm[:ss]]'
d983 1
a983 1
leading '+' or '-' is not allowed.
d1000 1
a1000 1
'5' stands for the last week in which
d1015 2
a1016 2
(NZDT) is observed from September's last Sunday at
02:00 until April's first Sunday at 03:00:
d1052 1
a1052 1
DST transition times can range from −167:59:59
d1056 1
a1056 1
where the transition time −1:00 means 23:00 the previous day.
d1069 1
a1069 1
system's best idea of local (wall clock) time.
d1071 1
a1071 1
used only at certain times – without regard to whether the
d1074 1
a1074 1
While an administrator can "do everything in UT" to
d1076 1
a1076 1
handling daylight saving time shifts – as might be required to
d1085 1
a1085 2
for TZ values like
"EST5EDT".
d1127 1
a1127 1
The file's format is TZif,
d1141 2
a1142 2
variable to take on values such as 'America/New_York'
might cause "old" programs (that expect TZ to have a
d1145 1
a1145 1
to hold the string used to generate the TZif file's name.
d1150 3
a1152 3
"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
d1195 1
a1195 1
To get a timestamp's time zone abbreviation, consult
d1197 1
a1197 1
use strftime's "%Z" conversion
d1204 1
a1204 1
To get a timestamp's UT offset, consult
d1208 1
a1208 1
or use strftime's "%z" conversion
d1233 3
a1235 3
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
d1265 1
a1265 1
They are not in any sense "standard compatible" – some are
d1296 1
a1296 1
"Timezone identifiers" above.
d1299 2
a1300 2
Library functions described in "Time and date
functions" above.
d1322 1
a1322 1
the text file 'version' in each release.
d1350 1
a1350 1
than Bangkok by putting "Asia/Bangkok" in the event's record,
d1384 1
a1384 1
and systems needing more precise UTC can use this package's leap
d1394 2
a1395 2
adjustments are applied –
namely, at calls to localtime and analogous functions –
d1405 1
a1405 1
To convert an application's time_t timestamps to or from
d1428 1
a1428 1
in the first place; see the REDO variable in this package's
d1443 1
a1443 1
Other information and sources are given in the file 'calendars'
d1453 1
a1453 1
href='https://www.esa.int/Applications/Navigation/Telling_time_on_the_Moon'>considering
d1459 1
a1459 1
href='https://www.whitehouse.gov/wp-content/uploads/2024/04/Celestial-Time-Standardization-Policy.pdf'>ordered
d1466 1
a1466 1
Some people's work schedules have used
d1476 1
a1476 1
Exploration Rovers (MER) mission (2004–2018).
d1484 1
a1484 1
A Mars solar day is called a "sol" and has a mean period equal to
d1488 2
a1489 2
(One MER worker noted, "If I am working Mars hours, and Mars hours are
2.5% more than Earth hours, shouldn't I get an extra 2.5% pay raise?")
d1497 1
a1497 1
defines Earth's prime meridian.
d1505 2
a1506 2
For example, the MER mission defined two time zones "Local
Solar Time A" and "Local Solar Time B" for its two missions, each zone
d1510 2
a1511 2
the A zone might suffer "Mars lag" when switching to work in the B zone.
Such a "time zone" is not particularly suited for any application
d1525 1
a1525 1
like Earth's.
d1528 1
a1528 1
For example, although Mercury's
d1531 1
a1531 1
Sun so rapidly that an observer on Mercury's equator would see a
d1557 2
a1558 2
"Technical
Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"
d1568 3
a1570 3
"Workdays
Fit for a Martian", Los Angeles Times
(2004-01-14), pp A1, A20–A21.
d1574 2
a1575 2
"Jet
Lag Is Worse on Mars", The Atlantic (2015-02-26)
d1579 2
a1580 2
"How
long is a day on the other planets of the solar system?"
d1587 8
a1594 3
tzname[localtime(&clock)->tm_isdst]
(if HAVE_TZNAME is nonzero) to learn the correct time
@
1.19
log
@Sync with tzcode2024a:
Release 2024a - 2024-02-01 09:28:56 -0800
Changes to code
The FROM and TO columns of Rule lines can no longer be "minimum"
or an abbreviation of "minimum", because TZif files do not support
DST rules that extend into the indefinite past - although these
rules were supported when TZif files had only 32-bit data, this
stopped working when 64-bit TZif files were introduced in 1995.
This should not be a problem for realistic data, since DST was
first used in the 20th century. As a transition aid, FROM columns
like "minimum" are now diagnosed and then treated as if they were
the year 1900; this should suffice for TZif files on old systems
with only 32-bit time_t, and it is more compatible with bugs in
2023c-and-earlier localtime.c. (Problem reported by Yoshito
Umaoka.)
localtime and related functions no longer mishandle some
timestamps that occur about 400 years after a switch to a time
zone with a DST schedule. In 2023d data this problem was visible
for some timestamps in November 2422, November 2822, etc. in
America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.)
strftime %s now uses tm_gmtoff if available. (Problem and draft
patch reported by Dag-Erling Smørgrav.)
Changes to build procedure
The leap-seconds.list file is now copied from the IERS instead of
from its downstream counterpart at NIST, as the IERS version is
now in the public domain too and tends to be more up-to-date.
(Thanks to Martin Burnicki for liaisoning with the IERS.)
Changes to documentation
The strftime man page documents which struct tm members affect
which conversion specs, and that tzset is called. (Problems
reported by Robert Elz and Steve Summit.)
@
text
@d92 3
a94 1
As of this writing, the current edition of POSIX is: POSIX.1-2017
d383 2
a384 1
on platforms that do not support POSIX.1-2017-style TZ strings;
d431 2
a432 2
This guarantees that all abbreviations could have been specified by a
POSIX.1-2017 TZ string.
d584 5
d786 1
a786 1
such as that required by POSIX.1-2017.
d877 2
a878 2
'zic' supplied with this package instead of using the
system 'zic', since the format of zic's
d883 4
a886 1
TZ.
Unfortunately, the POSIX.1-2017
TZ string takes a form that is hard to describe and
is error-prone in practice.
Also, POSIX.1-2017 TZ strings cannot deal with daylight
d932 1
a932 1
The POSIX.1-2017 TZ string takes the following form:
d999 1
a999 1
Here is an example POSIX.1-2017 TZ string for New
d1010 1
a1010 1
This POSIX.1-2017 TZ string is hard to remember, and
d1012 1
a1012 1
With this package you can use this instead:
d1017 22
d1040 5
a1044 11
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
time conversion package, and when
US time conversion rules changed (as in the United
States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated
to ensure proper results.
d1046 4
d1068 2
a1069 4
POSIX.1-2017 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.
d1072 11
a1082 2
POSIX requires that time_t clock counts exclude leap
seconds.
d1084 11
d1108 1
a1108 1
and POSIX.1-2013 and the tz code both
a1110 5
tz codeTZ environment variable is used in generating
the name of a file from which time-related information is read
(or is interpreted à la POSIX.1-2017); TZ is no longer
constrained to be a string containing abbreviations
and numeric data as described above.
d1128 2
a1129 1
It was recognized that allowing the TZ environment
d1132 1
a1132 1
certain form) to operate incorrectly; consideration was given to using
a1145 9
The code supports platforms with a UT offset member
in struct tm, e.g., tm_gmtoff,
or with a time zone abbreviation member in
struct tm, e.g., tm_zone. As noted
in Austin
Group defect 1533, a future version of POSIX is planned to
require tm_gmtoff and tm_zone.
Etc/Unknown', as
CLDR uses that string for an unknown or invalid timezone.
d221 3
a223 3
If all clocks in a region have agreed since 1970,
give them just one name even if some of the clocks disagreed before 1970,
or reside in different countries or in notable or faraway locations.
a224 8
For example, do not create a name Indian/Crozet
as a near-duplicate or alias of Asia/Dubai
merely because they are different countries or territories,
or their clocks disagreed before 1970, or the
Crozet Islands
are notable in their own right,
or the Crozet Islands are not adjacent to other locations
that use Asia/Dubai.
d381 1
a381 2
on platforms that do not support proleptic TZ strings
like <+08>-8;
d428 2
a429 2
This guarantees that all abbreviations could have been specified
explicitly by a POSIX proleptic TZ string.
d579 1
a579 1
from Internet
a580 5
(The abbreviation 'Z' that
Internet
RFC 9557 uses for this concept
would violate the POSIX requirement
of at least three characters in an abbreviation.)
d778 1
a778 1
such as that required by POSIX.
d869 2
a870 2
zic supplied with this package instead of using the
system zic, since the format of zic's
d875 1
a875 4
In POSIX, time display in a process is controlled by the
environment variable TZ, which can have two forms:
TZ value
like CET-1CEST,M3.5.0,M10.5.0/3 uses a complex
notation that specifies a single standard time along with daylight
saving rules that apply to all years past, present, and future.
TZ value
like Europe/Berlin names a location that stands for
civil time near that location, which can have more than
one standard time and more than one set of daylight saving rules,
to record timekeeping practice more accurately.
These names are defined by the tz database.
Some platforms support only the features required by POSIX.1-2017, and have not yet upgraded to POSIX.1-2024. Code intended to be portable to these platforms must deal with problems that were fixed in later POSIX editions.
TZ,
and there is 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.
TZ string,
which is all that POSIX.1-2017 requires,
has a format that is hard to describe and is error-prone in practice.
Also, proleptic TZ strings cannot deal with daylight
d891 1
a891 1
A proleptic TZ string has the following format:
d958 1
a958 1
Here is an example proleptic TZ string for New
d969 1
a969 1
This proleptic TZ string is hard to remember, and
d971 1
a971 1
With this package you can use a geographical TZ instead:
a975 12
POSIX.1-2017 also has the limitations of POSIX.1-2024, discussed in the next section.
POSIX.1-2024 extends POSIX.1-2017 in the following significant ways:
TZ.
Earlier POSIX editions require support only for proleptic TZ.
struct tm
to have a UT offset member tm_gmtoff
and a time zone abbreviation member tm_zone.
Earlier POSIX editions lack this requirement.
"<-02>2<-01>,M3.5.0/-1,M10.5.0/0"
where the transition time −1:00 means 23:00 the previous day.
a988 4
However POSIX.1-2024, like earlier POSIX editions, has some limitations:
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
time conversion package, and when
US time conversion rules changed (as in the United
States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated
to ensure proper results.
tz code
The tz code defines some properties
left unspecified by POSIX, and attempts to support some
extensions to POSIX.
tz code both
d1032 5
d1039 5
a1043 3
If the TZ environment variable uses the geographical format,
it is used in generating
the name of a file from which time-related information is read.
d1046 2
a1047 2
Internet
RFC 9636.
d1056 1
a1056 2
When the tz code was developed in the 1980s,
it was recognized that allowing the TZ environment
d1059 1
a1059 1
certain format) to operate incorrectly; consideration was given to using
d1073 9
d1091 1
a1091 1
The functions were inspired by NetBSD.
a1118 1
It is planned to be removed in a future edition of POSIX.
a1126 1
They are planned to be removed in a future edition of POSIX.
a1137 2
It was intended as an index into the tzname variable,
but as mentioned previously that usage is obsolete.
d1142 2
a1143 3
disambiguation works only for proleptic TZ strings;
it does not work in general for geographical timezones,
such as when a location changes to a time zone with a
d1160 2
a1161 2
use strftime with a %Z conversion specification
to learn the correct time
d1281 7
a1287 7
Unfortunately they have caused so many problems with civil
timekeeping that there are
plans
to discontinue them by 2035.
Even if these plans come to fruition, a record of leap seconds will still be
needed to resolve timestamps from 1972 through 2035,
and there may also be a need to record whatever mechanism replaces them.
a1376 6
Also, NASA
has been ordered
to consider the establishment of Coordinated Lunar Time (LTC).
It is not yet known whether the US and European efforts will result in
multiple timescales on the Moon.
@
1.18
log
@Update tzcode from 2022g to 2023c:
Release 2023c - 2023-03-28 12:42:14 -0700
Release 2023b - 2023-03-23 19:50:38 -0700
Release 2023a - 2023-03-22 12:39:33 -0700
Changes to code
You can now tell tzselect local time, to simplify later choices.
Select the 'time' option in its first prompt.
You can now compile with -DTZNAME_MAXIMUM=N to limit time zone
abbreviations to N bytes (default 255). The reference runtime
library now rejects POSIX-style TZ strings that contain longer
abbreviations, treating them as UTC. Previously the limit was
platform dependent and abbreviations were silently truncated to
16 bytes even when the limit was greater than 16.
The code by default is now designed for C99 or later. To build in
a C89 environment, compile with -DPORT_TO_C89. To support C89
callers of the tzcode library, compile with -DSUPPORT_C89. The
two new macros are transitional aids planned to be removed in a
future version, when C99 or later will be required.
The code now builds again on pre-C99 platforms, if you compile
with -DPORT_TO_C89. This fixes a bug introduced in 2022f.
On C23-compatible platforms tzcode no longer uses syntax like
'static [[noreturn]] void usage(void);'. Instead, it uses
'[[noreturn]] static void usage(void);' as strict C23 requires.
(Problem reported by Houge Langley.)
The code's functions now constrain their arguments with the C
'restrict' keyword consistently with their documentation.
This may allow future optimizations.
zdump again builds standalone with ckdadd and without setenv,
fixing a bug introduced in 2022g. (Problem reported by panic.)
leapseconds.awk can now process a leap seconds file that never
expires; this might be useful if leap seconds are discontinued.
Changes to commentary
tz-link.html has a new section "Coordinating with governments and
distributors". (Thanks to Neil Fuller for some of the text.)
To improve tzselect diagnostics, zone1970.tab's comments column is
now limited to countries that have multiple timezones.
Note that leap seconds are planned to be discontinued by 2035.
@
text
@d98 1
a98 1
standard and daylight saving times supported by POSIX.
d190 1
a190 1
href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX
d365 5
d381 1
a381 1
on platforms that do not support POSIX-style TZ strings;
d429 1
a429 1
POSIX TZ string.
d773 1
a773 1
href="https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-better-double-check-time">the
d778 1
a778 1
such as that required by POSIX.
d875 1
a875 1
TZ strings cannot deal with daylight
d891 1
a891 1
The POSIX TZ string takes the following form:
d958 1
a958 1
Here is an example POSIX TZ string for New
d969 1
a969 1
This POSIX TZ string is hard to remember, and
d1007 1
a1007 1
POSIX provides no convenient and efficient way to determine
d1034 1
a1034 1
TZ is no longer
@
1.17
log
@Merge in 2022g:
Although tzcode still works with C89, bugs found in recent routine
maintenance indicate that bitrot has set in and that in practice
C89 is no longer used to build tzcode. As it is a maintenance
burden, support for C89 is planned to be removed soon. Instead,
please use compilers compatible with C99, C11, C17, or C23.
timegm, which tzcode implemented in 1989, will finally be
standardized 34 years later as part of C23, so timegm is now
supported even if STD_INSPIRED is not defined.
Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone.
(Problem reported by Đoàn Trần Công Danh.)
Fix bug in zic on hosts where malloc(0) yields NULL on success.
(Problem reported by Tim McBrayer for AIX 6.1.)
Fix zic configuration to avoid linkage failures on some platforms.
(Problems reported by Gilmore Davidson and Igor Ivanov.)
Work around MS-Windows nmake incompatibility with POSIX.
(Problem reported by Manuela Friedrich.)
Port mktime and strftime to debugging platforms where accessing
uninitialized data has undefined behavior (strftime problem
reported by Robert Elz).
Check more carefully for unlikely integer overflows, preferring
C23 STD_INSPIRED is defined should, at this point, be
d1245 1
a1245 1
rely on recently-added zic features, so that users can
d1274 12
d1299 1
a1299 1
and systems needing more-precise UTC can use this package's leap
d1304 1
a1304 1
The directly-supported mechanism assumes that time_t
d1365 9
a1373 1
America/Mazatlan which observes Mexican-style DST,
@
1.15
log
@Welcome to tzcode-2022c
Work around a bug in onetrueawk that broke commands like
'make traditional_tarballs' on FreeBSD, macOS, etc.
(Problem reported by Deborah Goldsmith.)
Add code to tzselect that uses experimental structured comments in
zone1970.tab to clarify whether Zones like Africa/Abidjan and
Europe/Istanbul cross continent or ocean boundaries.
(Inspired by a problem reported by Peter Krefting.)
Fix bug with 'zic -d /a/b/c' when /a is unwritable but the
directory /a/b already exists.
Remove zoneinfo2tdf.pl, as it was unused and triggered false
malware alarms on some email servers.
@
text
@d332 1
@
1.14
log
@Welcome to 2022b:
zic has a new option '-R @@N' to output explicit transitions < N.
(Need suggested by Almaz Mingaleev.)
'zic -r @@N' no longer outputs bad data when N < first transition.
(Problem introduced in 2021d and reported by Peter Krefting.)
zic now checks its input for NUL bytes and unterminated lines, and
now supports input line lengths up to 2048 (not 512) bytes.
gmtime and related code now use the abbreviation "UTC" not "GMT".
POSIX is being revised to require this.
When tzset and related functions set vestigial static variables
like tzname, they now prefer specified timestamps to unspecified ones.
(Problem reported by Almaz Mingaleev.)
zic no longer complains "can't determine time zone abbreviation to
use just after until time" when a transition to a new standard
time occurs simultanously with the first DST fallback transition.
@
text
@d125 1
a125 1
The Unicode Common Locale Data
d574 1
a574 1
from Internet
d627 1
a627 1
href="http://www.hup.harvard.edu/catalog.php?isbn=9780674286146">The
d813 1
a813 1
Proc Royal Soc A. 2016 Dec 7;472:20160404.
d1039 1
a1039 1
Internet
d1067 6
a1072 5
in struct tm, e.g., tm_gmtoff.
struct tm, e.g., tm_zone.
d1133 2
a1134 1
a DST transition when the clock jumps back, this
d1282 1
a1282 1
NTP
@
1.13
log
@welcome to tzcode-2022a
Changes to code
Fix bug when mktime gets confused by truncated TZif files with
unspecified local time. (Problem reported by Almaz Mingaleev.)
Fix bug when 32-bit time_t code reads malformed 64-bit TZif data.
(Problem reported by Christos Zoulas.)
When reading a version 2 or later TZif file, the TZif reader now
validates the version 1 header and data block only enough to skip
over them, as recommended by RFC 8536 section 4. Also, the TZif
reader no longer mistakenly attempts to parse a version 1 TZIf
file header as a TZ string.
zdump -v now outputs "(localtime failed)" and "(gmtime failed)"
when local time and UT cannot be determined for a timestamp.
@
text
@d379 1
a379 1
One of etcetera's names is GMT,
d382 2
d473 1
d508 1
a508 1
KMT Kaunas, Kiev, Kingston;
d726 2
a727 2
−00:25:21.1), but the tz
code cannot represent the fractional second.
d1301 2
a1302 1
conventionally named GMT,
@
1.12
log
@Change to code and documentation from 2021a -> 2021e
Release 2021e - 2021-10-21 18:41:00 -0700
Changes to code
none
Release 2021d - 2021-10-15 13:48:18 -0700
Changes to code
'zic -r' now uses "-00" time zone abbreviations for intervals
with UT offsets that are unspecified due to -r truncation.
This implements a change in draft Internet RFC 8536bis.
Release 2021c - 2021-10-01 14:21:49 -0700
Changes to code
Fix a bug in 'zic -b fat' that caused old timestamps to be
mishandled in 32-bit-only readers (problem reported by Daniel
Fischer).
Changes to documentation
Distribute the SECURITY file (problem reported by Andreas Radke).
Release 2021b - 2021-09-24 16:23:00 -0700
Changes to maintenance procedure
The new file SECURITY covers how to report security-related bugs.
Several backward-compatibility links have been moved to the
'backward' file. These links, which range from Africa/Addis_Ababa
to Pacific/Saipan, are only for compatibility with now-obsolete
guidelines suggesting an entry for every ISO 3166 code.
The intercontinental convenience links Asia/Istanbul and
Europe/Nicosia have also been moved to 'backward'.
Changes to code
zic now creates each output file or link atomically,
possibly by creating a temporary file and then renaming it.
This avoids races where a TZ setting would temporarily stop
working while zic was installing a replacement file or link.
zic -L no longer omits the POSIX TZ string in its output.
Starting with 2020a, zic -L truncated its output according to the
"Expires" directive or "#expires" comment in the leapseconds file.
The resulting TZif files omitted daylight saving transitions after
the leap second table expired, which led to far less-accurate
predictions of times after the expiry. Although future timestamps
cannot be converted accurately in the presence of leap seconds, it
is more accurate to convert near-future timestamps with a few
seconds error than with an hour error, so zic -L no longer
truncates output in this way.
Instead, when zic -L is given the "Expires" directive, it now
outputs the expiration by appending a no-change entry to the leap
second table. Although this should work well with most TZif
readers, it does not conform to Internet RFC 8536 and some pickier
clients (including tzdb 2017c through 2021a) reject it, so
"Expires" directives are currently disabled by default. To enable
them, set the EXPIRES_LINE Makefile variable. If a TZif file uses
this new feature it is marked with a new TZif version number 4,
a format intended to be documented in a successor to RFC 8536.
zic -L LEAPFILE -r @@LO no longer generates an invalid TZif file
that omits leap second information for the range LO..B when LO
falls between two leap seconds A and B. Instead, it generates a
TZif version 4 file that represents the previously-missing
information.
The TZif reader now allows the leap second table to begin with a
correction other than -1 or +1, and to contain adjacent
transitions with equal corrections. This supports TZif version 4.
The TZif reader now lets leap seconds occur less than 28 days
apart. This supports possible future TZif extensions.
Fix bug that caused 'localtime' etc. to crash when TZ was
set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does
not conform to POSIX but does conform to Internet RFC 8536.
Fix another bug that caused 'localtime' etc. to crash when TZ was
set to a POSIX-conforming but unusual TZ string like
"EST5EDT4,0/0,J365/0", where almost all the year is DST.
Fix yet another bug that caused 'localtime' etc. to mishandle slim
TZif files containing leap seconds after the last explicit
transition in the table, or when handling far-future timestamps
in slim TZif files lacking leap seconds.
Fix localtime misbehavior involving positive leap seconds.
This change affects only behavior for "right" system time,
which contains leap seconds, and only if the UT offset is
not a multiple of 60 seconds when a positive leap second occurs.
(No such timezone exists in tzdb, luckily.) Without the fix,
the timestamp was ambiguous during a positive leap second.
With the fix, any seconds occurring after a positive leap second
and within the same localtime minute are counted through 60, not
through 59; their UT offset (tm_gmtoff) is the same as before.
Here is how the fix affects timestamps in a timezone with UT
offset +01:23:45 (5025 seconds) and with a positive leap second at
1972-06-30 23:59:60 UTC (78796800):
time_t without the fix with the fix
78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 (leap second)
78796801 1972-07-01 01:23:45 1972-07-01 01:23:46
...
78796815 1972-07-01 01:23:59 1972-07-01 01:23:60
78796816 1972-07-01 01:24:00 1972-07-01 01:24:00
Fix an unlikely bug that caused 'localtime' etc. to misbehave if
civil time changes a few seconds before time_t wraps around, when
leap seconds are enabled.
Fix bug in zic -r; in some cases, the dummy time type after the
last time transition disagreed with the TZ string, contrary to
Internet RFC 8563 section 3.3.
Fix a bug with 'zic -r @@X' when X is a negative leap second that
has a nonnegative correction. Without the fix, the output file
was truncated so that X appeared to be a positive leap second.
Fix a similar, even-less-likely bug when truncating at a positive
leap second that has a nonpositive correction.
zic -r now reports an error if given rolling leap seconds, as this
usage has never generally worked and is evidently unused.
zic now generates a POSIX-conforming TZ string for TZif files
where all-year DST is predicted for the indefinite future.
For example, for all-year Eastern Daylight Time, zic now generates
"XXX3EDT4,0/0,J365/23" where it previously generated
"EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for
noting the possibility of POSIX conformance.)
zic.c no longer requires sys/wait.h (thanks to spazmodius for
noting it wasn't needed).
When reading slim TZif files, zdump no longer mishandles leap
seconds on the rare platforms where time_t counts leap seconds,
fixing a bug introduced in 2014g.
zdump -v now outputs timestamps at boundaries of what localtime
and gmtime can represent, instead of the less-useful timestamps
one day after the minimum and one day before the maximum.
(Thanks to Arthur David Olson for prototype code, and to Manuela
Friedrich for debugging help.)
zdump's -c and -t options are now consistently inclusive for the
lower time bound and exclusive for the upper. Formerly they were
inconsistent. (Confusion noted by Martin Burnicki.)
Changes to build procedure
You can now compile with -DHAVE_MALLOC_ERRNO=0 to port to
non-POSIX hosts where malloc doesn't set errno.
(Problem reported by Jan Engelhardt.)
Changes to documentation
tzfile.5 better matches a draft successor to RFC 8536
backward' file.
d351 1
a351 1
The file 'zone1970.tab' lists geographical locations used
d355 1
a355 1
Although a 'zone1970.tab' location's
d361 4
d368 14
a381 3
Excluding 'backward' should not affect the other data.
If 'backward' is excluded, excluding
'etcetera' should not affect the remaining data.
@
1.11
log
@Merge tzcode-2021a
- No comments in the changelog about the code changes.
@
text
@a44 2
The database labels each timezone with a notable location and
records all known clock transitions for that location.
d49 3
d62 3
a64 2
time, America/Mazatlan which observes Mexican-style DST,
and America/Phoenix which does not observe DST.
d73 1
a73 1
Clock transitions before 1970 are recorded for each timezone,
d195 2
a196 2
E.g., prefer Asia/Brunei to
Asia/Bandar_Seri_Begawan.
d478 1
a478 1
AMT Amsterdam, Asunción, Athens;
d481 1
a481 1
CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba;
d504 2
a505 1
WMT Warsaw.
d519 1
a519 3
An extra-special case is SET for Swedish Time (svensk
normaltid) 1879–1899, 3° west of the Stockholm
Observatory.
d706 1
a706 3
For example, from 1909 to 1937 Netherlands clocks were legally Amsterdam Mean
d708 1
a708 1
+00:19:32.13), but the tz
d755 2
a756 1
such as that required by POSIX. If DST is not used a different time zone
d1274 2
a1275 1
at the same point that time zone and DST adjustments are applied –
@
1.10
log
@Merge tzcode2020b (except we keep tzsetwall(3) for now for compatibility,
and we were "slim" already)
Support for zic's long-obsolete '-y YEARISTYPE' option has been
removed and, with it, so has support for the TYPE field in Rule
lines, which is now reserved for compatibility with earlier zic.
These features were previously deprecated in release 2015f.
(Thanks to Tim Parenti.)
zic now defaults to '-b slim' instead of to '-b fat'.
zic's new '-l -' and '-p -' options uninstall any existing
localtime and posixrules files, respectively.
The undocumented and ineffective tzsetwall function has been
removed.
@
text
@d477 2
a478 2
BMT Baghdad, Bangkok, Batavia, Bern, Bogotá, Bridgetown, Brussels,
Bucharest;
d509 1
@
1.9
log
@Bring in 2020a
@
text
@d36 1
a36 1
all computer-based clocks that track civil time.
d118 1
a118 1
"Ruthenia" instead of the timezone name "Europe/Uzhgorod".
d123 1
a123 1
The Unicode Common Locale Data
d125 2
a126 4
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
"乌日哥罗德".
d694 8
d1330 2
a1331 2
Some people's work schedules
use Mars time.
d1335 1
a1335 1
Pathfindertzsetwall 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
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 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.)
HAVE_TZNAME is defined) to learn the correct time
d1243 63
@
1.7
log
@merge 2019a
Changes to code
zic now has an -r option to limit the time range of output data.
For example, 'zic -r @@1000000000' limits the output data to
timestamps starting 1000000000 seconds after the Epoch.
This helps shrink output size and can be useful for applications
not needing the full timestamp history, such as TZDIST truncation;
see Internet RFC 8536 section 5.1. (Inspired by a feature request
from Christopher Wong, helped along by bug reports from Wong and
from Tim Parenti.)
Changes to documentation
Mention Internet RFC 8536 (February 2019), which documents TZif.
tz-link.html now cites tzdata-meta
set
`date`'
d958 1
a958 1
system's best idea of local wall clock.
d1055 1
a1055 1
system's best approximation to local wall clock time to be delivered
d1057 2
a1058 2
Source code for portable applications that "must" run on local wall
clock time should call tzsetwall;
d1062 1
a1062 1
(These functions also arrange for local wall clock time to
d1357 1
a1357 1
(2015-06-30).
d1361 1
a1361 1
"Workdays
@
1.6
log
@Release 2018i - 2018-12-30 11:05:43 -0800
Briefly:
São Tomé and Príncipe switches from +01 to +00 on 2019-01-01.
Changes to future timestamps
Due to a change in government, São Tomé and Príncipe switches back
from +01 to +00 on 2019-01-01 at 02:00. (Thanks to Vadim
Nasardinov and Michael Deckers.)
Release 2018h - 2018-12-23 17:59:32 -0800
Briefly:
Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21.
New zone Asia/Qostanay because Qostanay, Kazakhstan didn't move.
Metlakatla, Alaska observes PST this winter only.
Guess Morocco will continue to adjust clocks around Ramadan.
Add predictions for Iran from 2038 through 2090.
Changes to future timestamps
Guess that Morocco will continue to fall back just before and
spring forward just after Ramadan, the practice since 2012.
(Thanks to Maamar Abdelkader.) This means Morocco will observe
negative DST during Ramadan in main and vanguard formats, and in
rearguard format it stays in the +00 timezone and observes
ordinary DST in all months other than Ramadan. As before, extend
this guesswork to the year 2037. As a consequence, Morocco is
scheduled to observe three DST transitions in some Gregorian years
(e.g., 2033) due to the mismatch between the Gregorian and Islamic
calendars.
The table of exact transitions for Iranian DST has been extended.
It formerly cut off before the year 2038 in a nod to 32-bit time_t.
It now cuts off before 2091 as there is doubt about how the Persian
calendar will treat 2091. This change predicts DST transitions in
2038-9, 2042-3, and 2046-7 to occur one day later than previously
predicted. As before, post-cutoff transitions are approximated.
Changes to past and future timestamps
Qyzylorda (aka Kyzylorda) oblast in Kazakhstan moved from +06 to
+05 on 2018-12-21. This is a zone split as Qostanay (aka
Kostanay) did not switch, so create a zone Asia/Qostanay.
Metlakatla moved from Alaska to Pacific standard time on 2018-11-04.
It did not change clocks that day and remains on -08 this winter.
(Thanks to Ryan Stanley.) It will revert to the usual Alaska
rules next spring, so this change affects only timestamps
from 2018-11-04 through 2019-03-10.
Change to past timestamps
Kwajalein's 1993-08-20 transition from -12 to +12 was at 24:00,
not 00:00. I transcribed the time incorrectly from Shanks.
(Thanks to Phake Nick.)
Nauru's 1979 transition was on 02-10 at 02:00, not 05-01 at 00:00.
(Thanks to Phake Nick.)
Guam observed DST irregularly from 1959 through 1977.
(Thanks to Phake Nick.)
Hong Kong observed DST in 1941 starting 06-15 (not 04-01), then on
10-01 changed standard time to +08:30 (not +08). Its transition
back to +08 after WWII was on 1945-09-15, not the previous day.
Its 1904-10-30 change took effect at 01:00 +08 (not 00:00 LMT).
(Thanks to Phake Nick, Steve Allen, and Joseph Myers.) Also,
its 1952 fallback was on 11-02 (not 10-25).
This release contains many changes to timestamps before 1946 due
to Japanese possession or occupation of Pacific/Chuuk,
Pacific/Guam, Pacific/Kosrae, Pacific/Kwajalein, Pacific/Majuro,
Pacific/Nauru, Pacific/Palau, and Pacific/Pohnpei.
(Thanks to Phake Nick.)
Assume that the Spanish East Indies was like the Philippines and
observed American time until the end of 1844. This affects
Pacific/Chuuk, Pacific/Kosrae, Pacific/Palau, and Pacific/Pohnpei.
Changes to past tm_isdst flags
For the recent Morocco change, the tm_isdst flag should be 1 from
2018-10-27 00:00 to 2018-10-28 03:00. (Thanks to Michael Deckers.)
Give a URL to the official decree. (Thanks to Matt Johnson.)
@
text
@d18 1
a18 1
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.
d309 3
a311 3
Older versions of this package used a different naming scheme, and these older names are still supported. d317 1 a317 1
d319 1 a319 1d330 25 d1006 3 a1008 1 a timezone information format that contains binary data. d1191 1 a1191 1 "Names of timezones" above. d1238 11 @ 1.5 log @Welcome tzcode-2018g Changes to code When generating TZif files with leap seconds, zic no longer uses a format that trips up older 32-bit clients, fixing a bug introduced in 2018f. (Reported by Daniel Fischer.) Also, the zic workaround for QTBUG-53071 now also works for TZif files with leap seconds. The translator to rearguard format now rewrites the line "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". This caters to zic before 2007 and to Oracle TZUpdater 2.2.0 and earlier. (Reported by Christos Zoulas.) Changes to documentation tzfile.5 has new sections on interoperability issues. @ text @d409 1 a409 1 GST Guam, d1241 1 a1241 1 Mars d1264 1 a1264 2 called Mars Coordinated Time (MTC). @ 1.4 log @Update to 2018f: Changes to code zic now always generates TZif files where time type 0 is used for timestamps before the first transition. This simplifies the reading of TZif files and should not affect behavior of existing TZif readers because the same set of time types is used; only their internal indexes may have changed. This affects only the legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. Because of the type 0 change, zic no longer outputs a dummy transition at time -2**59 (before the Big Bang), as clients should no longer need this to handle historical timestamps correctly. This reverts a change introduced in 2013d and shrinks most TZif files by a few bytes. zic now supports negative time-of-day in Rule and Leap lines, e.g., "Rule X min max - Apr lastSun -6:00 1:00 -" means the transition occurs at 18:00 on the Saturday before the last Sunday in April. This behavior was documented in 2018a but the code did not entirely match the documentation. localtime.c no longer requires at least one time type in TZif files that lack transitions or have a POSIX-style TZ string. This future-proofs the code against possible future extensions to the format that would allow TZif files with POSIX-style TZ strings and without transitions or time types. A read-access subscript error in localtime.c has been fixed. It could occur only in TZif files with timecnt == 0, something that does not happen in practice now but could happen in future versions. localtime.c no longer ignores TZif POSIX-style TZ strings that specify only standard time. Instead, these TZ strings now override the default time type for timestamps after the last transition (or for all time stamps if there are no transitions), just as DST strings specifying DST have always done. leapseconds.awk now outputs "#updated" and "#expires" comments, and supports leap seconds at the ends of months other than June and December. (Inspired by suggestions from Chris Woodbury.) Changes to documentation New restrictions: A Rule name must start with a character that is neither an ASCII digit nor "-" nor "+", and an unquoted name should not use characters in the set "!$%&'()*,/:;<=>?@@[\]^`{|}~". The latter restriction makes room for future extensions (a possibility noted by Tom Lane). tzfile.5 now documents what time types apply before the first and after the last transition, if any. Documentation now uses the spelling "timezone" for a TZ setting that determines timestamp history, and "time zone" for a geographic region currently sharing the same standard time. The name "TZif" is now used for the tz binary data format. tz-link.htm now mentions the A0 TimeZone Migration utilities. (Thanks to Aldrin Martoq for the link.) @ text @d410 1 a410 1 HST/HDT Hawaii, @ 1.3 log @Merge 2018e Changes to code zic now accepts subsecond precision in expressions like 00:19:32.13, which is approximately the legal time of the Netherlands from 1835 to 1937. However, because it is questionable whether the few recorded uses of non-integer offsets had subsecond precision in practice, there are no plans for tzdata to use this feature. (Thanks to Steve Allen for pointing out the limitations of historical data in this area.) The code is a bit more portable to MS-Windows. Installers can compile with -DRESERVE_STD_EXT_IDS on MS-Windows platforms that reserve identifiers like 'localtime'. (Thanks to Manuela Friedrich). Changes to documentation and commentary theory.html now outlines tzdb's extensions to POSIX's model for civil time, and has a section "POSIX features no longer needed" that lists POSIX API components that are now vestigial. (From suggestions by Steve Summit.) It also better distinguishes time zones from tz regions. (From a suggestion by Guy Harris.) Commentary is now more consistent about using the phrase "daylight saving time", to match the C name tm_isdst. Daylight saving time need not occur in summer, and need not have a positive offset from standard time. Commentary about historical transitions in Uruguay has been expanded with links to many relevant legal documents. (Thanks to Tim Parenti.) Commentary now uses some non-ASCII characters with Unicode value less than U+0100, as they can be useful and should work even with older editors such as XEmacs. @ text @d1 1 d6 3 d18 1 a18 1
tz region corresponds to a ruleset that can
d101 4
a104 4
Whether and when a tz region changes its
clock, and even the region's notional base offset from UTC, are variable.
It does not always make sense to talk about a region's
"base offset", since it is not necessarily a single number.
d110 1
a110 1
tz region has a unique name that
corresponds to a set of time zone rules.
d115 5
a119 1
interface that explains the names; for one example, see the
d123 4
a126 1
interfaces.
d136 1
a136 1
Uniquely identify every region where clocks have agreed since 1970.
d141 1
a141 1
Indicate to experts where that region is.
d161 2
a162 3
AREA is the name of a continent or ocean, and
LOCATION is the name of a specific location within that
region.
d173 1
a173 1
choosing tz region names,
d225 3
a227 3
If all the clocks in a region have agreed since 1970,
do not bother to include more than one location
even if subregions' clocks disagreed before 1970.
d241 1
a241 1
tz regions.
d249 1
a249 1
Europe/Rome to Europe/Roma, and
d251 2
a252 2
Europe/Αθήνα or the Romanized
Europe/Athína.
d303 1
a303 1
to name tz regions.
d305 1
a305 1
regions as described above; this is a subset of the names in the data.
d427 1
d483 1
a483 1
GMT/BST established for time in the UK.
d503 1
a503 1
-05 and +0830 that are generated
d518 2
a519 2
Use a consistent style in a tz region's history.
For example, if history tends to use numeric
d531 1
a531 1
RFC 3339.
d573 1
a573 1
Thousands more tz regions would be needed if
d638 1
a638 1
earliest time for which a tz region's
d644 1
a644 1
For many tz regions the earliest time of
d650 1
a650 1
For example, the tz region
d694 5
d701 1
a701 1
The tz database models pre-standard time
d704 4
a707 2
Gregorian calendar and local mean time, but many people used
other calendars and other timescales.
d714 13
d760 1
a760 1
Measurement of
d796 1
a796 1
should not prompt creation of tz regions
d848 1
a848 1
and daylight saving time (DST) zone names.
d920 2
a921 1
POSIX does not define the exact meaning of TZ values like
d923 6
a928 7
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
d934 1
a934 1
need access to multiple time zone rulesets.
d939 1
a939 1
(This is important for applications that an administrator wants
d945 2
a946 2
handling daylight saving time shifts - as might be required to
limit phone calls to off-peak hours.)
d951 1
a951 1
timestamps, particularly for tz regions
d969 1
a969 1
floating-point type, this was not supported by any practical systems,
d981 1
a981 1
the name of a binary file from which time-related information is read
d983 4
a986 3
constrained to be a three-letter time zone
abbreviation followed by a number of hours and an optional three-letter
daylight time zone abbreviation.
d988 3
a990 3
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
d1000 1
a1000 1
to hold the string used to generate the binary file's name.
d1006 3
a1008 3
use TZ values such as "EST5EDT" which
can be used both by "new" programs (à la POSIX) and "old"
programs (as zone names and offsets).
d1023 1
a1023 1
time zone rulesets.
d1144 3
a1146 2
Other time conversion proposals, in particular the one developed
by folks at Hewlett Packard, offer a wider selection of functions
d1168 2
a1169 2
A set of tz region names as per
"Names of time zone rulesets" above.
d1238 1
a1238 1
use Mars time.
d1270 1
a1270 1
solar time keeping, so there is no real standard for Mars time zones.
d1342 1
a1342 1
(2017-04-27).
@
1.3.2.1
log
@Sync with HEAD
@
text
@a0 1
a4 3
d14 1
a14 1
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,
d76 1
a76 1
A tz timezone corresponds to a ruleset that can
d80 4
a83 4
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.
d89 1
a89 1
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
d99 1
a99 4
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
"乌日哥罗德".
d109 1
a109 1
Uniquely identify every timezone where clocks have agreed since 1970.
d114 1
a114 1
Indicate to experts where the timezone's clocks typically are.
d118 1
a118 1
For example, names are typically not tied to countries, to avoid
d120 1
a120 1
Swaziland→Eswatini) or when locations change countries (e.g., Hong
a121 2
There is no requirement that every country or national
capital must have a timezone name.
d134 3
a136 2
AREA is a continent or ocean, and
LOCATION is a specific location within the area.
d147 1
a147 1
choosing timezone names,
d192 5
a196 4
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.
d199 4
a202 4
If boundaries between regions are fluid, such as during a war or
insurrection, do not bother to create a new timezone merely
because of yet another boundary change. This helps prevent table
bloat and simplifies maintenance.
d215 1
a215 1
timezones.
d223 1
a223 1
Europe/Rome to Europa/Roma, and
d225 2
a226 2
Ευρώπη/Αθήνα or the Romanized
Evrópi/Athína.
d276 10
a285 4
Guidelines have evolved with time, and names following old versions of
this guideline might not follow the current version. When guidelines
have changed, old names continue to be supported. Guideline changes
have included the following:
d288 3
a290 3
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.
d383 2
a384 2
GST/GDT Guam,
HST/HDT/HWT/HPT Hawaii,
a400 1
PST/PDT Philippine,
d456 1
a456 1
GMT/BST established for time in the UK.
d476 1
a476 1
-05 and +0530 that are generated
d491 2
a492 2
Use a consistent style in a timezone's history.
For example, if a history tends to use numeric
d504 1
a504 1
RFC 3339.
d546 1
a546 1
Thousands more timezones would be needed if
d611 1
a611 1
earliest time for which a timezone's
d617 1
a617 1
For many timezones the earliest time of
d623 1
a623 1
For example, the timezone
a666 5
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.
d669 1
a669 1
The tz database models time
d672 2
a673 4
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.
a679 13
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.
d713 1
a713 1
Measurement of
d749 1
a749 1
should not prompt creation of timezones
d801 1
a801 1
and daylight saving time (DST) zone abbreviations.
d873 1
a873 2
POSIX does not define the DST transitions
for TZ values like
d875 7
a881 6
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
d887 1
a887 1
need access to multiple timezones.
d892 1
a892 1
This is important for applications that an administrator wants
d898 2
a899 2
handling daylight saving time shifts – as might be required to
limit phone calls to off-peak hours.
d904 1
a904 1
timestamps, particularly for timezones
d922 1
a922 1
floating-point type, this was not supported by any practical system,
d934 1
a934 1
the name of a file from which time-related information is read
d936 3
a938 6
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; see
Internet
RFC 8536.
d940 3
a942 3
particular timezone are encoded in the
TZif file; the format of the file allows US,
Australian, and other rules to be encoded, and
d952 1
a952 1
to hold the string used to generate the TZif file's name.
d958 3
a960 3
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.
d975 1
a975 1
timezones.
d1096 2
a1097 3
Other time conversion proposals, in particular those supported by the
Time Zone
Database Parser, offer a wider selection of functions
d1119 2
a1120 2
A set of timezone names as per
"Timezone identifiers" above.
a1166 11
Timezone boundaries are not part of the stable interface. For example, even though the Asia/Bangkok timezone currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part of the stable interface and the timezone can split at any time. If a calendar application records a future event in some location other than Bangkok by putting "Asia/Bangkok" in the event's record, the application should be robust in the presence of timezone splits between now and the future time.
d1189 1 a1189 1 use Mars time. d1192 1 a1192 1 Mars d1215 2 a1216 1 called Mars Coordinated Time (MTC). d1221 1 a1221 1 solar timekeeping, so there is no real standard for Mars time zones. d1293 1 a1293 1 (2016-01-20). @ 1.3.2.2 log @Mostly merge changes from HEAD upto 20200411 @ text @d91 1 a91 1 href="https://pubs.opengroup.org/onlinepubs/9699919799/"> The Open d189 1 a189 1 href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">POSIX d304 1 a304 1 these guidelines might not follow the current version. When guidelines d333 1 a333 1 Older versions of these guidelines said that d382 2 a383 2 'set
`date`'
d958 1
a958 1
system's best idea of local (wall clock) time.
d1055 1
a1055 1
system's best approximation to local (wall clock) time to be delivered
d1057 2
a1058 2
Source code for portable applications that "must" run on local
time should call tzsetwall;
d1062 1
a1062 1
(These functions also arrange for local time to
d1357 1
a1357 1
(2018-12-13).
d1361 1
a1361 1
"Workdays
@
1.2
log
@Merge tzcode2018c [ changelog with changes to tzdata sections removed ]
Release 2018c - 2018-01-22 23:00:44 -0800
Changes to build procedure
The build procedure now works around mawk 1.3.3's lack of support
for character class expressions. (Problem reported by Ohyama.)
Release 2018b - 2018-01-17 23:24:48 -0800
Changes to build procedure
The distribution now contains the file 'pacificnew' again.
This file was inadvertantly omitted in the 2018a distribution.
(Problem reported by Matias Fonzo.)
Release 2018a - 2018-01-12 22:29:21 -0800
Changes to build procedure
The default installation locations have been changed to mostly
match Debian circa 2017, instead of being designed as an add-on to
4.3BSD circa 1986. This affects the Makefile macros TOPDIR,
TZDIR, MANDIR, and LIBDIR. New Makefile macros TZDEFAULT, USRDIR,
USRSHAREDIR, BINDIR, ZDUMPDIR, and ZICDIR let installers tailor
locations more precisely. (This responds to suggestions from
Brian Inglis and from Steve Summit.)
The default installation procedure no longer creates the
backward-compatibility link US/Pacific-New, which causes
confusion during user setup (e.g., see Debian bug 815200).
Use 'make BACKWARD="backward pacificnew"' to create the link
anyway, for now. Eventually we plan to remove the link entirely.
tzdata.zi now contains a version-number comment.
(Suggested by Tom Lane.)
The Makefile now quotes values like BACKWARD more carefully when
passing them to the shell. (Problem reported by Zefram.)
Builders no longer need to specify -DHAVE_SNPRINTF on platforms
that have snprintf and use pre-C99 compilers. (Problem reported
by Jon Skeet.)
Changes to code
zic has a new option -t FILE that specifies the location of the
file that determines local time when TZ is unset. The default for
this location can be configured via the new TZDEFAULT makefile
macro, which defaults to /etc/localtime.
Diagnostics and commentary now distinguish UT from UTC more
carefully; see theory.html for more information about UT vs UTC.
zic has been ported to GCC 8's -Wstringop-truncation option.
(Problem reported by Martin Sebor.)
Changes to documentation and commentary
The zic man page now documents the longstanding behavior that
times and years can be out of the usual range, with negative times
counting backwards from midnight and with year 0 preceding year 1.
(Problem reported by Michael Deckers.)
The theory.html file now mentions the POSIX limit of six chars
per abbreviation, and lists alphabetic abbreviations used.
The files tz-art.htm and tz-link.htm have been renamed to
tz-art.html and tz-link.html, respectively, for consistency with
other file names and to simplify web server configuration.
@
text
@a0 1
a6 7
d8 1
a8 1
/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'.
d146 2
a147 1
Here are the general rules used for choosing location names,
d150 1
d153 15
a167 13
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.
d170 2
a171 2
A name must not be empty, or contain '//', or
start or end with '/'.
d174 4
a177 3
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.
d180 6
a185 7
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'.
d188 2
a189 2
Uninhabited regions like the North Pole and Bouvet Island
do not need locations, since local time is not defined there.
d192 5
a196 3
There should typically be at least one name for each ISO 3166-1
officially assigned two-letter code for an inhabited country
or territory.
d199 4
a202 4
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.
d205 5
a209 3
If a name is ambiguous, use a less ambiguous alternative;
e.g. many cities are named San José and Georgetown, so
prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.
d212 8
a219 5
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.
d222 6
a227 6
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.
d230 6
a235 5
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'.
d238 2
a239 1
Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
d242 10
a251 9
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.
d254 1
a254 1
Use '_' to represent a space.
d257 3
a259 2
Omit '.' from abbreviations in names, e.g. prefer
'St_Helena' to 'St._Helena'.
d262 5
a266 6
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.
d269 3
a271 3
If a name is changed, put its old spelling in the
'backward' file.
This means old spellings will continue to work.
d277 9
a285 6
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.
d294 2
a295 1
'WET', 'CET', 'MET', and 'EET' (see the file 'europe').
d300 9
a308 5
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'.
d312 3
a314 3
Excluding 'backward' should not affect the other data. If
'backward' is excluded, excluding 'etcetera' should not affect the
remaining data.
d316 1
d318 2
a319 4
+' 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.
These abbreviations (for standard/daylight/etc. time) are: ACST/ACDT Australian Central, AST/ADT/APT/AWT/ADDT Atlantic, AEST/AEDT Australian Eastern, AHST/AHDT Alaska-Hawaii, AKST/AKDT Alaska, AWST/AWDT Australian Western, BST/BDT Bering, CAT/CAST Central Africa, CET/CEST/CEMT Central European, ChST Chamorro, CST/CDT/CWT/CPT/CDDT Central [North America], CST/CDT China, GMT/BST/IST/BDST Greenwich, EAT East Africa, EST/EDT/EWT/EPT/EDDT Eastern [North America], EET/EEST Eastern European, GST Guam, HST/HDT Hawaii, HKT/HKST Hong Kong, IST India, IST/GMT Irish, IST/IDT/IDDT Israel, JST/JDT Japan, KST/KDT Korea, MET/MEST Middle European (a backward-compatibility alias for Central European), MSK/MSD Moscow, MST/MDT/MWT/MPT/MDDT Mountain, NST/NDT/NWT/NPT/NDDT Newfoundland, NST/NDT/NWT/NPT Nome, NZMT/NZST New Zealand through 1945, NZST/NZDT New Zealand 1946–present, PKT/PKST Pakistan, PST/PDT/PWT/PPT/PDDT Pacific, SAST South Africa, SST Samoa, WAT/WAST West Africa, WET/WEST/WEMT Western European, WIB Waktu Indonesia Barat, WIT Waktu Indonesia Timur, WITA Waktu Indonesia Tengah, YST/YDT/YWT/YPT/YDDT Yukon.
-004430' for MMT) would
cause trouble here, as the numeric strings would exceed the POSIX length limit.
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.
-05 and +0830 that are
generated by zic's %z notation.
-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.
d507 1
d512 2
a513 1
Israel. To avoid ambiguity, use numeric UT offsets like
d516 1
a516 1
Europe/London
stands for the United Kingdom, but its pre-1847 times are valid
only for locations that have London's exact meridian, and its 1847
transition to GMT is known to be valid only for the L&NW and the
Caledonian railways.
Europe/London is valid for all locations in its
region after GMT was made the standard time, but the date of
standardization (1880-08-02) is not in the tz database, other than
in commentary. For many zones the earliest time of validity is
unknown.
America/Kentucky/Louisville represents a region around
the city of
Louisville, the boundaries of which are unclear.
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.
POSIX has the following properties and limitations.
d775 9 a783 6 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. d785 1 d787 1 a787 1 The POSIX TZ string takes the following form: d789 1 d791 1 a791 1 stdoffset[dst[offset][,date[/time],date[/time]]]
d793 1
d795 3
a797 1
where:
d800 5
a804 6
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.
d807 7
a813 5
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.
d816 4
a819 3
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.
d822 5
a826 5
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.
d829 1
a829 1
takes one of the following forms:
d832 2
a833 2
origin-1 day number not counting February 29
d835 13
a847 14
origin-0 day number counting February 29 if present
Mm.n.d (0[Sunday]≤d≤6[Saturday], 1≤n≤5, 1≤m≤12)5'
stands for the last week in which
day d appears
(which may be either the 4th or 5th week).
Typically, this is the only useful form;
the n
and Jn forms are
rarely used.
d849 76
a924 66
TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'TZ='Pacific/Auckland'EST5EDT".
Typically the current US DST rules are used to interpret such values,
but this means that the US DST rules are compiled into each program
that does time conversion. This means that when US time conversion
rules change (as in the United States in 1987), all programs that
do time conversion must be recompiled to ensure proper results.
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.
d927 3
a929 3
These are the extensions that have been made to the POSIX functions:
d933 12 a944 9 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. d947 14 a960 13 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).
d962 45
a1006 51
struct tm,
e.g., tm_gmtoff.
struct tm, e.g., tm_zone.
daylight
and timezone variables are no longer needed.
(These variables are defined and set by tzset;
however, their values will not be used
by localtime.)
tzalloc, tzfree,
localtime_rz, and mktime_z for
more-efficient thread-safe applications that need to use
multiple time zones. The tzalloc
and tzfree functions allocate and free objects of
type timezone_t, and localtime_rz
and mktime_z are like localtime_r
and mktime with an extra
timezone_t argument. The functions were inspired
by NetBSD.
tzsetwall has been added to arrange
for the system's
best approximation to local wall clock time to be delivered by
subsequent calls to localtime. Source code for portable
applications that "must" run on local wall clock time should call
tzsetwall; if such code is moved to "old" systems that don't
provide tzsetwall, you won't be able to generate an executable program.
(These time zone functions also arrange for local wall clock time to be
used if tzset is called – directly or indirectly –
and there's no TZ
environment variable; portable applications should not, however, rely
on this behavior since it's not the way SVR2 systems behave.)
time_t values are supported, on systems
where time_t is signed.
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.
timezone function is not
present in this package;
it's impossible to reliably map timezone's arguments (a "minutes west
of GMT" value and a "daylight saving time in effect" flag) to a
time zone abbreviation, and we refuse to guess.
Programs that in the past used the timezone function may now examine
localtime(&clock)->tm_zone
(if TM_ZONE is defined) or
tzname[localtime(&clock)->tm_isdst]
(if HAVE_TZNAME is defined)
to learn the correct time zone abbreviation to use.
gettimeofday function is not used in
this package.
This formerly let users obtain the current UTC offset and DST flag,
but this functionality was removed in later versions of BSD.
time_t values when doing conversions for places
that don't use UT.
This package takes care to do these conversions correctly.
A comment in the source code tells how to get compatibly wrong
results.
d1109 1
a1109 9
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.
The tz code and data supply the following interfaces:
d1119 2 a1120 2 A set of zone names as per "Names of time zone rules" above. d1123 2 a1124 2 Library functions described in "Time and date functions" above. d1127 2 a1128 2 The programstzselect, zdump,
and zic, documented in their man pages.
d1131 2
a1132 2
The format of zic input files, documented in
the zic man page.
d1135 2
a1136 2
The format of zic output files, documented in
the tzfile man page.
d1139 1
a1139 1
The format of zone table files, documented in zone1970.tab.
d1142 1
a1142 1
The format of the country code file, documented in iso3166.tab.
d1145 2
a1146 2
The version number of the code and data, as the first line of
the text file 'version' in each release.
d1149 1
d1152 7
a1158 6
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.
d1162 4
a1165 4
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.
d1167 1
a1167 1
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. d1203 3 a1205 3 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. d1209 8 a1216 4 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). d1222 8 a1229 6 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. d1234 2 a1235 1 wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a d1237 1 a1237 1 12:00 GMT. d1242 17 a1258 11 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. d1262 3 a1264 2 Although the tz database does not support time on other planets, it is documented here in the hopes that support will be added eventually. d1268 1 a1268 1 Sources: d1270 1 d1273 4 a1276 4 Michael Allison and Robert Schmunk, "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" (2015-06-30). d1279 4 a1282 4 Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times (2004-01-14), pp A1, A20-A21. d1285 3 a1287 3 Tom Chmielewski, "Jet Lag Is Worse on Mars", The Atlantic (2015-02-26) d1290 4 a1293 4 Matt Williams, "How long is a day on the other planets of the solar system?" (2017-04-27). d1296 1 a1296 1
tz code and datatz
databasetz
databasetz databasetz
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 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.
d55 1
a55 1
Although some information outside the scope of the database is
d62 7
a68 21
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 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 does not always make sense to talk about a region's
"base offset", since it is not necessarily a single number.
d70 2
a72 1
tz region has a unique name that
corresponds to a set of time zone rules.
d80 5
a84 5
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.
d88 1
a88 1
The naming conventions attempt to strike a balance
a90 1
d93 3
a95 3
Uniquely identify every region where clocks have agreed since 1970.
This is essential for the intended use: static clocks keeping local
civil time.
d98 1
a98 1
Indicate to experts where that region is.
d101 5
a105 5
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).
d108 1
a108 1
Be portable to a wide variety of implementations.
d111 1
a111 1
Use a consistent naming conventions over the entire world.
a113 1
d115 8
a122 11
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'.
Some names are further qualified to help avoid confusion; for example,
'America/Indiana/Petersburg' distinguishes Petersburg,
Indiana from other Petersburgs in America.
d126 1
a126 2
Here are the general guidelines used for
choosing tz region names,
a128 1
d131 13
a143 15
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.
d146 2
a147 2
A name must not be empty, or contain '//', or
start or end with '/'.
d150 3
a152 4
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.
d155 7
a161 6
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.
d164 2
a165 2
Uninhabited regions like the North Pole and Bouvet Island
do not need locations, since local time is not defined there.
d168 3
a170 5
There should typically be at least one name for each ISO
3166-1 officially assigned two-letter code for an inhabited
country or territory.
d173 4
a176 4
If all the clocks in a region have agreed since 1970,
do not bother to include more than one location
even if subregions' clocks disagreed before 1970.
Otherwise these tables would become annoyingly large.
d179 3
a181 5
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.
d184 5
a188 8
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 Europe/Paris to Europe/France,
since
France
has had multiple time zones.
d191 6
a196 6
Use mainstream English spelling, e.g., prefer
Europe/Rome to Europe/Roma, and
prefer Europe/Athens to the Greek
Europe/Αθήνα or the Romanized
Europe/Athína.
The POSIX file name restrictions encourage this guideline.
d199 5
a203 6
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.
d206 1
a206 2
Use the singular form, e.g., prefer Atlantic/Canary to
Atlantic/Canaries.
d209 9
a217 10
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.
d220 1
a220 1
Use '_' to represent a space.
d223 2
a224 3
Omit '.' from abbreviations in names.
E.g., prefer Atlantic/St_Helena to
Atlantic/St._Helena.
d227 6
a232 5
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.
d235 3
a237 3
If a name is changed, put its old spelling in the
'backward' file.
This means old spellings will continue to work.
d243 6
a248 9
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.
d257 1
a257 2
'WET', 'CET', 'MET', and
'EET' (see the file 'europe').
d262 5
a266 9
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'.
d270 3
a272 3
Excluding 'backward' should not affect the other data.
If 'backward' is excluded, excluding
'etcetera' should not affect the remaining data.
a273 1
+' 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.
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.
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.
tz database".
-05 and +0830 that are generated
by zic's %z notation.
tz region's history.
For example, if history tends to use numeric
abbreviations and a particular entry could go either way, use a
numeric abbreviation.
-00') for
locations while uninhabited.
The leading '-' is a flag that the UT offset is in
some sense undefined; this notation is derived
from Internet
RFC 3339.
a438 1
d443 1
a443 2
Israel.
To avoid ambiguity, use numeric UT offsets like
d446 1
a446 1
tz databasetz database is not authoritative, and it
surely has errors.
d459 1
a459 1
Errors in the tz database arise from many sources:
a460 1
d463 152
a614 203
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.
tz regions would be needed if
the tz database's scope were extended to
cover even just the known or guessed history of standard time; for
example, the current single entry for France would need to split
into dozens of entries, perhaps hundreds.
And in most of the world even this approach would be misleading
due to widespread disagreement or indifference about what times
should be observed.
In her 2015 book
The
Global Transformation of Time, 1870–1950,
Vanessa Ogle writes
"Outside of Europe and North America there was no system of time
zones at all, often not even a stable landscape of mean times,
prior to the middle decades of the twentieth century".
See: Timothy Shenk, Booked:
A Global History of Time. Dissent 2015-12-17.
tz database relies on
years of first-class work done by
Joseph Myers and others; see
"History of
legal time in Britain".
Other countries are not done nearly as well.
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.
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.
tz database does not record a
region's boundaries, and in many cases the boundaries are not known.
For example, the tz region
America/Kentucky/Louisville represents a region
around the city of Louisville, the boundaries of which are
unclear.
tz
database were often spread out over hours, days, or even decades.
tz database requires.
tz code can handle.
For example, from 1909 to 1937 Netherlands clocks were legally Amsterdam Mean
Time (estimated to be UT
+00:19:32.13), but the tz
code cannot represent the fractional second.
In practice these old specifications were rarely if ever
implemented to subsecond precision.
tz database are correct, the
tz rules that generate them may not
faithfully reflect the historical rules.
For example, from 1922 until World War II the UK moved clocks
forward the day following the third Saturday in April unless that
was Easter, in which case it moved clocks forward the previous
Sunday.
Because the tz database has no
way to specify Easter, these exceptional years are entered as
separate tz Rule lines, even though the
legal rules did not change.
tz database models pre-standard time
using the proleptic
Gregorian calendar and local mean time, but many people used
other calendars and other timescales.
For example, the Roman Empire used
the Julian
calendar,
and Roman
timekeeping had twelve varying-length daytime hours with a
non-hour-based system at night.
tz database assumes Universal Time
(UT) as an origin, even though UT is not
standardized for older timestamps.
In the tz database commentary,
UT denotes a family of time standards that includes
Coordinated Universal Time (UTC) along with other
variants such as UT1 and GMT,
with days starting at midnight.
Although UT equals UTC for modern
timestamps, UTC was not defined until 1960, so
commentary uses the more-general abbreviation UT for
timestamps that might predate 1960.
Since UT, UT1, etc. disagree slightly,
and since pre-1972 UTC seconds varied in length,
interpretation of older timestamps can be problematic when
subsecond accuracy is needed.
tz database does not represent how
uncertain its information is.
Ideally it would contain information about when data entries are
incomplete or dicey.
Partial temporal knowledge is a field of active research, though,
and it is not clear how to apply it here.
d617 11
d629 2
d632 2
a633 28
In short, many, perhaps most, of the tz
database's pre-1970 and future timestamps are either wrong or
misleading.
Any attempt to pass the
tz database off as the definition of time
should be unacceptable to anybody who cares about the facts.
In particular, the tz database's
LMT offsets should not be considered meaningful, and
should not prompt creation of tz regions
merely because two locations
differ in LMT or transitioned to standard time at
different dates.
The tz code contains time and date functions
that are upwards compatible with those of POSIX.
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.
d636 3
a638 1
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.
a648 1
d650 1
a650 1
The POSIX TZ string takes the following form:
a651 1
d653 1
a653 1
stdoffset[dst[offset][,date[/time],date[/time]]]
a654 1
d656 1
a656 3
where:
d659 6
a664 5
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.
d667 5
a671 7
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.
d674 3
a676 4
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.
d679 5
a683 5
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.
d686 1
a686 1
takes one of the following forms:
d689 2
a690 2
origin-1 day number not counting February 29
d692 14
a705 13
origin-0 day number counting February 29 if present
Mm.n.d
(0[Sunday]≤d≤6[Saturday], 1≤n≤5,
1≤m≤12)5' stands for the last week in which
day d appears (which may be either the 4th or
5th week).
Typically, this is the only useful form; the n
and Jn forms are rarely used.
d707 66
a772 76
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'TZ values like
"EST5EDT".
Typically the current US DST rules
are used to interpret such values, but this means that the
US DST rules are compiled into each
program that does time conversion.
This means that when
US time conversion rules change (as in the United
States in 1987), all programs that do time conversion must be
recompiled to ensure proper results.
TZ environment variable is process-global, which
makes it hard to write efficient, thread-safe applications that
need access to multiple time zone rulesets.
TZ environment variable.
While an administrator can "do everything in UT" to
get around the problem, doing so is inconvenient and precludes
handling daylight saving time shifts - as might be required to
limit phone calls to off-peak hours.)
tz regions
that do not fit into the POSIX model.
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.
d775 3
a777 3
tz codeTZ 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.
d792 13
a804 14
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).
d806 51
a856 45
struct tm, e.g., tm_gmtoff.
struct tm, e.g., tm_zone.
tzalloc, tzfree,
localtime_rz, and mktime_z for
more-efficient thread-safe applications that need to use multiple
time zone rulesets.
The tzalloc and tzfree functions
allocate and free objects of type timezone_t,
and localtime_rz and mktime_z are
like localtime_r and mktime with an
extra timezone_t argument.
The functions were inspired by NetBSD.
tzsetwall has been added to arrange for the
system's best approximation to local wall clock time to be delivered
by subsequent calls to localtime.
Source code for portable applications that "must" run on local wall
clock time should call tzsetwall;
if such code is moved to "old" systems that 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.)
time_t values are supported, on systems
where time_t is signed.
tz code supports these
vestigial APIs for backwards compatibility, they should
be avoided in portable applications.
The vestigial APIs are:
d863 37
a899 27
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.
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.
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.
d902 21
a923 57
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.
gettimeofday function is not
used in this package.
This formerly let users obtain the current UTC offset
and DST flag, but this functionality was removed in
later versions of BSD.
time_t values when doing conversions
for places that 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.
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.
tz code and data supply the following interfaces:
a929 1
d932 2
a933 2
A set of tz region names as per
"Names of time zone rulesets" above.
d936 2
a937 2
Library functions described in "Time and date
functions" above.
d940 2
a941 2
The programs tzselect, zdump,
and zic, documented in their man pages.
d944 2
a945 2
The format of zic input files, documented in
the zic man page.
d948 2
a949 2
The format of zic output files, documented in
the tzfile man page.
d952 1
a952 1
The format of zone table files, documented in zone1970.tab.
d955 1
a955 1
The format of the country code file, documented in iso3166.tab.
d958 2
a959 2
The version number of the code and data, as the first line of
the text file 'version' in each release.
a961 1
d964 6
a969 7
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.
d973 4
a976 4
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.
d978 1
a978 1
calendars'
in the tz distribution.
They sometimes disagree.
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.
d1010 3
a1012 3
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.
d1016 4
a1019 8
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).
d1025 6
a1030 8
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.
d1035 1
a1035 2
wide acceptance.
Astronomers often use Mars Sol Date (MSD) which is a
d1037 1
a1037 1
12:00 GMT.
d1042 11
a1052 17
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.
d1056 2
a1057 3
Although the tz database does not support
time on other planets, it is documented here in the hopes that support
will be added eventually.
d1061 1
a1061 1
Sources for time on other planets:
a1062 1
d1065 4
a1068 4
Michael Allison and Robert Schmunk,
"Technical
Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"
(2015-06-30).
d1071 4
a1074 4
Jia-Rui Chong,
"Workdays
Fit for a Martian", Los Angeles Times
(2004-01-14), pp A1, A20–A21.
d1077 3
a1079 3
Tom Chmielewski,
"Jet
Lag Is Worse on Mars", The Atlantic (2015-02-26)
d1082 4
a1085 4
Matt Williams,
"How
long is a day on the other planets of the solar system?"
(2017-04-27).
d1088 1
a1088 1
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,
d76 1
a76 1
A tz timezone corresponds to a ruleset that can
d80 4
a83 4
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.
d89 1
a89 1
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
d99 1
a99 4
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
"乌日哥罗德".
d109 1
a109 1
Uniquely identify every timezone where clocks have agreed since 1970.
d114 1
a114 1
Indicate to experts where the timezone's clocks typically are.
d134 3
a136 2
AREA is a continent or ocean, and
LOCATION is a specific location within the area.
d147 1
a147 1
choosing timezone names,
d199 3
a201 3
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.
d215 1
a215 1
timezones.
d223 1
a223 1
Europe/Rome to Europa/Roma, and
d225 2
a226 2
Ευρώπη/Αθήνα or the Romanized
Evrópi/Athína.
d277 1
a277 1
to name timezones.
d279 1
a279 1
regions as described above; this is a subset of the timezones in the data.
a400 1
PST/PDT Philippine,
d456 1
a456 1
GMT/BST established for time in the UK.
d476 1
a476 1
-05 and +0530 that are generated
d491 2
a492 2
Use a consistent style in a timezone's history.
For example, if a history tends to use numeric
d504 1
a504 1
RFC 3339.
d546 1
a546 1
Thousands more timezones would be needed if
d611 1
a611 1
earliest time for which a timezone's
d617 1
a617 1
For many timezones the earliest time of
d623 1
a623 1
For example, the timezone
a666 5
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.
d669 1
a669 1
The tz database models time
d672 2
a673 4
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.
a679 13
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.
d713 1
a713 1
Measurement of
d749 1
a749 1
should not prompt creation of timezones
d801 1
a801 1
and daylight saving time (DST) zone abbreviations.
d873 1
a873 2
POSIX does not define the DST transitions
for TZ values like
d875 7
a881 6
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
d887 1
a887 1
need access to multiple timezones.
d892 1
a892 1
This is important for applications that an administrator wants
d898 2
a899 2
handling daylight saving time shifts – as might be required to
limit phone calls to off-peak hours.
d904 1
a904 1
timestamps, particularly for timezones
d922 1
a922 1
floating-point type, this was not supported by any practical system,
d934 1
a934 1
the name of a file from which time-related information is read
d936 3
a938 4
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.
d940 3
a942 3
particular timezone are encoded in the
TZif file; the format of the file allows US,
Australian, and other rules to be encoded, and
d952 1
a952 1
to hold the string used to generate the TZif file's name.
d958 3
a960 3
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.
d975 1
a975 1
timezones.
d1096 2
a1097 3
Other time conversion proposals, in particular those supported by the
Time Zone
Database Parser, offer a wider selection of functions
d1119 2
a1120 2
A set of timezone names as per
"Names of timezones" above.
d1189 1
a1189 1
use Mars time.
d1221 1
a1221 1
solar timekeeping, so there is no real standard for Mars time zones.
d1293 1
a1293 1
(2016-01-20).
@
1.2.2.3
log
@Sync with HEAD, resolve a couple of conflicts
@
text
@d410 1
a410 1
HST/HDT/HWT/HPT Hawaii,
@
1.2.2.4
log
@Synch with HEAD
@
text
@d409 1
a409 1
GST/GDT Guam,
d1241 1
a1241 1
Mars
d1264 2
a1265 1
called Mars Coordinated Time (MTC).
@
1.1
log
@Welcome to 2017c:
zic and the reference runtime now reject multiple leap seconds
within 28 days of each other, or leap seconds before the Epoch.
As a result, support for double leap seconds, which was
obsolescent and undocumented, has been removed. Double leap
seconds were an error in the C89 standard; they have never existed
in civil timekeeping. (Thanks to Robert Elz and Bradley White for
noticing glitches in the code that uncovered this problem.)
zic now warns about use of the obsolescent and undocumented -y
option, and about use of the obsolescent TYPE field of Rule lines.
zic now allows unambiguous abbreviations like "Sa" and "Su" for
weekdays; formerly it rejected them due to a bug. Conversely, zic
no longer considers non-prefixes to be abbreviations; for example,
it no longer accepts "lF" as an abbreviation for "lastFriday".
Also, zic warns about the undocumented usage with a "last-"
prefix, e.g., "last-Fri".
Similarly, zic now accepts the unambiguous abbreviation "L" for
"Link" in ordinary context and for "Leap" in leap-second context.
Conversely, zic no longer accepts non-prefixes such as "La" as
abbreviations for words like "Leap".
zic no longer accepts leap second lines in ordinary input, or
ordinary lines in leap second input. Formerly, zic sometimes
warned about this undocumented usage and handled it incorrectly.
The new macro HAVE_TZNAME governs whether the tzname external
variable is exported, instead of USG_COMPAT. USG_COMPAT now
governs only the external variables "timezone" and "daylight".
This change is needed because the three variables are not in the
same category: although POSIX requires tzname, it specifies the
other two variables as optional. Also, USG_COMPAT is now 1 or 0:
if not defined, the code attempts to guess it from other macros.
localtime.c and difftime.c no longer require stdio.h, and .c files
other than zic.c no longer require sys/wait.h.
zdump.c no longer assumes snprintf. (Reported by Jonathan Leffler.)
Calculation of time_t extrema works around a bug in GCC 4.8.4
(Reported by Stan Shebs and Joseph Myers.)
zic.c no longer mistranslates formats of line numbers in non-English
locales. (Problem reported by Benno Schulenberg.)
Several minor changes have been made to the code to make it a
bit easier to port to MS-Windows and Solaris. (Thanks to Kees
Dekker for reporting the problems.)
Changes to documentation and commentary
The two new files 'theory.html' and 'calendars' contain the
contents of the removed file 'Theory'. The goal is to document
tzdb theory more accessibly.
The zic man page now documents abbreviation rules.
tz-link.htm now covers how to apply tzdata changes to clients.
(Thanks to Jorge Fábregas for the AIX link.) It also mentions MySQL.
The leap-seconds.list URL has been updated to something that is
more reliable for tzdb. (Thanks to Tim Parenti and Brian Inglis.)
@
text
@d55 4
d247 1
a247 1
corresponds to its LMT offset with one hour for every 15 degrees east
d286 1
a286 1
Use three or more characters that are ASCII alphanumerics or
d304 1
a304 1
expression [-+[:alnum:]]{3,} should match
d315 43
d361 44
a404 3
traditional xMT notation, e.g. 'PMT' for
Paris Mean Time.
The only name like this in current use is 'GMT'.
a430 26
[The remaining guidelines predate the introduction of %z.
They are problematic as they mean tz data entries invent
notation rather than record it. These guidelines are now
deprecated and the plan is to gradually move to %z for
inhabited locations and to "-00" for uninhabited locations.]
-0600' instead of time zone
abbreviations like 'CST'; this avoids the ambiguity.
d453 1
a453 1
Corrections are welcome and encouraged; see the file CONTRIBUTING.
d663 1
a663 1
in a quoted form like '<UTC+10>'; this allows
d711 1
a711 1
It says that standard time (NZST) is 12 hours ahead of UTC,
d743 1
a743 1
variable. While an administrator can "do everything in UTC" to get
d967 1
a967 1
files. Sources for time zone and daylight
d1068 1
a1068 1
(2012-08-08).
@