Annotation of src/lib/libc/time/Theory, Revision 1.20
1.18 christos 1: Theory and pragmatics of the tz code and data
2:
1.2 perry 3:
4: ----- Outline -----
5:
1.10 christos 6: Scope of the tz database
1.18 christos 7: Names of time zone rules
1.2 perry 8: Time zone abbreviations
1.18 christos 9: Accuracy of the tz database
10: Time and date functions
1.4 kleink 11: Calendrical issues
1.8 kleink 12: Time and time zones on Mars
1.2 perry 13:
14:
1.18 christos 15: ----- Scope of the tz database -----
16:
17: The tz database attempts to record the history and predicted future of
18: all computer-based clocks that track civil time. To represent this
19: data, the world is partitioned into regions whose clocks all agree
20: about time stamps that occur after the somewhat-arbitrary cutoff point
21: of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region,
22: the database records all known clock transitions, and labels the region
23: with a notable location. Although 1970 is a somewhat-arbitrary
24: cutoff, there are significant challenges to moving the cutoff earlier
25: even by a decade or two, due to the wide variety of local practices
26: before computer timekeeping became prevalent.
27:
28: Clock transitions before 1970 are recorded for each such location,
29: because most systems support time stamps before 1970 and could
30: misbehave if data entries were omitted for pre-1970 transitions.
31: However, the database is not designed for and does not suffice for
32: applications requiring accurate handling of all past times everywhere,
33: as it would take far too much effort and guesswork to record all
34: details of pre-1970 civil timekeeping.
35:
36: As described below, reference source code for using the tz database is
37: also available. The tz code is upwards compatible with POSIX, an
38: international standard for UNIX-like systems. As of this writing, the
39: current edition of POSIX is:
1.2 perry 40:
1.14 christos 41: The Open Group Base Specifications Issue 7
42: IEEE Std 1003.1, 2013 Edition
43: <http://pubs.opengroup.org/onlinepubs/9699919799/>
1.2 perry 44:
45:
1.1 jtc 46:
1.18 christos 47: ----- Names of time zone rules -----
1.2 perry 48:
1.18 christos 49: Each of the database's time zone rules has a unique name.
50: Inexperienced users are not expected to select these names unaided.
51: Distributors should provide documentation and/or a simple selection
52: interface that explains the names; for one example, see the 'tzselect'
53: program in the tz code. The Unicode Common Locale Data Repository
54: <http://cldr.unicode.org/> contains data that may be useful for other
55: selection interfaces.
1.2 perry 56:
1.18 christos 57: The time zone rule naming conventions attempt to strike a balance
58: among the following goals:
1.6 kleink 59:
1.18 christos 60: * Uniquely identify every region where clocks have agreed since 1970.
61: This is essential for the intended use: static clocks keeping local
62: civil time.
63:
64: * Indicate to experts where that region is.
65:
66: * Be robust in the presence of political changes. For example, names
67: of countries are ordinarily not used, to avoid incompatibilities
68: when countries change their name (e.g. Zaire->Congo) or when
69: locations change countries (e.g. Hong Kong from UK colony to
70: China).
1.2 perry 71:
1.18 christos 72: * Be portable to a wide variety of implementations.
1.9 mlelstv 73:
1.18 christos 74: * Use a consistent naming conventions over the entire world.
1.9 mlelstv 75:
1.18 christos 76: Names normally have the form AREA/LOCATION, where AREA is the name
77: of a continent or ocean, and LOCATION is the name of a specific
78: location within that region. North and South America share the same
79: area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York',
80: and 'Pacific/Honolulu'.
1.9 mlelstv 81:
1.18 christos 82: Here are the general rules used for choosing location names,
83: in decreasing order of importance:
1.9 mlelstv 84:
1.18 christos 85: Use only valid POSIX file name components (i.e., the parts of
86: names other than '/'). Do not use the file name
87: components '.' and '..'. Within a file name component,
88: use only ASCII letters, '.', '-' and '_'. Do not use
89: digits, as that might create an ambiguity with POSIX
90: TZ strings. A file name component must not exceed 14
91: characters or start with '-'. E.g., prefer 'Brunei'
92: to 'Bandar_Seri_Begawan'. Exceptions: see the discussion
93: of legacy names below.
94: A name must not be empty, or contain '//', or start or end with '/'.
95: Do not use names that differ only in case. Although the reference
96: implementation is case-sensitive, some other implementations
97: are not, and they would mishandle names differing only in case.
98: If one name A is an initial prefix of another name AB (ignoring case),
99: then B must not start with '/', as a regular file cannot have
100: the same name as a directory in POSIX. For example,
101: 'America/New_York' precludes 'America/New_York/Bronx'.
102: Uninhabited regions like the North Pole and Bouvet Island
103: do not need locations, since local time is not defined there.
104: There should typically be at least one name for each ISO 3166-1
105: officially assigned two-letter code for an inhabited country
106: or territory.
107: If all the clocks in a region have agreed since 1970,
108: don't bother to include more than one location
109: even if subregions' clocks disagreed before 1970.
110: Otherwise these tables would become annoyingly large.
111: If a name is ambiguous, use a less ambiguous alternative;
112: e.g. many cities are named San José and Georgetown, so
113: prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to 'Georgetown'.
114: Keep locations compact. Use cities or small islands, not countries
115: or regions, so that any future time zone changes do not split
116: locations into different time zones. E.g. prefer 'Paris'
117: to 'France', since France has had multiple time zones.
118: Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and
119: prefer 'Athens' to the Greek 'Αθήνα' or the Romanized 'Athína'.
120: The POSIX file name restrictions encourage this rule.
121: Use the most populous among locations in a zone,
122: e.g. prefer 'Shanghai' to 'Beijing'. Among locations with
123: similar populations, pick the best-known location,
124: e.g. prefer 'Rome' to 'Milan'.
125: Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
126: Omit common suffixes like '_Islands' and '_City', unless that
127: would lead to ambiguity. E.g. prefer 'Cayman' to
128: 'Cayman_Islands' and 'Guatemala' to 'Guatemala_City',
129: but prefer 'Mexico_City' to 'Mexico' because the country
130: of Mexico has several time zones.
131: Use '_' to represent a space.
132: Omit '.' from abbreviations in names, e.g. prefer 'St_Helena'
133: to 'St._Helena'.
134: Do not change established names if they only marginally
135: violate the above rules. For example, don't change
136: the existing name 'Rome' to 'Milan' merely because
137: Milan's population has grown to be somewhat greater
138: than Rome's.
139: If a name is changed, put its old spelling in the 'backward' file.
140: This means old spellings will continue to work.
1.1 jtc 141:
1.18 christos 142: The file 'zone1970.tab' lists geographical locations used to name time
143: zone rules. It is intended to be an exhaustive list of names for
144: geographic regions as described above; this is a subset of the names
145: in the data. Although a 'zone1970.tab' location's longitude
146: corresponds to its LMT offset with one hour for every 15 degrees east
147: longitude, this relationship is not exact.
1.1 jtc 148:
1.18 christos 149: Older versions of this package used a different naming scheme,
150: and these older names are still supported.
151: See the file 'backward' for most of these older names
152: (e.g., 'US/Eastern' instead of 'America/New_York').
153: The other old-fashioned names still supported are
154: 'WET', 'CET', 'MET', and 'EET' (see the file 'europe').
1.1 jtc 155:
1.18 christos 156: Older versions of this package defined legacy names that are
157: incompatible with the first rule of location names, but which are
158: still supported. These legacy names are mostly defined in the file
159: 'etcetera'. Also, the file 'backward' defines the legacy names
160: 'GMT0', 'GMT-0', 'GMT+0' and 'Canada/East-Saskatchewan', and the file
161: 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
162: 'MST7MDT', and 'PST8PDT'.
1.14 christos 163:
1.18 christos 164: Excluding 'backward' should not affect the other data. If
165: 'backward' is excluded, excluding 'etcetera' should not affect the
166: remaining data.
1.1 jtc 167:
168:
1.18 christos 169: ----- Time zone abbreviations -----
1.1 jtc 170:
1.18 christos 171: When this package is installed, it generates time zone abbreviations
172: like 'EST' to be compatible with human tradition and POSIX.
173: Here are the general rules used for choosing time zone abbreviations,
174: in decreasing order of importance:
1.1 jtc 175:
1.19 christos 176: Use three or more characters that are ASCII alphanumerics or '+' or '-'.
1.18 christos 177: Previous editions of this database also used characters like
178: ' ' and '?', but these characters have a special meaning to
179: the shell and cause commands like
180: set `date`
181: to have unexpected effects.
182: Previous editions of this rule required upper-case letters,
183: but the Congressman who introduced Chamorro Standard Time
1.19 christos 184: preferred "ChST", so lower-case letters are now allowed.
185: Also, POSIX from 2001 on relaxed the rule to allow '-', '+',
186: and alphanumeric characters from the portable character set
187: in the current locale. In practice ASCII alphanumerics and
188: '+' and '-' are safe in all locales.
1.1 jtc 189:
1.19 christos 190: In other words, in the C locale the POSIX extended regular
191: expression [-+[:alnum:]]{3,} should match the abbreviation.
192: This guarantees that all abbreviations could have been
193: specified by a POSIX TZ string.
1.1 jtc 194:
1.18 christos 195: Use abbreviations that are in common use among English-speakers,
196: e.g. 'EST' for Eastern Standard Time in North America.
197: We assume that applications translate them to other languages
198: as part of the normal localization process; for example,
199: a French application might translate 'EST' to 'HNE'.
1.1 jtc 200:
1.18 christos 201: For zones whose times are taken from a city's longitude, use the
202: traditional xMT notation, e.g. 'PMT' for Paris Mean Time.
203: The only name like this in current use is 'GMT'.
1.14 christos 204:
1.18 christos 205: Use 'LMT' for local mean time of locations before the introduction
206: of standard time; see "Scope of the tz database".
1.1 jtc 207:
1.18 christos 208: If there is no common English abbreviation, use numeric offsets like
209: -05 and +0830 that are generated by zic's %z notation.
1.2 perry 210:
1.18 christos 211: [The remaining guidelines predate the introduction of %z.
212: They are problematic as they mean tz data entries invent
213: notation rather than record it. These guidelines are now
214: deprecated and the plan is to gradually move to %z for
215: inhabited locations and to "-00" for uninhabited locations.]
1.2 perry 216:
1.18 christos 217: If there is no common English abbreviation, abbreviate the English
218: translation of the usual phrase used by native speakers.
219: If this is not available or is a phrase mentioning the country
220: (e.g. "Cape Verde Time"), then:
1.2 perry 221:
1.18 christos 222: When a country is identified with a single or principal zone,
223: append 'T' to the country's ISO code, e.g. 'CVT' for
224: Cape Verde Time. For summer time append 'ST';
225: for double summer time append 'DST'; etc.
226: Otherwise, take the first three letters of an English place
227: name identifying each zone and append 'T', 'ST', etc.
228: as before; e.g. 'VLAST' for VLAdivostok Summer Time.
1.1 jtc 229:
1.20 ! christos 230: Use UT (with time zone abbreviation '-00') for locations while
! 231: uninhabited. The leading '-' is a flag that the time
! 232: zone is in some sense undefined; this notation is
! 233: derived from Internet RFC 3339.
1.2 perry 234:
1.18 christos 235: Application writers should note that these abbreviations are ambiguous
236: in practice: e.g. 'CST' has a different meaning in China than
237: it does in the United States. In new applications, it's often better
238: to use numeric UT offsets like '-0600' instead of time zone
239: abbreviations like 'CST'; this avoids the ambiguity.
1.10 christos 240:
1.14 christos 241:
242: ----- Accuracy of the tz database -----
243:
244: The tz database is not authoritative, and it surely has errors.
1.16 christos 245: Corrections are welcome and encouraged; see the file CONTRIBUTING.
246: Users requiring authoritative data should consult national standards
247: bodies and the references cited in the database's comments.
1.10 christos 248:
1.14 christos 249: Errors in the tz database arise from many sources:
250:
251: * The tz database predicts future time stamps, and current predictions
252: will be incorrect after future governments change the rules.
253: For example, if today someone schedules a meeting for 13:00 next
254: October 1, Casablanca time, and tomorrow Morocco changes its
255: daylight saving rules, software can mess up after the rule change
256: if it blithely relies on conversions made before the change.
257:
1.16 christos 258: * The pre-1970 entries in this database cover only a tiny sliver of how
1.14 christos 259: clocks actually behaved; the vast majority of the necessary
260: information was lost or never recorded. Thousands more zones would
261: be needed if the tz database's scope were extended to cover even
262: just the known or guessed history of standard time; for example,
263: the current single entry for France would need to split into dozens
1.19 christos 264: of entries, perhaps hundreds. And in most of the world even this
265: approach would be misleading due to widespread disagreement or
266: indifference about what times should be observed. In her 2015 book
267: "The Global Transformation of Time, 1870-1950", Vanessa Ogle writes
268: "Outside of Europe and North America there was no system of time
269: zones at all, often not even a stable landscape of mean times,
270: prior to the middle decades of the twentieth century". See:
271: Timothy Shenk, Booked: A Global History of Time. Dissent 2015-12-17
272: https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanessa-ogle
1.14 christos 273:
1.16 christos 274: * Most of the pre-1970 data entries come from unreliable sources, often
1.14 christos 275: astrology books that lack citations and whose compilers evidently
276: invented entries when the true facts were unknown, without
277: reporting which entries were known and which were invented.
278: These books often contradict each other or give implausible entries,
1.16 christos 279: and on the rare occasions when they are checked they are
1.14 christos 280: typically found to be incorrect.
281:
282: * For the UK the tz database relies on years of first-class work done by
283: Joseph Myers and others; see <http://www.polyomino.org.uk/british-time/>.
284: Other countries are not done nearly as well.
285:
286: * Sometimes, different people in the same city would maintain clocks
287: that differed significantly. Railway time was used by railroad
288: companies (which did not always agree with each other),
289: church-clock time was used for birth certificates, etc.
290: Often this was merely common practice, but sometimes it was set by law.
291: For example, from 1891 to 1911 the UT offset in France was legally
292: 0:09:21 outside train stations and 0:04:21 inside.
293:
294: * Although a named location in the tz database stands for the
295: containing region, its pre-1970 data entries are often accurate for
296: only a small subset of that region. For example, Europe/London
297: stands for the United Kingdom, but its pre-1847 times are valid
298: only for locations that have London's exact meridian, and its 1847
299: transition to GMT is known to be valid only for the L&NW and the
300: Caledonian railways.
301:
1.16 christos 302: * The tz database does not record the earliest time for which a zone's
303: data entries are thereafter valid for every location in the region.
1.14 christos 304: For example, Europe/London is valid for all locations in its
305: region after GMT was made the standard time, but the date of
306: standardization (1880-08-02) is not in the tz database, other than
307: in commentary. For many zones the earliest time of validity is
308: unknown.
309:
310: * The tz database does not record a region's boundaries, and in many
311: cases the boundaries are not known. For example, the zone
312: America/Kentucky/Louisville represents a region around the city of
313: Louisville, the boundaries of which are unclear.
314:
315: * Changes that are modeled as instantaneous transitions in the tz
316: database were often spread out over hours, days, or even decades.
317:
318: * Even if the time is specified by law, locations sometimes
319: deliberately flout the law.
320:
321: * Early timekeeping practices, even assuming perfect clocks, were
322: often not specified to the accuracy that the tz database requires.
323:
324: * Sometimes historical timekeeping was specified more precisely
325: than what the tz database can handle. For example, from 1909 to
326: 1937 Netherlands clocks were legally UT+00:19:32.13, but the tz
327: database cannot represent the fractional second.
328:
329: * Even when all the timestamp transitions recorded by the tz database
330: are correct, the tz rules that generate them may not faithfully
331: reflect the historical rules. For example, from 1922 until World
332: War II the UK moved clocks forward the day following the third
333: Saturday in April unless that was Easter, in which case it moved
334: clocks forward the previous Sunday. Because the tz database has no
335: way to specify Easter, these exceptional years are entered as
336: separate tz Rule lines, even though the legal rules did not change.
337:
1.16 christos 338: * The tz database models pre-standard time using the proleptic Gregorian
1.14 christos 339: calendar and local mean time (LMT), but many people used other
340: calendars and other timescales. For example, the Roman Empire used
341: the Julian calendar, and had 12 varying-length daytime hours with a
342: non-hour-based system at night.
343:
1.16 christos 344: * Early clocks were less reliable, and data entries do not represent
345: this unreliability.
1.14 christos 346:
347: * As for leap seconds, civil time was not based on atomic time before
348: 1972, and we don't know the history of earth's rotation accurately
349: enough to map SI seconds to historical solar time to more than
350: about one-hour accuracy. See: Morrison LV, Stephenson FR.
351: Historical values of the Earth's clock error Delta T and the
352: calculation of eclipses. J Hist Astron. 2004;35:327-36
353: <http://adsabs.harvard.edu/full/2004JHA....35..327M>;
354: Historical values of the Earth's clock error. J Hist Astron. 2005;36:339
355: <http://adsabs.harvard.edu/full/2005JHA....36..339M>.
356:
357: * The relationship between POSIX time (that is, UTC but ignoring leap
358: seconds) and UTC is not agreed upon after 1972. Although the POSIX
359: clock officially stops during an inserted leap second, at least one
360: proposed standard has it jumping back a second instead; and in
361: practice POSIX clocks more typically either progress glacially during
362: a leap second, or are slightly slowed while near a leap second.
363:
364: * The tz database does not represent how uncertain its information is.
1.16 christos 365: Ideally it would contain information about when data entries are
1.14 christos 366: incomplete or dicey. Partial temporal knowledge is a field of
367: active research, though, and it's not clear how to apply it here.
368:
369: In short, many, perhaps most, of the tz database's pre-1970 and future
370: time stamps are either wrong or misleading. Any attempt to pass the
371: tz database off as the definition of time should be unacceptable to
372: anybody who cares about the facts. In particular, the tz database's
373: LMT offsets should not be considered meaningful, and should not prompt
374: creation of zones merely because two locations differ in LMT or
375: transitioned to standard time at different dates.
376:
1.10 christos 377:
1.18 christos 378: ----- Time and date functions -----
379:
380: The tz code contains time and date functions that are upwards
381: compatible with those of POSIX.
382:
383: POSIX has the following properties and limitations.
384:
385: * In POSIX, time display in a process is controlled by the
386: environment variable TZ. Unfortunately, the POSIX TZ string takes
387: a form that is hard to describe and is error-prone in practice.
388: Also, POSIX TZ strings can't deal with other (for example, Israeli)
389: daylight saving time rules, or situations where more than two
390: time zone abbreviations are used in an area.
391:
392: The POSIX TZ string takes the following form:
393:
394: stdoffset[dst[offset][,date[/time],date[/time]]]
395:
396: where:
397:
398: std and dst
399: are 3 or more characters specifying the standard
400: and daylight saving time (DST) zone names.
401: Starting with POSIX.1-2001, std and dst may also be
402: in a quoted form like "<UTC+10>"; this allows
403: "+" and "-" in the names.
404: offset
405: is of the form '[+-]hh:[mm[:ss]]' and specifies the
406: offset west of UT. 'hh' may be a single digit; 0<=hh<=24.
407: The default DST offset is one hour ahead of standard time.
408: date[/time],date[/time]
409: specifies the beginning and end of DST. If this is absent,
410: the system supplies its own rules for DST, and these can
411: differ from year to year; typically US DST rules are used.
412: time
413: takes the form 'hh:[mm[:ss]]' and defaults to 02:00.
414: This is the same format as the offset, except that a
415: leading '+' or '-' is not allowed.
416: date
417: takes one of the following forms:
418: Jn (1<=n<=365)
419: origin-1 day number not counting February 29
420: n (0<=n<=365)
421: origin-0 day number counting February 29 if present
422: Mm.n.d (0[Sunday]<=d<=6[Saturday], 1<=n<=5, 1<=m<=12)
423: for the dth day of week n of month m of the year,
424: where week 1 is the first week in which day d appears,
425: and '5' stands for the last week in which day d appears
426: (which may be either the 4th or 5th week).
427: Typically, this is the only useful form;
428: the n and Jn forms are rarely used.
429:
430: Here is an example POSIX TZ string, for US Pacific time using rules
431: appropriate from 1987 through 2006:
1.2 perry 432:
1.18 christos 433: TZ='PST8PDT,M4.1.0/02:00,M10.5.0/02:00'
1.6 kleink 434:
1.18 christos 435: This POSIX TZ string is hard to remember, and mishandles time stamps
436: before 1987 and after 2006. With this package you can use this
437: instead:
1.6 kleink 438:
1.18 christos 439: TZ='America/Los_Angeles'
1.6 kleink 440:
1.18 christos 441: * POSIX does not define the exact meaning of TZ values like "EST5EDT".
442: Typically the current US DST rules are used to interpret such values,
443: but this means that the US DST rules are compiled into each program
444: that does time conversion. This means that when US time conversion
445: rules change (as in the United States in 1987), all programs that
446: do time conversion must be recompiled to ensure proper results.
1.6 kleink 447:
1.18 christos 448: * In POSIX, there's no tamper-proof way for a process to learn the
449: system's best idea of local wall clock. (This is important for
450: applications that an administrator wants used only at certain times -
451: without regard to whether the user has fiddled the "TZ" environment
452: variable. While an administrator can "do everything in UTC" to get
453: around the problem, doing so is inconvenient and precludes handling
454: daylight saving time shifts - as might be required to limit phone
455: calls to off-peak hours.)
1.2 perry 456:
1.18 christos 457: * POSIX requires that systems ignore leap seconds.
1.2 perry 458:
1.18 christos 459: * The tz code attempts to support all the time_t implementations
460: allowed by POSIX. The time_t type represents a nonnegative count of
461: seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds.
462: In practice, time_t is usually a signed 64- or 32-bit integer; 32-bit
463: signed time_t values stop working after 2038-01-19 03:14:07 UTC, so
464: new implementations these days typically use a signed 64-bit integer.
465: Unsigned 32-bit integers are used on one or two platforms,
466: and 36-bit and 40-bit integers are also used occasionally.
467: Although earlier POSIX versions allowed time_t to be a
468: floating-point type, this was not supported by any practical
469: systems, and POSIX.1-2013 and the tz code both require time_t
470: to be an integer type.
1.2 perry 471:
1.18 christos 472: These are the extensions that have been made to the POSIX functions:
1.2 perry 473:
1.18 christos 474: * The "TZ" environment variable is used in generating the name of a file
475: from which time zone information is read (or is interpreted a la
476: POSIX); "TZ" is no longer constrained to be a three-letter time zone
477: name followed by a number of hours and an optional three-letter
478: daylight time zone name. The daylight saving time rules to be used
479: for a particular time zone are encoded in the time zone file;
480: the format of the file allows U.S., Australian, and other rules to be
481: encoded, and allows for situations where more than two time zone
482: abbreviations are used.
1.2 perry 483:
1.18 christos 484: It was recognized that allowing the "TZ" environment variable to
485: take on values such as "America/New_York" might cause "old" programs
486: (that expect "TZ" to have a certain form) to operate incorrectly;
487: consideration was given to using some other environment variable
488: (for example, "TIMEZONE") to hold the string used to generate the
489: time zone information file name. In the end, however, it was decided
490: to continue using "TZ": it is widely used for time zone purposes;
491: separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance;
492: and systems where "new" forms of "TZ" might cause problems can simply
493: use TZ values such as "EST5EDT" which can be used both by
494: "new" programs (a la POSIX) and "old" programs (as zone names and
495: offsets).
1.2 perry 496:
1.18 christos 497: * To handle places where more than two time zone abbreviations are used,
498: the functions "localtime" and "gmtime" set tzname[tmp->tm_isdst]
499: (where "tmp" is the value the function returns) to the time zone
500: abbreviation to be used. This differs from POSIX, where the elements
501: of tzname are only changed as a result of calls to tzset.
1.15 christos 502:
1.18 christos 503: * Since the "TZ" environment variable can now be used to control time
504: conversion, the "daylight" and "timezone" variables are no longer
505: needed. (These variables are defined and set by "tzset"; however, their
506: values will not be used by "localtime.")
1.15 christos 507:
1.18 christos 508: * The "localtime" function has been set up to deliver correct results
509: for near-minimum or near-maximum time_t values. (A comment in the
510: source code tells how to get compatibly wrong results).
1.2 perry 511:
1.18 christos 512: * A function "tzsetwall" has been added to arrange for the system's
513: best approximation to local wall clock time to be delivered by
514: subsequent calls to "localtime." Source code for portable
515: applications that "must" run on local wall clock time should call
516: "tzsetwall();" if such code is moved to "old" systems that don't
517: provide tzsetwall, you won't be able to generate an executable program.
518: (These time zone functions also arrange for local wall clock time to be
519: used if tzset is called - directly or indirectly - and there's no "TZ"
520: environment variable; portable applications should not, however, rely
521: on this behavior since it's not the way SVR2 systems behave.)
1.2 perry 522:
1.18 christos 523: * Negative time_t values are supported, on systems where time_t is signed.
1.2 perry 524:
1.18 christos 525: * These functions can account for leap seconds, thanks to Bradley White.
1.6 kleink 526:
1.18 christos 527: Points of interest to folks with other systems:
1.6 kleink 528:
1.18 christos 529: * This package is already part of many POSIX-compliant hosts,
530: including BSD, HP, Linux, Network Appliance, SCO, SGI, and Sun.
531: On such hosts, the primary use of this package
532: is to update obsolete time zone rule tables.
533: To do this, you may need to compile the time zone compiler
534: 'zic' supplied with this package instead of using the system 'zic',
535: since the format of zic's input changed slightly in late 1994,
536: and many vendors still do not support the new input format.
1.6 kleink 537:
1.18 christos 538: * The UNIX Version 7 "timezone" function is not present in this package;
539: it's impossible to reliably map timezone's arguments (a "minutes west
540: of GMT" value and a "daylight saving time in effect" flag) to a
541: time zone abbreviation, and we refuse to guess.
542: Programs that in the past used the timezone function may now examine
543: tzname[localtime(&clock)->tm_isdst] to learn the correct time
544: zone abbreviation to use. Alternatively, use
545: localtime(&clock)->tm_zone if this has been enabled.
1.6 kleink 546:
1.18 christos 547: * The 4.2BSD gettimeofday function is not used in this package.
548: This formerly let users obtain the current UTC offset and DST flag,
549: but this functionality was removed in later versions of BSD.
1.2 perry 550:
1.18 christos 551: * In SVR2, time conversion fails for near-minimum or near-maximum
552: time_t values when doing conversions for places that don't use UT.
553: This package takes care to do these conversions correctly.
1.2 perry 554:
1.18 christos 555: The functions that are conditionally compiled if STD_INSPIRED is defined
556: should, at this point, be looked on primarily as food for thought. They are
557: not in any sense "standard compatible" - some are not, in fact, specified in
558: *any* standard. They do, however, represent responses of various authors to
559: standardization proposals.
1.14 christos 560:
1.18 christos 561: Other time conversion proposals, in particular the one developed by folks at
562: Hewlett Packard, offer a wider selection of functions that provide capabilities
563: beyond those provided here. The absence of such functions from this package
564: is not meant to discourage the development, standardization, or use of such
565: functions. Rather, their absence reflects the decision to make this package
566: contain valid extensions to POSIX, to ensure its broad acceptability. If
567: more powerful time conversion functions can be standardized, so much the
568: better.
1.4 kleink 569:
570:
571: ----- Calendrical issues -----
572:
573: Calendrical issues are a bit out of scope for a time zone database,
574: but they indicate the sort of problems that we would run into if we
575: extended the time zone database further into the past. An excellent
1.10 christos 576: resource in this area is Nachum Dershowitz and Edward M. Reingold,
1.15 christos 577: Calendrical Calculations: Third Edition, Cambridge University Press (2008)
578: <http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/>.
579: Other information and sources are given below. They sometimes disagree.
1.4 kleink 580:
581:
582: France
583:
584: Gregorian calendar adopted 1582-12-20.
585: French Revolutionary calendar used 1793-11-24 through 1805-12-31,
586: and (in Paris only) 1871-05-06 through 1871-05-23.
587:
588:
589: Russia
590:
1.9 mlelstv 591: From Chris Carrier (1996-12-02):
1.14 christos 592: On 1929-10-01 the Soviet Union instituted an "Eternal Calendar"
1.4 kleink 593: with 30-day months plus 5 holidays, with a 5-day week.
594: On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the
595: Gregorian calendar while retaining the 6-day week; on 1940-06-27 it
596: reverted to the 7-day week. With the 6-day week the usual days
597: off were the 6th, 12th, 18th, 24th and 30th of the month.
598: (Source: Evitiar Zerubavel, _The Seven Day Circle_)
599:
600:
601: Mark Brader reported a similar story in "The Book of Calendars", edited
602: by Frank Parise (1982, Facts on File, ISBN 0-8719-6467-8), page 377. But:
603:
604: From: Petteri Sulonen (via Usenet)
605: Date: 14 Jan 1999 00:00:00 GMT
1.9 mlelstv 606: ...
1.4 kleink 607:
1.15 christos 608: If your source is correct, how come documents between 1929 and 1940 were
1.4 kleink 609: still dated using the conventional, Gregorian calendar?
610:
611: I can post a scan of a document dated December 1, 1934, signed by
612: Yenukidze, the secretary, on behalf of Kalinin, the President of the
613: Executive Committee of the Supreme Soviet, if you like.
614:
615:
616:
617: Sweden (and Finland)
618:
1.9 mlelstv 619: From: Mark Brader
1.15 christos 620: Subject: Re: Gregorian reform - a part of locale?
621: <news:1996Jul6.012937.29190@sq.com>
1.4 kleink 622: Date: 1996-07-06
623:
624: In 1700, Denmark made the transition from Julian to Gregorian. Sweden
625: decided to *start* a transition in 1700 as well, but rather than have one of
626: those unsightly calendar gaps :-), they simply decreed that the next leap
1.15 christos 627: year after 1696 would be in 1744 - putting the whole country on a calendar
1.4 kleink 628: different from both Julian and Gregorian for a period of 40 years.
629:
630: However, in 1704 something went wrong and the plan was not carried through;
631: they did, after all, have a leap year that year. And one in 1708. In 1712
632: they gave it up and went back to Julian, putting 30 days in February that
633: year!...
634:
635: Then in 1753, Sweden made the transition to Gregorian in the usual manner,
636: getting there only 13 years behind the original schedule.
637:
638: (A previous posting of this story was challenged, and Swedish readers
1.15 christos 639: produced the following references to support it: "Tideräkning och historia"
640: by Natanael Beckman (1924) and "Tid, en bok om tideräkning och
641: kalenderväsen" by Lars-Olof Lodén (1968).
1.4 kleink 642:
643:
644: Grotefend's data
645:
1.9 mlelstv 646: From: "Michael Palmer" [with one obvious typo fixed]
1.4 kleink 647: Subject: Re: Gregorian Calendar (was Re: Another FHC related question
648: Newsgroups: soc.genealogy.german
649: Date: Tue, 9 Feb 1999 02:32:48 -800
1.9 mlelstv 650: ...
1.4 kleink 651:
1.6 kleink 652: The following is a(n incomplete) listing, arranged chronologically, of
653: European states, with the date they converted from the Julian to the
1.4 kleink 654: Gregorian calendar:
655:
656: 04/15 Oct 1582 - Italy (with exceptions), Spain, Portugal, Poland (Roman
657: Catholics and Danzig only)
658: 09/20 Dec 1582 - France, Lorraine
659:
660: 21 Dec 1582/
661: 01 Jan 1583 - Holland, Brabant, Flanders, Hennegau
1.15 christos 662: 10/21 Feb 1583 - bishopric of Liege (Lüttich)
1.4 kleink 663: 13/24 Feb 1583 - bishopric of Augsburg
664: 04/15 Oct 1583 - electorate of Trier
665: 05/16 Oct 1583 - Bavaria, bishoprics of Freising, Eichstedt, Regensburg,
666: Salzburg, Brixen
1.15 christos 667: 13/24 Oct 1583 - Austrian Oberelsaß and Breisgau
1.4 kleink 668: 20/31 Oct 1583 - bishopric of Basel
1.15 christos 669: 02/13 Nov 1583 - duchy of Jülich-Berg
670: 02/13 Nov 1583 - electorate and city of Köln
671: 04/15 Nov 1583 - bishopric of Würzburg
1.4 kleink 672: 11/22 Nov 1583 - electorate of Mainz
673: 16/27 Nov 1583 - bishopric of Strassburg and the margraviate of Baden
1.15 christos 674: 17/28 Nov 1583 - bishopric of Münster and duchy of Cleve
1.4 kleink 675: 14/25 Dec 1583 - Steiermark
676:
677: 06/17 Jan 1584 - Austria and Bohemia
1.15 christos 678: 11/22 Jan 1584 - Lucerne, Uri, Schwyz, Zug, Freiburg, Solothurn
1.4 kleink 679: 12/23 Jan 1584 - Silesia and the Lausitz
680: 22 Jan/
681: 02 Feb 1584 - Hungary (legally on 21 Oct 1587)
682: Jun 1584 - Unterwalden
683: 01/12 Jul 1584 - duchy of Westfalen
684:
685: 16/27 Jun 1585 - bishopric of Paderborn
686:
687: 14/25 Dec 1590 - Transylvania
688:
689: 22 Aug/
690: 02 Sep 1612 - duchy of Prussia
691:
692: 13/24 Dec 1614 - Pfalz-Neuburg
693:
694: 1617 - duchy of Kurland (reverted to the Julian calendar in
695: 1796)
696:
1.15 christos 697: 1624 - bishopric of Osnabrück
1.4 kleink 698:
699: 1630 - bishopric of Minden
700:
701: 15/26 Mar 1631 - bishopric of Hildesheim
702:
703: 1655 - Kanton Wallis
704:
705: 05/16 Feb 1682 - city of Strassburg
706:
707: 18 Feb/
708: 01 Mar 1700 - Protestant Germany (including Swedish possessions in
709: Germany), Denmark, Norway
710: 30 Jun/
711: 12 Jul 1700 - Gelderland, Zutphen
712: 10 Nov/
713: 12 Dec 1700 - Utrecht, Overijssel
714:
715: 31 Dec 1700/
1.15 christos 716: 12 Jan 1701 - Friesland, Groningen, Zürich, Bern, Basel, Geneva,
1.4 kleink 717: Turgau, and Schaffhausen
718:
719: 1724 - Glarus, Appenzell, and the city of St. Gallen
720:
721: 01 Jan 1750 - Pisa and Florence
722:
723: 02/14 Sep 1752 - Great Britain
724:
725: 17 Feb/
726: 01 Mar 1753 - Sweden
727:
1.15 christos 728: 1760-1812 - Graubünden
1.4 kleink 729:
1.6 kleink 730: The Russian empire (including Finland and the Baltic states) did not
1.4 kleink 731: convert to the Gregorian calendar until the Soviet revolution of 1917.
732:
1.16 christos 733: Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen
1.6 kleink 734: Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend
1.16 christos 735: (Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28.
1.8 kleink 736:
737:
738: ----- Time and time zones on Mars -----
739:
1.17 christos 740: Some people's work schedules use Mars time. Jet Propulsion Laboratory
741: (JPL) coordinators have kept Mars time on and off at least since 1997
742: for the Mars Pathfinder mission. Some of their family members have
743: also adapted to Mars time. Dozens of special Mars watches were built
744: for JPL workers who kept Mars time during the Mars Exploration
1.8 kleink 745: Rovers mission (2004). These timepieces look like normal Seikos and
746: Citizens but use Mars seconds rather than terrestrial seconds.
747:
748: A Mars solar day is called a "sol" and has a mean period equal to
749: about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is
750: divided into a conventional 24-hour clock, so each Mars second equals
751: about 1.02749125 terrestrial seconds.
752:
753: The prime meridian of Mars goes through the center of the crater
754: Airy-0, named in honor of the British astronomer who built the
755: Greenwich telescope that defines Earth's prime meridian. Mean solar
756: time on the Mars prime meridian is called Mars Coordinated Time (MTC).
757:
758: Each landed mission on Mars has adopted a different reference for
759: solar time keeping, so there is no real standard for Mars time zones.
760: For example, the Mars Exploration Rover project (2004) defined two
761: time zones "Local Solar Time A" and "Local Solar Time B" for its two
762: missions, each zone designed so that its time equals local true solar
763: time at approximately the middle of the nominal mission. Such a "time
764: zone" is not particularly suited for any application other than the
765: mission itself.
766:
767: Many calendars have been proposed for Mars, but none have achieved
768: wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a
769: sequential count of Mars solar days elapsed since about 1873-12-29
770: 12:00 GMT.
771:
772: The tz database does not currently support Mars time, but it is
773: documented here in the hopes that support will be added eventually.
774:
775: Sources:
776:
777: Michael Allison and Robert Schmunk,
778: "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock"
1.13 christos 779: <http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08).
1.8 kleink 780:
781: Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times
1.13 christos 782: <http://articles.latimes.com/2004/jan/14/science/sci-marstime14>
1.8 kleink 783: (2004-01-14), pp A1, A20-A21.
1.15 christos 784:
1.17 christos 785: Tom Chmielewski, "Jet Lag Is Worse on Mars", The Atlantic (2015-02-26)
786: <http://www.theatlantic.com/technology/archive/2015/02/jet-lag-is-worse-on-mars/386033/>
1.15 christos 787:
788: -----
1.18 christos 789:
790: This file is in the public domain, so clarified as of 2009-05-17 by
791: Arthur David Olson.
792:
793: -----
1.15 christos 794: Local Variables:
795: coding: utf-8
796: End:
CVSweb <webmaster@jp.NetBSD.org>