@@ -118,16 +121,16 @@
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".
+“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
+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 "布拉格".
+locale-dependent strings like “Prague”, “Praha”, “Прага”, and “布拉格”.
@@ -142,13 +145,13 @@
civil time.
- Indicate to experts where the timezone's clocks typically are.
+ Indicate to experts where the timezone’s clocks typically are.
Be robust in the presence of political changes.
For example, names are typically not tied to countries, to avoid
incompatibilities when countries change their name (e.g.,
- Swaziland→Eswatini) or when locations change countries (e.g., Hong
+ Swaziland→Eswatini) or when locations change countries (e.g., Hong
Kong from UK colony to China).
There is no requirement that every country or national
capital must have a timezone name.
@@ -166,11 +169,11 @@
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'.
+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,
+America/Indiana/Petersburg distinguishes Petersburg,
Indiana from other Petersburgs in America.
@@ -183,25 +186,25 @@
Use only valid POSIX file name components (i.e., the parts of
- names other than '/').
- Do not use the file name components '.' and
- '..'.
+ names other than "/").
+ Do not use the file name components "." and
+ "..".
Within a file name component, use only ASCII letters,
- '.', '-' and '_'.
+ ".", "-" and "_".
Do not use digits, as that might create an ambiguity with POSIX's proleptic
- TZ strings.
+ href="https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_03">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.
- A name must not be empty, or contain '//', or
- start or end with '/'.
- Also, a name must not be 'Etc/Unknown', as
+ A name must not be empty, or contain "//", or
+ start or end with "/".
+ Also, a name must not be "Etc/Unknown", as
CLDR uses that string for an unknown or invalid timezone.
@@ -213,7 +216,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
+ 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.
@@ -280,8 +283,8 @@
Atlantic/Canaries.
- Omit common suffixes like '_Islands' and
- '_City', unless that would lead to ambiguity.
+ 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
@@ -292,10 +295,10 @@
country of Mexico has several time zones.
- Use '_' to represent a space.
+ Use "_" to represent a space.
- Omit '.' from abbreviations in names.
+ Omit "." from abbreviations in names.
E.g., prefer Atlantic/St_Helena to
Atlantic/St._Helena.
@@ -303,15 +306,15 @@
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.
+ Europe/Milan merely because Milan’s population has grown
+ to be somewhat greater than Rome’s.
If a name is changed, put its old spelling in the
- 'backward' file as a link to the new spelling.
+ "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,
+ 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.
@@ -327,11 +330,11 @@
Older versions of this package used a different naming scheme.
-See the file 'backward' for most of these older names
-(e.g., 'US/Eastern' instead of 'America/New_York').
+See the file "backward" for most of these older names
+(e.g., US/Eastern instead of America/New_York).
The other old-fashioned names still supported are
-'WET', 'CET', 'MET', and
-'EET' (see the file 'europe').
+WET, CET, MET, and
+EET (see the file "europe").
@@ -339,13 +342,13 @@
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
-'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'.
+"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.
@@ -365,11 +368,11 @@
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
+Although a zone1970.tab location’s
longitude
corresponds to
its local mean
-time (LMT) offset with one hour for every 15°
+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;
@@ -395,7 +398,7 @@
like <+08>-8;
no other source file other than backward
contains links to its zones.
-One of etcetera's names is Etc/UTC,
+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,
@@ -407,7 +410,7 @@
Time zone abbreviations
When this package is installed, it generates time zone abbreviations
-like 'EST' to be compatible with human tradition and POSIX.
+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:
@@ -415,25 +418,24 @@
Use three to six characters that are ASCII alphanumerics or
- '+' or '-'.
+ "+" or "-".
Previous editions of this database also used characters like
- space and '?', but these characters have a
+ space and "?", but these characters have a
special meaning to the
UNIX shell
and cause commands like
- 'set
- `date`'
+ "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
+ 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 practice ASCII alphanumerics and "+" and
+ "-" are safe in all locales.
In other words, in the C locale the POSIX extended regular
@@ -445,10 +447,10 @@
Use abbreviations that are in common use among English-speakers,
- e.g., 'EST' for Eastern Standard Time in North America.
+ e.g., “EST” for Eastern Standard Time in North America.
We assume that applications translate them to other languages
as part of the normal localization process; for example,
- a French application might translate 'EST' to 'HNE'.
+ a French application might translate “EST” to “HNE”.
These abbreviations (for standard/daylight/etc. time) are:
@@ -483,7 +485,7 @@
NST/NDT/NWT/NPT/NDDT Newfoundland,
NST/NDT/NWT/NPT Nome,
NZMT/NZST New Zealand through 1945,
- NZST/NZDT New Zealand 1946–present,
+ NZST/NZDT New Zealand 1946–present,
PKT/PKST Pakistan,
PST/PDT/PWT/PPT Pacific,
PST/PDT Philippine,
@@ -500,12 +502,12 @@
- For times taken from a city's longitude, use the
+ For times taken from a city’s longitude, use the
traditional xMT notation.
- The only abbreviation like this in current use is 'GMT'.
+ 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
+ Typically, numeric abbreviations (e.g., -004430 for
MMT) would cause trouble here, as the numeric strings would exceed
the POSIX length limit.
@@ -546,39 +548,39 @@
A few abbreviations also follow the pattern that
GMT/BST established for time in the UK.
They are:
- BMT/BST for Bermuda 1890–1930,
+ BMT/BST for Bermuda 1890–1930,
CMT/BST for Calamarca Mean Time and Bolivian Summer Time
- 1890–1932,
+ 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.
+ 1880–1916,
+ MMT/MST/MDST for Moscow 1880–1919, and
+ RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926.
- Use 'LMT' for local mean time of locations before the
- introduction of standard time; see "Scope of the
- tz database".
+ Use “LMT” for local mean time of locations before the
+ introduction of standard time; see “Scope of the
+ tz database”.
If there is no common English abbreviation, use numeric offsets like
-05 and +0530 that are generated
- by zic's %z notation.
+ by zic’s %z notation.
Use current abbreviations for older timestamps to avoid confusion.
For example, in 1910 a common English abbreviation for time
- in central Europe was 'MEZ' (short for both "Middle European
- Zone" and for "Mitteleuropäische Zeit" in German).
- Nowadays 'CET' ("Central European Time") is more common in
- English, and the database uses 'CET' even for circa-1910
+ in central Europe was “MEZ” (short for both “Middle European
+ Zone” and for “Mitteleuropäische Zeit” in German).
+ Nowadays “CET” (“Central European Time”) is more common in
+ English, and the database uses “CET” even for circa-1910
timestamps as this is less confusing for modern users and avoids
- the need for determining when 'CET' supplanted 'MEZ' in common
+ the need for determining when “CET” supplanted “MEZ” in common
usage.
- Use a consistent style in a timezone's history.
+ Use a consistent style in a timezone’s history.
For example, if a history tends to use numeric
abbreviations and a particular entry could go either way, use a
numeric abbreviation.
@@ -586,13 +588,13 @@
Use
Universal Time
- (UT) (with time zone abbreviation '-00') for
+ (UT) (with time zone abbreviation -00) for
locations while uninhabited.
- The leading '-' is a flag that the UT offset is in
+ 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
+ (The abbreviation Z that
Internet
RFC 9557 uses for this concept
would violate the POSIX requirement
@@ -602,11 +604,11 @@
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
+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'.
+-0600 instead of time zone abbreviations like CST.
@@ -617,7 +619,7 @@
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.
+bodies and the references cited in the database’s comments.
@@ -639,7 +641,7 @@
clocks actually behaved; the vast majority of the necessary
information was lost or never recorded.
Thousands more timezones would be needed if
- the tz database's scope were extended to
+ 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.
@@ -648,14 +650,14 @@
should be observed.
In her 2015 book
The
- Global Transformation of Time, 1870–1950,
+ href="https://www.hup.harvard.edu/books/9780674286146">The
+ Global Transformation of Time, 1870–1950,
Vanessa Ogle writes
- "Outside of Europe and North America there was no system of time
+ “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".
+ prior to the middle decades of the twentieth century”.
See: Timothy Shenk, Booked:
+href="https://dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle/">Booked:
A Global History of Time. Dissent 2015-12-17.
@@ -697,13 +699,13 @@
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
+ have London’s exact meridian, and its 1847 transition
to GMT is known to be valid only for the L&NW and
the Caledonian railways.
The tz database does not record the
- earliest time for which a timezone's
+ 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,
@@ -714,7 +716,7 @@
The tz database does not record a
- region's boundaries, and in many cases the boundaries are not known.
+ 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
@@ -747,7 +749,7 @@
than what the 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
+ −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.
@@ -787,9 +789,9 @@
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
+ 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
+ href="https://theworld.org/stories/2015/01/30/ethiopian-time">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
@@ -825,16 +827,16 @@
Civil time was not based on atomic time before 1972, and we do not
know the history of
- earth's
+ earth’s
rotation accurately enough to map SI seconds to
historical solar time
to more than about one-hour accuracy.
- See: Stephenson FR, Morrison LV, Hohenkerk CY.
- Measurement of
- the Earth's rotation: 720 BC to AD 2015.
- Proc Royal Soc A. 2016;472:20160404.
+ See: Morrison LV, Stephenson FR, Hohenkerk CY, Zawilski M.
+ Addendum 2020
+ to ‘Measurement of the Earth’s rotation: 720 BC to AD 2015’.
+ Proc Royal Soc A. 2021;477:20200776.
Also see: Espenak F. Uncertainty
in Delta T (ΔT).
@@ -843,7 +845,7 @@
The relationship between POSIX time (that is, UTC but
ignoring leap
seconds) and UTC is not agreed upon.
- This affects time stamps during the leap second era (1972–2035).
+ This affects time stamps during the leap second era (1972–2035).
Although the POSIX
clock officially stops during an inserted leap second, at least one
proposed standard has it jumping back a second instead; and in
@@ -862,12 +864,12 @@
In short, many, perhaps most, of the tz
-database's pre-1970 and future timestamps are either wrong or
+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
+In particular, the tz database’s
LMT offsets should not be considered meaningful, and
should not prompt creation of timezones
merely because two locations
@@ -886,7 +888,7 @@
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
+system zic, since the format of zic’s
input is occasionally extended, and a platform may still be shipping
an older zic.
@@ -914,7 +916,8 @@
POSIX.1-2017 properties and limitations
-Some platforms support only the features required by POSIX.1-2017,
+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.
@@ -956,14 +959,14 @@
are 3 or more characters specifying the standard
and daylight saving time (DST) zone abbreviations.
Starting with POSIX.1-2001, std and dst
- may also be in a quoted form like '<+09>';
+ may also be quoted in angle brackets, like <+09>;
this allows "+" and "-" in the names.
offset
is of the form
- '[±]hh:[mm[:ss]]'
+ [±]hh:[mm[:ss]]
and specifies the offset west of UT.
- 'hh' may be a single digit;
+ hh may be a single digit;
0≤hh≤24.
The default DST offset is one hour ahead of
standard time.
@@ -976,10 +979,10 @@
time
takes the form
- 'hh:[mm[:ss]]'
+ hh:[mm[:ss]]
and defaults to 02:00.
This is the same format as the offset, except that a
- leading '+' or '-' is not allowed.
+ leading "+" or "-" is not allowed.
date
takes one of the following forms:
@@ -996,7 +999,7 @@
for the dth day of week n of
month m of the year, where week 1 is the first
week in which day d appears, and
- '5' stands for the last week in which
+ "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
@@ -1011,8 +1014,8 @@
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:
+ (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'
@@ -1048,11 +1051,11 @@
Earlier POSIX editions lack this requirement.
- DST transition times can range from −167:59:59
+ DST transition times can range from −167:59:59
to 167:59:59 instead of merely from 00:00:00 to 24:59:59.
This allows for proleptic TZ strings
like "<-02>2<-01>,M3.5.0/-1,M10.5.0/0"
- where the transition time −1:00 means 23:00 the previous day.
+ where the transition time −1:00 means 23:00 the previous day.
@@ -1065,14 +1068,14 @@
In POSIX, there is no tamper-proof way for a process to learn the
- system's best idea of local (wall clock) time.
+ system’s best idea of local (wall clock) time.
This is important for applications that an administrator wants
- used only at certain times – without regard to whether the
+ used only at certain times – without regard to whether the
user has fiddled the
TZ environment variable.
- While an administrator can "do everything in UT" to
+ 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
+ handling daylight saving time shifts – as might be required to
limit phone calls to off-peak hours.
@@ -1081,8 +1084,7 @@
POSIX does not define the DST transitions
- for TZ values like
- "EST5EDT".
+ for settings like 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
@@ -1124,9 +1126,9 @@
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,
+ The file’s format is TZif,
a timezone information format that contains binary data; see
- Internet
+ Internet
RFC 9636.
The daylight saving time rules to be used for a
particular timezone are encoded in the
@@ -1138,18 +1140,18 @@
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
+ 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.
+ to hold the string used to generate the TZif file’s name.
In the end, however, it was decided to continue using
TZ: it is widely used for time zone purposes;
separately maintaining both TZ
and TIMEZONE seemed a nuisance; and systems where
- "new" forms of TZ might cause problems can simply
- use legacy TZ values such as "EST5EDT" which
- can be used by "new" programs as well as by "old" programs that
+ 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.
@@ -1192,20 +1194,20 @@
The POSIX 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
+ To get a timestamp’s time zone abbreviation, consult
the tm_zone member if available; otherwise,
- use strftime's "%Z" conversion
+ use strftime’s "%Z" conversion
specification.
The POSIX 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
+ 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
+ or use strftime’s "%z" conversion
specification if a string like "+0900" suffices.
@@ -1230,9 +1232,9 @@
The 7th Edition
UNIXtimezone 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
+ 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
@@ -1262,7 +1264,7 @@
The functions that are conditionally compiled
if 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
+ 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.
@@ -1293,11 +1295,11 @@
The programs tzselect, zdump,
@@ -1319,7 +1321,7 @@
The version number of the code and data, as the first line of
- the text file 'version' in each release.
+ the text file "version" in each release.
@@ -1347,7 +1349,7 @@
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,
+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.
@@ -1381,7 +1383,7 @@
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
+and systems needing more precise UTC can use this package’s leap
second support directly.
@@ -1391,8 +1393,8 @@
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 –
+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
@@ -1402,7 +1404,7 @@
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
+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
@@ -1425,7 +1427,7 @@
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
+in the first place; see the REDO variable in this package’s
makefile.
@@ -1438,9 +1440,9 @@
extended the time zone database further into the past.
An excellent resource in this area is Edward M. Reingold
and Nachum Dershowitz, Calendrical
+href="https://www.cambridge.org/fr/universitypress/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition">Calendrical
Calculations: The Ultimate Edition, Cambridge University Press (2018).
-Other information and sources are given in the file 'calendars'
+Other information and sources are given in the file "calendars"
in the tz distribution.
They sometimes disagree.
@@ -1450,20 +1452,20 @@
Time and time zones off Earth
The European Space Agency is considering
+href="https://www.esa.int/Applications/Satellite_navigation/Telling_time_on_the_Moon">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
+href="https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/04/Celestial-Time-Standardization-Policy.pdf">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
+Some people’s work schedules have used
Mars time.
Jet Propulsion Laboratory (JPL) coordinators kept Mars time on
and off during the
@@ -1473,7 +1475,7 @@
Dozens of special Mars watches were built for JPL workers who kept
Mars time during the
Mars
-Exploration Rovers (MER) mission (2004–2018).
+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
@@ -1481,12 +1483,12 @@
-A Mars solar day is called a "sol" and has a mean period equal to
+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?")
+(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?”)
@@ -1494,7 +1496,7 @@
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.
+defines Earth’s prime meridian.
Mean solar time on the Mars prime meridian is
called Mars Coordinated Time (MTC).
@@ -1502,13 +1504,13 @@
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
+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
+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.
@@ -1522,13 +1524,13 @@
In our solar system, Mars is the planet with time and calendar most
-like Earth's.
+like Earth’s.
On other planets, Sun-based time and calendars would work quite
differently.
-For example, although Mercury's
+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
+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
@@ -1554,8 +1556,8 @@