Names of time zone rules

Names of time zone rulesets

-Each of the database's time zone rules has a unique name. +Each tz region has a unique name that +corresponds to a set of time zone rules. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains the names; for one example, see the 'tzselect' @@ -87,7 +100,7 @@ interfaces.

-The time zone rule naming conventions attempt to strike a balance +The naming conventions attempt to strike a balance among the following goals:

@@ -127,7 +140,8 @@ Typical names are 'Africa/Cairo',

-Here are the general rules used for choosing location names, +Here are the general guidelines used for +choosing tz region names, in decreasing order of importance:

@@ -192,8 +206,8 @@ in decreasing order of importance:

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. + future changes do not split individual locations into different + tz regions. E.g., prefer 'Paris' to 'France', since France has had multiple time zones. @@ -202,10 +216,10 @@ in decreasing order of importance: 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. + The POSIX file name restrictions encourage this guideline.

- Use the most populous among locations in a zone, + Use the most populous among locations in a region, e.g., prefer 'Shanghai' to 'Beijing'. Among locations with similar populations, pick the best-known @@ -235,7 +249,7 @@ in decreasing order of importance:

Do not change established names if they only marginally violate - the above rules. + the above guidelines. 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. @@ -249,7 +263,7 @@ in decreasing order of importance:

The file 'zone1970.tab' lists geographical locations used -to name time zone rules. +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 @@ -272,7 +286,7 @@ The other old-fashioned names still supported are

Older versions of this package defined legacy names that are -incompatible with the first rule of location names, but which are +incompatible with the first guideline of location names, but which are still supported. These legacy names are mostly defined in the file 'etcetera'. @@ -295,7 +309,7 @@ If 'backward' is excluded, excluding

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, +Here are the general guidelines used for choosing time zone abbreviations, in decreasing order of importance:

@@ -309,9 +323,9 @@ in decreasing order of importance: '

set
     `date`

' to have unexpected effects. - Previous editions of this rule required upper-case letters, but the - Congressman who - introduced Chamorro + 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 '-', @@ -383,7 +397,7 @@ in decreasing order of importance:

- For zones whose times are 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 others are for timestamps before 1960, @@ -461,16 +475,17 @@ in decreasing order of importance: usage.

- Use a consistent style in a zone's history. - For example, if a zone's history tends to use numeric + Use a consistent style in a 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.

- Use Universal Time + Use + Universal Time (UT) (with time zone abbreviation '-00') for locations while uninhabited. - The leading '-' is a flag that the time zone is in + The leading '-' is a flag that the UT offset is in some sense undefined; this notation is derived from Internet RFC 3339. @@ -515,7 +530,7 @@ Errors in the tz database arise from many sources: The pre-1970 entries in this database cover only a tiny sliver of how clocks actually behaved; the vast majority of the necessary information was lost or never recorded. - Thousands more zones would be needed if + Thousands more 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 @@ -524,7 +539,8 @@ Errors in the tz database arise from many sources: due to widespread disagreement or indifference about what times should be observed. In her 2015 book - The + The Global Transformation of Time, 1870–1950, Vanessa Ogle writes "Outside of Europe and North America there was no system of time @@ -574,18 +590,19 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes

The tz database does not record the - earliest time for which a zone's + 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 zones the earliest time of validity is unknown. + For many tz regions 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 + For example, the tz region America/Kentucky/Louisville represents a region around the city of Louisville, the boundaries of which are unclear. @@ -711,7 +728,8 @@ Any attempt to pass the 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 +should not prompt creation of tz regions +merely because two locations differ in LMT or transitioned to standard time at different dates.

@@ -724,8 +742,7 @@ 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 zone rule -tables. +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 @@ -779,8 +796,8 @@ an older zic.

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; + If this is absent, the system supplies its own ruleset + for DST, and its rules can differ from year to year; typically US DST rules are used.

time

@@ -849,7 +866,7 @@ an older zic.

The TZ environment variable is process-global, which makes it hard to write efficient, thread-safe applications that - need access to multiple time zones. + need access to multiple time zone rulesets.

In POSIX, there's no tamper-proof way for a process to learn the @@ -866,8 +883,8 @@ an older zic.

POSIX provides no convenient and efficient way to determine the UT offset and time zone abbreviation of arbitrary - timestamps, particularly for time zone settings that do not fit - into the POSIX model. + timestamps, particularly for tz regions + that do not fit into the POSIX model.

POSIX requires that systems ignore leap seconds. @@ -896,13 +913,14 @@ an older zic.

The TZ environment variable is used in generating - the name of a file from which time zone information is read + 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 - 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 + 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. @@ -913,7 +931,7 @@ an older zic. 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. + 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 @@ -936,7 +954,7 @@ an older zic. Functions tzalloc, tzfree, localtime_rz, and mktime_z for more-efficient thread-safe applications that need to use multiple - time zones. + time zone rulesets. The tzalloc and tzfree functions allocate and free objects of type timezone_t, and localtime_rz and mktime_z are @@ -953,7 +971,7 @@ an older zic. 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 + (These 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 @@ -997,7 +1015,7 @@ The vestigial APIs are: 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. + specification if a string like "+0900" suffices.

The tm_isdst member is almost never needed and most of @@ -1076,8 +1094,8 @@ The tz code and data supply the following interfaces:

- A set of zone names as per "Names of time zone - rules" above. + A set of tz region names as per + "Names of time zone rulesets" above.
Library functions described in "Time and date @@ -1136,7 +1154,7 @@ An excellent resource in this area is Nachum Dershowitz and Edward M. Reingold, Calendrical Calculations: Third Edition, Cambridge University Press (2008). -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.
-- 2.14.3