84d9c625bf
- Fix for possible unset uid/gid in toproto
- Fix for default mtree style
- Update libelf
- Importing libexecinfo
- Resynchronize GCC, mpc, gmp, mpfr
- build.sh: Replace params with show-params.
This has been done as the make target has been renamed in the same
way, while a new target named params has been added. This new
target generates a file containing all the parameters, instead of
printing it on the console.
- Update test48 with new etc/services (Fix by Ben Gras <ben@minix3.org)
get getservbyport() out of the inner loop
Change-Id: Ie6ad5226fa2621ff9f0dee8782ea48f9443d2091
751 lines
33 KiB
Text
751 lines
33 KiB
Text
This file is in the public domain, so clarified as of
|
|
2009-05-17 by Arthur David Olson.
|
|
|
|
----- Outline -----
|
|
|
|
Time and date functions
|
|
Scope of the tz database
|
|
Names of time zone rule files
|
|
Time zone abbreviations
|
|
Calendrical issues
|
|
Time and time zones on Mars
|
|
|
|
----- Time and date functions -----
|
|
|
|
These time and date functions are upwards compatible with those of 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, 2013 Edition
|
|
<http://pubs.opengroup.org/onlinepubs/9699919799/>
|
|
|
|
POSIX has the following properties and limitations.
|
|
|
|
* In POSIX, time display in a process is controlled by the
|
|
environment variable TZ. Unfortunately, the POSIX TZ string takes
|
|
a form that is hard to describe and is error-prone in practice.
|
|
Also, POSIX TZ strings can't deal with other (for example, Israeli)
|
|
daylight saving time rules, or situations where more than two
|
|
time zone abbreviations are used in an area.
|
|
|
|
The POSIX TZ string takes the following form:
|
|
|
|
stdoffset[dst[offset][,date[/time],date[/time]]]
|
|
|
|
where:
|
|
|
|
std and dst
|
|
are 3 or more characters specifying the standard
|
|
and daylight saving time (DST) zone names.
|
|
Starting with POSIX.1-2001, std and dst may also be
|
|
in a quoted form like "<UTC+10>"; this allows
|
|
"+" and "-" in the names.
|
|
offset
|
|
is of the form '[+-]hh:[mm[:ss]]' and specifies the
|
|
offset west of UT. 'hh' may be a single digit; 0<=hh<=24.
|
|
The default DST offset is one hour ahead of standard time.
|
|
date[/time],date[/time]
|
|
specifies the beginning and end of DST. If this is absent,
|
|
the system supplies its own rules for DST, and these can
|
|
differ from year to year; typically US DST rules are used.
|
|
time
|
|
takes the form 'hh:[mm[:ss]]' and defaults to 02:00.
|
|
This is the same format as the offset, except that a
|
|
leading '+' or '-' is not allowed.
|
|
date
|
|
takes one of the following forms:
|
|
Jn (1<=n<=365)
|
|
origin-1 day number not counting February 29
|
|
n (0<=n<=365)
|
|
origin-0 day number counting February 29 if present
|
|
Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12)
|
|
for the dth day of week n of month m of the year,
|
|
where week 1 is the first week in which day d appears,
|
|
and '5' stands for the last week in which day d appears
|
|
(which may be either the 4th or 5th week).
|
|
Typically, this is the only useful form;
|
|
the n and Jn forms are rarely used.
|
|
|
|
Here is an example POSIX TZ string, for US Pacific time using rules
|
|
appropriate from 1987 through 2006:
|
|
|
|
TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00'
|
|
|
|
This POSIX TZ string is hard to remember, and mishandles time stamps
|
|
before 1987 and after 2006. With this package you can use this
|
|
instead:
|
|
|
|
TZ='America/Los_Angeles'
|
|
|
|
* POSIX does not define the exact meaning of TZ values like "EST5EDT".
|
|
Typically the current US DST rules are used to interpret such values,
|
|
but this means that the US DST rules are compiled into each program
|
|
that does time conversion. This means that when US time conversion
|
|
rules change (as in the United States in 1987), all programs that
|
|
do time conversion must be recompiled to ensure proper results.
|
|
|
|
* In POSIX, there's no tamper-proof way for a process to learn the
|
|
system's best idea of local wall clock. (This is important for
|
|
applications that an administrator wants used only at certain times--
|
|
without regard to whether the user has fiddled the "TZ" environment
|
|
variable. While an administrator can "do everything in UTC" to get
|
|
around the problem, doing so is inconvenient and precludes handling
|
|
daylight saving time shifts--as might be required to limit phone
|
|
calls to off-peak hours.)
|
|
|
|
* POSIX requires that systems ignore leap seconds.
|
|
|
|
* The tz code attempts 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 integers are also used occasionally.
|
|
Although earlier POSIX versions allowed time_t to be a
|
|
floating-point type, this was not supported by any practical
|
|
systems, and POSIX.1-2013 and the tz code both require time_t
|
|
to be an integer type.
|
|
|
|
These are the extensions that have been made to the POSIX functions:
|
|
|
|
* The "TZ" environment variable is used in generating the name of a file
|
|
from which time zone information is read (or is interpreted a la
|
|
POSIX); "TZ" is no longer constrained to be a three-letter time zone
|
|
name followed by a number of hours and an optional three-letter
|
|
daylight time zone name. The daylight saving time rules to be used
|
|
for a particular time zone are encoded in the time zone file;
|
|
the format of the file allows U.S., Australian, and other rules to be
|
|
encoded, and allows for situations where more than two time zone
|
|
abbreviations are used.
|
|
|
|
It was recognized that allowing the "TZ" environment variable to
|
|
take on values such as "America/New_York" might cause "old" programs
|
|
(that expect "TZ" to have a certain form) to operate incorrectly;
|
|
consideration was given to using some other environment variable
|
|
(for example, "TIMEZONE") to hold the string used to generate the
|
|
time zone information file name. In the end, however, it was decided
|
|
to continue using "TZ": it is widely used for time zone purposes;
|
|
separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance;
|
|
and systems where "new" forms of "TZ" might cause problems can simply
|
|
use TZ values such as "EST5EDT" which can be used both by
|
|
"new" programs (a la POSIX) and "old" programs (as zone names and
|
|
offsets).
|
|
|
|
* To handle places where more than two time zone abbreviations are used,
|
|
the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst]
|
|
(where "tmp" is the value the function returns) to the time zone
|
|
abbreviation to be used. This differs from POSIX, where the elements
|
|
of tzname are only changed as a result of calls to tzset.
|
|
|
|
* Since the "TZ" environment variable can now be used to control time
|
|
conversion, the "daylight" and "timezone" variables are no longer
|
|
needed. (These variables are defined and set by "tzset"; however, their
|
|
values will not be used by "localtime.")
|
|
|
|
* The "localtime" function has been set up to deliver correct results
|
|
for near-minimum or near-maximum time_t values. (A comment in the
|
|
source code tells how to get compatibly wrong results).
|
|
|
|
* A function "tzsetwall" has been added to arrange for the system's
|
|
best approximation to local wall clock time to be delivered by
|
|
subsequent calls to "localtime." Source code for portable
|
|
applications that "must" run on local wall clock time should call
|
|
"tzsetwall();" if such code is moved to "old" systems that don't
|
|
provide tzsetwall, you won't be able to generate an executable program.
|
|
(These time zone functions also arrange for local wall clock time to be
|
|
used if tzset is called--directly or indirectly--and there's no "TZ"
|
|
environment variable; portable applications should not, however, rely
|
|
on this behavior since it's not the way SVR2 systems behave.)
|
|
|
|
* Negative time_t values are supported, on systems where time_t is signed.
|
|
|
|
* These functions can account for leap seconds, thanks to Bradley White.
|
|
|
|
Points of interest to folks with other systems:
|
|
|
|
* This package is already part of many POSIX-compliant hosts,
|
|
including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun.
|
|
On such hosts, the primary use of this package
|
|
is to update obsolete time zone rule tables.
|
|
To do this, you may need to compile the time zone compiler
|
|
'zic' supplied with this package instead of using the system 'zic',
|
|
since the format of zic's input changed slightly in late 1994,
|
|
and many vendors still do not support the new input format.
|
|
|
|
* The UNIX Version 7 "timezone" function is not present in this package;
|
|
it's impossible to reliably map timezone's arguments (a "minutes west
|
|
of GMT" value and a "daylight saving time in effect" flag) to a
|
|
time zone abbreviation, and we refuse to guess.
|
|
Programs that in the past used the timezone function may now examine
|
|
tzname[localtime(&clock)->tm_isdst] to learn the correct time
|
|
zone abbreviation to use. Alternatively, use
|
|
localtime(&clock)->tm_zone if this has been enabled.
|
|
|
|
* The 4.2BSD gettimeofday function is not used in this package.
|
|
This formerly let users obtain the current UTC offset and DST flag,
|
|
but this functionality was removed in later versions of BSD.
|
|
|
|
* In SVR2, time conversion fails for near-minimum or near-maximum
|
|
time_t values when doing conversions for places that don't use UT.
|
|
This package takes care to do these conversions correctly.
|
|
|
|
The functions that are conditionally compiled if STD_INSPIRED is defined
|
|
should, at this point, be looked on primarily as food for thought. They are
|
|
not in any sense "standard compatible"--some are not, in fact, specified in
|
|
*any* standard. They do, however, represent responses of various authors to
|
|
standardization proposals.
|
|
|
|
Other time conversion proposals, in particular the one developed by folks at
|
|
Hewlett Packard, offer a wider selection of functions that provide capabilities
|
|
beyond those provided here. The absence of such functions from this package
|
|
is not meant to discourage the development, standardization, or use of such
|
|
functions. Rather, their absence reflects the decision to make this package
|
|
contain valid extensions to POSIX, to ensure its broad acceptability. If
|
|
more powerful time conversion functions can be standardized, so much the
|
|
better.
|
|
|
|
|
|
----- Scope of the tz database -----
|
|
|
|
The tz database attempts to record the history and predicted future of
|
|
all computer-based clocks that track civil time. To represent this
|
|
data, the world is partitioned into regions whose clocks all agree
|
|
about time stamps that occur after the somewhat-arbitrary cutoff point
|
|
of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region,
|
|
the database records all known clock transitions, and labels the region
|
|
with a notable location. Although 1970 is a somewhat-arbitrary
|
|
cutoff, there are significant challenges to moving the cutoff earlier
|
|
even by a decade or two, due to the wide variety of local practices
|
|
before computer timekeeping became prevalent.
|
|
|
|
Clock transitions before 1970 are recorded for each such location,
|
|
because most POSIX-compatible systems support negative time stamps and
|
|
could misbehave if data 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.
|
|
|
|
|
|
----- Accuracy of the tz database -----
|
|
|
|
The tz database is not authoritative, and it surely has errors.
|
|
Corrections are welcome and encouraged. Users requiring authoritative
|
|
data should consult national standards bodies and the references cited
|
|
in the database's comments.
|
|
|
|
Errors in the tz database arise from many sources:
|
|
|
|
* The tz database predicts future time stamps, and current predictions
|
|
will be incorrect after future governments change the rules.
|
|
For example, if today someone schedules a meeting for 13:00 next
|
|
October 1, Casablanca time, and tomorrow Morocco changes its
|
|
daylight saving rules, software can mess up after the rule change
|
|
if it blithely relies on conversions made before the change.
|
|
|
|
* The pre-1970 data in this database cover only a tiny sliver of how
|
|
clocks actually behaved; the vast majority of the necessary
|
|
information was lost or never recorded. Thousands more zones would
|
|
be needed if the tz database's scope were extended to cover even
|
|
just the known or guessed history of standard time; for example,
|
|
the current single entry for France would need to split into dozens
|
|
of entries, perhaps hundreds.
|
|
|
|
* Most of the pre-1970 data comes from unreliable sources, often
|
|
astrology books that lack citations and whose compilers evidently
|
|
invented entries when the true facts were unknown, without
|
|
reporting which entries were known and which were invented.
|
|
These books often contradict each other or give implausible entries,
|
|
and on the rare occasions when their old data are checked they are
|
|
typically found to be incorrect.
|
|
|
|
* For the UK the tz database relies on years of first-class work done by
|
|
Joseph Myers and others; see <http://www.polyomino.org.uk/british-time/>.
|
|
Other countries are not done nearly as well.
|
|
|
|
* Sometimes, different people in the same city would maintain clocks
|
|
that differed significantly. Railway time was used by railroad
|
|
companies (which did not always agree with each other),
|
|
church-clock time was used for birth certificates, etc.
|
|
Often this was merely common practice, but sometimes it was set by law.
|
|
For example, from 1891 to 1911 the UT offset in France was legally
|
|
0:09:21 outside train stations and 0:04:21 inside.
|
|
|
|
* Although a named location in the tz database stands for the
|
|
containing region, its pre-1970 data entries are often accurate for
|
|
only a small subset of that region. For example, Europe/London
|
|
stands for the United Kingdom, but its pre-1847 times are valid
|
|
only for locations that have London's exact meridian, and its 1847
|
|
transition to GMT is known to be valid only for the L&NW and the
|
|
Caledonian railways.
|
|
|
|
* The tz database does not record the earliest time for which a
|
|
zone's data is thereafter valid for every location in the region.
|
|
For example, Europe/London is valid for all locations in its
|
|
region after GMT was made the standard time, but the date of
|
|
standardization (1880-08-02) is not in the tz database, other than
|
|
in commentary. For many zones the earliest time of validity is
|
|
unknown.
|
|
|
|
* The tz database does not record a region's boundaries, and in many
|
|
cases the boundaries are not known. For example, the zone
|
|
America/Kentucky/Louisville represents a region around the city of
|
|
Louisville, the boundaries of which are unclear.
|
|
|
|
* Changes that are modeled as instantaneous transitions in the tz
|
|
database were often spread out over hours, days, or even decades.
|
|
|
|
* Even if the time is specified by law, locations sometimes
|
|
deliberately flout the law.
|
|
|
|
* Early timekeeping practices, even assuming perfect clocks, were
|
|
often not specified to the accuracy that the tz database requires.
|
|
|
|
* Sometimes historical timekeeping was specified more precisely
|
|
than what the tz database can handle. For example, from 1909 to
|
|
1937 Netherlands clocks were legally UT+00:19:32.13, but the tz
|
|
database cannot represent the fractional second.
|
|
|
|
* Even when all the timestamp transitions recorded by the tz database
|
|
are correct, the tz rules that generate them may not faithfully
|
|
reflect the historical rules. For example, from 1922 until World
|
|
War II the UK moved clocks forward the day following the third
|
|
Saturday in April unless that was Easter, in which case it moved
|
|
clocks forward the previous Sunday. Because the tz database has no
|
|
way to specify Easter, these exceptional years are entered as
|
|
separate tz Rule lines, even though the legal rules did not change.
|
|
|
|
* The tz database models pre-standard time using the Gregorian
|
|
calendar and local mean time (LMT), but many people used other
|
|
calendars and other timescales. For example, the Roman Empire used
|
|
the Julian calendar, and had 12 varying-length daytime hours with a
|
|
non-hour-based system at night.
|
|
|
|
* Early clocks were less reliable, and the data do not represent this
|
|
unreliability.
|
|
|
|
* As for leap seconds, civil time was not based on atomic time before
|
|
1972, and we don't know the history of earth's rotation accurately
|
|
enough to map SI seconds to historical solar time to more than
|
|
about one-hour accuracy. See: Morrison LV, Stephenson FR.
|
|
Historical values of the Earth's clock error Delta T and the
|
|
calculation of eclipses. J Hist Astron. 2004;35:327-36
|
|
<http://adsabs.harvard.edu/full/2004JHA....35..327M>;
|
|
Historical values of the Earth's clock error. J Hist Astron. 2005;36:339
|
|
<http://adsabs.harvard.edu/full/2005JHA....36..339M>.
|
|
|
|
* The relationship between POSIX time (that is, UTC but ignoring leap
|
|
seconds) and UTC is not agreed upon after 1972. Although the POSIX
|
|
clock officially stops during an inserted leap second, at least one
|
|
proposed standard has it jumping back a second instead; and in
|
|
practice POSIX clocks more typically either progress glacially during
|
|
a leap second, or are slightly slowed while near a leap second.
|
|
|
|
* The tz database does not represent how uncertain its information is.
|
|
Ideally it would contain information about when the data are
|
|
incomplete or dicey. Partial temporal knowledge is a field of
|
|
active research, though, and it's not clear how to apply it here.
|
|
|
|
In short, many, perhaps most, of the tz database's pre-1970 and future
|
|
time stamps 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.
|
|
|
|
|
|
----- Names of time zone rule files -----
|
|
|
|
The time zone rule file naming conventions attempt to strike a balance
|
|
among the following goals:
|
|
|
|
* Uniquely identify every national region where clocks have all
|
|
agreed since 1970. This is essential for the intended use: static
|
|
clocks keeping local civil time.
|
|
|
|
* Indicate to humans as to where that region is. This simplifies use.
|
|
|
|
* Be robust in the presence of political changes. This reduces the
|
|
number of updates and backward-compatibility hacks. For example,
|
|
names of countries are ordinarily not used, to avoid
|
|
incompatibilities when countries change their name
|
|
(e.g. Zaire->Congo) or when locations change countries
|
|
(e.g. Hong Kong from UK colony to China).
|
|
|
|
* Be portable to a wide variety of implementations.
|
|
This promotes use of the technology.
|
|
|
|
* Use a consistent naming convention over the entire world.
|
|
This simplifies both use and maintenance.
|
|
|
|
This naming convention is not intended for use by inexperienced users
|
|
to select TZ values by themselves (though they can of course examine
|
|
and reuse existing settings). Distributors should provide
|
|
documentation and/or a simple selection interface that explains the
|
|
names; see the 'tzselect' program supplied with this distribution for
|
|
one example.
|
|
|
|
Names normally have the form AREA/LOCATION, where AREA is the name
|
|
of a continent or ocean, and LOCATION is the name of a specific
|
|
location within that region. North and South America share the same
|
|
area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York',
|
|
and 'Pacific/Honolulu'.
|
|
|
|
Here are the general rules used for choosing location names,
|
|
in decreasing order of importance:
|
|
|
|
Use only valid POSIX file name components (i.e., the parts of
|
|
names other than '/'). Do not use the file name
|
|
components '.' and '..'. Within a file name component,
|
|
use only ASCII letters, '.', '-' and '_'. Do not use
|
|
digits, as that might create an ambiguity with POSIX
|
|
TZ strings. A file name component must not exceed 14
|
|
characters or start with '-'. E.g., prefer 'Brunei'
|
|
to 'Bandar_Seri_Begawan'.
|
|
A name must not be empty, or contain '//', or start or end with '/'.
|
|
Do not use names that differ only in case. Although the reference
|
|
implementation is case-sensitive, some other implementations
|
|
are not, and they would mishandle names differing only in case.
|
|
If one name A is an initial prefix of another name AB (ignoring case),
|
|
then B must not start with '/', as a regular file cannot have
|
|
the same name as a directory in POSIX. For example,
|
|
'America/New_York' precludes 'America/New_York/Bronx'.
|
|
Uninhabited regions like the North Pole and Bouvet Island
|
|
do not need locations, since local time is not defined there.
|
|
There should typically be at least one name for each ISO 3166-1
|
|
officially assigned two-letter code for an inhabited country
|
|
or territory.
|
|
If all the clocks in a region have agreed since 1970,
|
|
don't bother to include more than one location
|
|
even if subregions' clocks disagreed before 1970.
|
|
Otherwise these tables would become annoyingly large.
|
|
If a name is ambiguous, use a less ambiguous alternative;
|
|
e.g. many cities are named San Jose and Georgetown, so
|
|
prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.
|
|
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.
|
|
Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and
|
|
prefer 'Athens' to the true name (which uses Greek letters).
|
|
The POSIX file name restrictions encourage this rule.
|
|
Use the most populous among locations in a zone,
|
|
e.g. prefer 'Shanghai' to 'Beijing'. Among locations with
|
|
similar populations, pick the best-known location,
|
|
e.g. prefer 'Rome' to 'Milan'.
|
|
Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
|
|
Omit common suffixes like '_Islands' and '_City', unless that
|
|
would lead to ambiguity. E.g. prefer 'Cayman' to
|
|
'Cayman_Islands' and 'Guatemala' to 'Guatemala_City',
|
|
but prefer 'Mexico_City' to 'Mexico' because the country
|
|
of Mexico has several time zones.
|
|
Use '_' to represent a space.
|
|
Omit '.' from abbreviations in names, e.g. prefer 'St_Helena'
|
|
to 'St._Helena'.
|
|
Do not change established names if they only marginally
|
|
violate the above rules. For example, don't change
|
|
the existing name 'Rome' to 'Milan' merely because
|
|
Milan's population has grown to be somewhat greater
|
|
than Rome's.
|
|
If a name is changed, put its old spelling in the 'backward' file.
|
|
This means old spellings will continue to work.
|
|
|
|
The file 'zone.tab' lists geographical locations used to name time
|
|
zone rule files. 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 'zone.tab' location's longitude
|
|
corresponds to its LMT offset with one hour for every 15 degrees east
|
|
longitude, this relationship is not exact.
|
|
|
|
Older versions of this package used a different naming scheme,
|
|
and these older names are still supported.
|
|
See the file 'backward' for most of these older names
|
|
(e.g. 'US/Eastern' instead of 'America/New_York');
|
|
excluding 'backward' should not affect the other data.
|
|
The other old-fashioned names still supported are
|
|
'WET', 'CET', 'MET', and 'EET' (see the file 'europe').
|
|
|
|
|
|
----- Time zone abbreviations -----
|
|
|
|
When this package is installed, it generates time zone abbreviations
|
|
like 'EST' to be compatible with human tradition and POSIX.
|
|
Here are the general rules used for choosing time zone abbreviations,
|
|
in decreasing order of importance:
|
|
|
|
Use abbreviations that consist of three or more ASCII letters.
|
|
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 the rule has been relaxed.
|
|
|
|
This rule guarantees that all abbreviations could have
|
|
been specified by a POSIX TZ string. POSIX
|
|
requires at least three characters for an
|
|
abbreviation. POSIX through 2000 says that an abbreviation
|
|
cannot start with ':', and cannot contain ',', '-',
|
|
'+', NUL, or a digit. POSIX from 2001 on changes this
|
|
rule to say that an abbreviation can contain only '-', '+',
|
|
and alphanumeric characters from the portable character set
|
|
in the current locale. To be portable to both sets of
|
|
rules, an abbreviation must therefore use only ASCII
|
|
letters.
|
|
|
|
Use abbreviations that are in common use among English-speakers,
|
|
e.g. 'EST' for Eastern Standard Time in North America.
|
|
We assume that applications translate them to other languages
|
|
as part of the normal localization process; for example,
|
|
a French application might translate 'EST' to 'HNE'.
|
|
|
|
For zones whose times are taken from a city's longitude, use the
|
|
traditional xMT notation, e.g. 'PMT' for Paris Mean Time.
|
|
The only name like this in current use is 'GMT'.
|
|
|
|
If there is no common English abbreviation, abbreviate the English
|
|
translation of the usual phrase used by native speakers.
|
|
If this is not available or is a phrase mentioning the country
|
|
(e.g. "Cape Verde Time"), then:
|
|
|
|
When a country is identified with a single or principal zone,
|
|
append 'T' to the country's ISO code, e.g. 'CVT' for
|
|
Cape Verde Time. For summer time append 'ST';
|
|
for double summer time append 'DST'; etc.
|
|
Otherwise, take the first three letters of an English place
|
|
name identifying each zone and append 'T', 'ST', etc.
|
|
as before; e.g. 'VLAST' for VLAdivostok Summer Time.
|
|
|
|
Use 'LMT' for local mean time of locations before the introduction
|
|
of standard time; see "Scope of the tz database".
|
|
|
|
Use UT (with time zone abbreviation 'zzz') for locations while
|
|
uninhabited. The 'zzz' mnemonic is that these locations are,
|
|
in some sense, asleep.
|
|
|
|
Application writers should note that these abbreviations are ambiguous
|
|
in practice: e.g. 'EST' has a different meaning in Australia than
|
|
it does in the United States. In new applications, it's often better
|
|
to use numeric UT offsets like '-0500' instead of time zone
|
|
abbreviations like 'EST'; this avoids the ambiguity.
|
|
|
|
|
|
----- Calendrical issues -----
|
|
|
|
Calendrical issues are a bit out of scope for a time zone database,
|
|
but they indicate the sort of problems that we would run into if we
|
|
extended the time zone database further into the past. An excellent
|
|
resource in this area is Nachum Dershowitz and Edward M. Reingold,
|
|
<a href="http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/">
|
|
Calendrical Calculations: Third Edition
|
|
</a>, Cambridge University Press (2008). Other information and
|
|
sources are given below. They sometimes disagree.
|
|
|
|
|
|
France
|
|
|
|
Gregorian calendar adopted 1582-12-20.
|
|
French Revolutionary calendar used 1793-11-24 through 1805-12-31,
|
|
and (in Paris only) 1871-05-06 through 1871-05-23.
|
|
|
|
|
|
Russia
|
|
|
|
From Chris Carrier (1996-12-02):
|
|
On 1929-10-01 the Soviet Union instituted an "Eternal Calendar"
|
|
with 30-day months plus 5 holidays, with a 5-day week.
|
|
On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the
|
|
Gregorian calendar while retaining the 6-day week; on 1940-06-27 it
|
|
reverted to the 7-day week. With the 6-day week the usual days
|
|
off were the 6th, 12th, 18th, 24th and 30th of the month.
|
|
(Source: Evitiar Zerubavel, _The Seven Day Circle_)
|
|
|
|
|
|
Mark Brader reported a similar story in "The Book of Calendars", edited
|
|
by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But:
|
|
|
|
From: Petteri Sulonen (via Usenet)
|
|
Date: 14 Jan 1999 00:00:00 GMT
|
|
...
|
|
|
|
If your source is correct, how come documents between 1929 -- 1940 were
|
|
still dated using the conventional, Gregorian calendar?
|
|
|
|
I can post a scan of a document dated December 1, 1934, signed by
|
|
Yenukidze, the secretary, on behalf of Kalinin, the President of the
|
|
Executive Committee of the Supreme Soviet, if you like.
|
|
|
|
|
|
|
|
Sweden (and Finland)
|
|
|
|
From: Mark Brader
|
|
<a href="news:1996Jul6.012937.29190@sq.com">
|
|
Subject: Re: Gregorian reform -- a part of locale?
|
|
</a>
|
|
Date: 1996-07-06
|
|
|
|
In 1700, Denmark made the transition from Julian to Gregorian. Sweden
|
|
decided to *start* a transition in 1700 as well, but rather than have one of
|
|
those unsightly calendar gaps :-), they simply decreed that the next leap
|
|
year after 1696 would be in 1744 -- putting the whole country on a calendar
|
|
different from both Julian and Gregorian for a period of 40 years.
|
|
|
|
However, in 1704 something went wrong and the plan was not carried through;
|
|
they did, after all, have a leap year that year. And one in 1708. In 1712
|
|
they gave it up and went back to Julian, putting 30 days in February that
|
|
year!...
|
|
|
|
Then in 1753, Sweden made the transition to Gregorian in the usual manner,
|
|
getting there only 13 years behind the original schedule.
|
|
|
|
(A previous posting of this story was challenged, and Swedish readers
|
|
produced the following references to support it: "Tiderakning och historia"
|
|
by Natanael Beckman (1924) and "Tid, en bok om tiderakning och
|
|
kalendervasen" by Lars-Olof Lode'n (no date was given).)
|
|
|
|
|
|
Grotefend's data
|
|
|
|
From: "Michael Palmer" [with one obvious typo fixed]
|
|
Subject: Re: Gregorian Calendar (was Re: Another FHC related question
|
|
Newsgroups: soc.genealogy.german
|
|
Date: Tue, 9 Feb 1999 02:32:48 -800
|
|
...
|
|
|
|
The following is a(n incomplete) listing, arranged chronologically, of
|
|
European states, with the date they converted from the Julian to the
|
|
Gregorian calendar:
|
|
|
|
04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman
|
|
Catholics and Danzig only)
|
|
09/20 Dec 1582 - France, Lorraine
|
|
|
|
21 Dec 1582/
|
|
01 Jan 1583 - Holland, Brabant, Flanders, Hennegau
|
|
10/21 Feb 1583 - bishopric of Liege (L"uttich)
|
|
13/24 Feb 1583 - bishopric of Augsburg
|
|
04/15 Oct 1583 - electorate of Trier
|
|
05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg,
|
|
Salzburg, Brixen
|
|
13/24 Oct 1583 - Austrian Oberelsass and Breisgau
|
|
20/31 Oct 1583 - bishopric of Basel
|
|
02/13 Nov 1583 - duchy of J"ulich-Berg
|
|
02/13 Nov 1583 - electorate and city of K"oln
|
|
04/15 Nov 1583 - bishopric of W"urzburg
|
|
11/22 Nov 1583 - electorate of Mainz
|
|
16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden
|
|
17/28 Nov 1583 - bishopric of M"unster and duchy of Cleve
|
|
14/25 Dec 1583 - Steiermark
|
|
|
|
06/17 Jan 1584 - Austria and Bohemia
|
|
11/22 Jan 1584 - Luzern, Uri, Schwyz, Zug, Freiburg, Solothurn
|
|
12/23 Jan 1584 - Silesia and the Lausitz
|
|
22 Jan/
|
|
02 Feb 1584 - Hungary (legally on 21 Oct 1587)
|
|
Jun 1584 - Unterwalden
|
|
01/12 Jul 1584 - duchy of Westfalen
|
|
|
|
16/27 Jun 1585 - bishopric of Paderborn
|
|
|
|
14/25 Dec 1590 - Transylvania
|
|
|
|
22 Aug/
|
|
02 Sep 1612 - duchy of Prussia
|
|
|
|
13/24 Dec 1614 - Pfalz-Neuburg
|
|
|
|
1617 - duchy of Kurland (reverted to the Julian calendar in
|
|
1796)
|
|
|
|
1624 - bishopric of Osnabr"uck
|
|
|
|
1630 - bishopric of Minden
|
|
|
|
15/26 Mar 1631 - bishopric of Hildesheim
|
|
|
|
1655 - Kanton Wallis
|
|
|
|
05/16 Feb 1682 - city of Strassburg
|
|
|
|
18 Feb/
|
|
01 Mar 1700 - Protestant Germany (including Swedish possessions in
|
|
Germany), Denmark, Norway
|
|
30 Jun/
|
|
12 Jul 1700 - Gelderland, Zutphen
|
|
10 Nov/
|
|
12 Dec 1700 - Utrecht, Overijssel
|
|
|
|
31 Dec 1700/
|
|
12 Jan 1701 - Friesland, Groningen, Z"urich, Bern, Basel, Geneva,
|
|
Turgau, and Schaffhausen
|
|
|
|
1724 - Glarus, Appenzell, and the city of St. Gallen
|
|
|
|
01 Jan 1750 - Pisa and Florence
|
|
|
|
02/14 Sep 1752 - Great Britain
|
|
|
|
17 Feb/
|
|
01 Mar 1753 - Sweden
|
|
|
|
1760-1812 - Graub"unden
|
|
|
|
The Russian empire (including Finland and the Baltic states) did not
|
|
convert to the Gregorian calendar until the Soviet revolution of 1917.
|
|
|
|
Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen
|
|
Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend
|
|
(Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28.
|
|
|
|
|
|
----- Time and time zones on Mars -----
|
|
|
|
Some people have adjusted their work schedules to fit Mars time.
|
|
Dozens of special Mars watches were built for Jet Propulsion
|
|
Laboratory workers who kept Mars time during the Mars Exploration
|
|
Rovers mission (2004). These timepieces look like normal Seikos and
|
|
Citizens but use Mars seconds rather than terrestrial seconds.
|
|
|
|
A Mars solar day is called a "sol" and has a mean period equal to
|
|
about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is
|
|
divided into a conventional 24-hour clock, so each Mars second equals
|
|
about 1.02749125 terrestrial seconds.
|
|
|
|
The prime meridian of Mars goes through the center of the crater
|
|
Airy-0, named in honor of the British astronomer who built the
|
|
Greenwich telescope that defines Earth's prime meridian. Mean solar
|
|
time on the Mars prime meridian is called Mars Coordinated Time (MTC).
|
|
|
|
Each landed mission on Mars has adopted a different reference for
|
|
solar time keeping, so there is no real standard for Mars time zones.
|
|
For example, the Mars Exploration Rover project (2004) defined two
|
|
time zones "Local Solar Time A" and "Local Solar Time B" for its two
|
|
missions, each zone designed so that its time equals local true solar
|
|
time at approximately the middle of the nominal mission. Such a "time
|
|
zone" is not particularly suited for any application other than the
|
|
mission itself.
|
|
|
|
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.
|
|
|
|
The tz database does not currently support Mars time, but it is
|
|
documented here in the hopes that support will be added eventually.
|
|
|
|
Sources:
|
|
|
|
Michael Allison and Robert Schmunk,
|
|
"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"
|
|
<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08).
|
|
|
|
Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times
|
|
<http://articles.latimes.com/2004/jan/14/science/sci-marstime14>
|
|
(2004-01-14), pp A1, A20-A21.
|