| theory.html (349598) | theory.html (352354) |
|---|---|
| 1<!DOCTYPE html> 2<html lang="en"> 3<head> 4 <title>Theory and pragmatics of the tz code and data</title> 5 <meta charset="UTF-8"> 6 <style> 7 pre {margin-left: 2em; white-space: pre-wrap;} 8 </style> --- 7 unchanged lines hidden (view full) --- 16 <li><a href="#scope">Scope of the <code><abbr>tz</abbr></code> 17 database</a></li> 18 <li><a href="#naming">Timezone identifiers</a></li> 19 <li><a href="#abbreviations">Time zone abbreviations</a></li> 20 <li><a href="#accuracy">Accuracy of the <code><abbr>tz</abbr></code> 21 database</a></li> 22 <li><a href="#functions">Time and date functions</a></li> 23 <li><a href="#stability">Interface stability</a></li> | 1<!DOCTYPE html> 2<html lang="en"> 3<head> 4 <title>Theory and pragmatics of the tz code and data</title> 5 <meta charset="UTF-8"> 6 <style> 7 pre {margin-left: 2em; white-space: pre-wrap;} 8 </style> --- 7 unchanged lines hidden (view full) --- 16 <li><a href="#scope">Scope of the <code><abbr>tz</abbr></code> 17 database</a></li> 18 <li><a href="#naming">Timezone identifiers</a></li> 19 <li><a href="#abbreviations">Time zone abbreviations</a></li> 20 <li><a href="#accuracy">Accuracy of the <code><abbr>tz</abbr></code> 21 database</a></li> 22 <li><a href="#functions">Time and date functions</a></li> 23 <li><a href="#stability">Interface stability</a></li> |
| 24 <li><a href="#leapsec">Leap seconds</a></li> |
|
| 24 <li><a href="#calendar">Calendrical issues</a></li> 25 <li><a href="#planets">Time and time zones on other planets</a></li> 26 </ul> 27 </nav> 28 29<section> 30 <h2 id="scope">Scope of the <code><abbr>tz</abbr></code> database</h2> 31<p> --- 61 unchanged lines hidden (view full) --- 93Edition. 94Because the database's scope encompasses real-world changes to civil 95timekeeping, its model for describing time is more complex than the 96standard and daylight saving times supported by POSIX. 97A <code><abbr>tz</abbr></code> timezone corresponds to a ruleset that can 98have more than two changes per year, these changes need not merely 99flip back and forth between two alternatives, and the rules themselves 100can change at times. | 25 <li><a href="#calendar">Calendrical issues</a></li> 26 <li><a href="#planets">Time and time zones on other planets</a></li> 27 </ul> 28 </nav> 29 30<section> 31 <h2 id="scope">Scope of the <code><abbr>tz</abbr></code> database</h2> 32<p> --- 61 unchanged lines hidden (view full) --- 94Edition. 95Because the database's scope encompasses real-world changes to civil 96timekeeping, its model for describing time is more complex than the 97standard and daylight saving times supported by POSIX. 98A <code><abbr>tz</abbr></code> timezone corresponds to a ruleset that can 99have more than two changes per year, these changes need not merely 100flip back and forth between two alternatives, and the rules themselves 101can change at times. |
| 101Whether and when a timezone changes its 102clock, and even the timezone's notional base offset from UTC, are variable. | 102Whether and when a timezone changes its clock, 103and even the timezone's notional base offset from <abbr>UTC</abbr>, 104are variable. |
| 103It does not always make sense to talk about a timezone's 104"base offset", which is not necessarily a single number. 105</p> 106 107</section> 108 109<section> 110 <h2 id="naming">Timezone identifiers</h2> --- 312 unchanged lines hidden (view full) --- 423 CST/CDT/CWT/CPT/CDDT Central [North America], 424 CST/CDT China, 425 GMT/BST/IST/BDST Greenwich, 426 EAT East Africa, 427 EST/EDT/EWT/EPT/EDDT Eastern [North America], 428 EET/EEST Eastern European, 429 GST/GDT Guam, 430 HST/HDT/HWT/HPT Hawaii, | 105It does not always make sense to talk about a timezone's 106"base offset", which is not necessarily a single number. 107</p> 108 109</section> 110 111<section> 112 <h2 id="naming">Timezone identifiers</h2> --- 312 unchanged lines hidden (view full) --- 425 CST/CDT/CWT/CPT/CDDT Central [North America], 426 CST/CDT China, 427 GMT/BST/IST/BDST Greenwich, 428 EAT East Africa, 429 EST/EDT/EWT/EPT/EDDT Eastern [North America], 430 EET/EEST Eastern European, 431 GST/GDT Guam, 432 HST/HDT/HWT/HPT Hawaii, |
| 431 HKT/HKST Hong Kong, | 433 HKT/HKST/HKWT Hong Kong, |
| 432 IST India, 433 IST/GMT Irish, 434 IST/IDT/IDDT Israel, 435 JST/JDT Japan, 436 KST/KDT Korea, 437 MET/MEST Middle European (a backward-compatibility alias for 438 Central European), 439 MSK/MSD Moscow, --- 527 unchanged lines hidden (view full) --- 967 </li> 968 <li> 969 POSIX provides no convenient and efficient way to determine 970 the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary 971 timestamps, particularly for timezones 972 that do not fit into the POSIX model. 973 </li> 974 <li> | 434 IST India, 435 IST/GMT Irish, 436 IST/IDT/IDDT Israel, 437 JST/JDT Japan, 438 KST/KDT Korea, 439 MET/MEST Middle European (a backward-compatibility alias for 440 Central European), 441 MSK/MSD Moscow, --- 527 unchanged lines hidden (view full) --- 969 </li> 970 <li> 971 POSIX provides no convenient and efficient way to determine 972 the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary 973 timestamps, particularly for timezones 974 that do not fit into the POSIX model. 975 </li> 976 <li> |
| 975 POSIX requires that systems ignore leap seconds. | 977 POSIX requires that <code>time_t</code> clock counts exclude leap 978 seconds. |
| 976 </li> 977 <li> 978 The <code><abbr>tz</abbr></code> code attempts to support all the 979 <code>time_t</code> implementations allowed by POSIX. 980 The <code>time_t</code> type represents a nonnegative count of seconds 981 since 1970-01-01 00:00:00 <abbr>UTC</abbr>, ignoring leap seconds. 982 In practice, <code>time_t</code> is usually a signed 64- or 32-bit 983 integer; 32-bit signed <code>time_t</code> values stop working after --- 83 unchanged lines hidden (view full) --- 1067 href="https://en.wikipedia.org/wiki/UNIX_System_V#SVR2"><abbr>SVR2</abbr></a> 1068 systems behave.) 1069 </li> 1070 <li> 1071 Negative <code>time_t</code> values are supported, on systems 1072 where <code>time_t</code> is signed. 1073 </li> 1074 <li> | 979 </li> 980 <li> 981 The <code><abbr>tz</abbr></code> code attempts to support all the 982 <code>time_t</code> implementations allowed by POSIX. 983 The <code>time_t</code> type represents a nonnegative count of seconds 984 since 1970-01-01 00:00:00 <abbr>UTC</abbr>, ignoring leap seconds. 985 In practice, <code>time_t</code> is usually a signed 64- or 32-bit 986 integer; 32-bit signed <code>time_t</code> values stop working after --- 83 unchanged lines hidden (view full) --- 1070 href="https://en.wikipedia.org/wiki/UNIX_System_V#SVR2"><abbr>SVR2</abbr></a> 1071 systems behave.) 1072 </li> 1073 <li> 1074 Negative <code>time_t</code> values are supported, on systems 1075 where <code>time_t</code> is signed. 1076 </li> 1077 <li> |
| 1075 These functions can account for leap seconds, thanks to Bradley White. | 1078 These functions can account for leap seconds; 1079 see <a href="#leapsec">Leap seconds</a> below. |
| 1076 </li> 1077</ul> 1078 1079<h3 id="vestigial">POSIX features no longer needed</h3> 1080<p> 1081POSIX and <a href="https://en.wikipedia.org/wiki/ISO_C"><abbr>ISO</abbr> C</a> 1082define some <a href="https://en.wikipedia.org/wiki/API"><abbr 1083title="application programming interface">API</abbr>s</a> that are vestigial: --- 160 unchanged lines hidden (view full) --- 1244If a calendar application records a future event in some location other 1245than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record, 1246the application should be robust in the presence of timezone splits 1247between now and the future time. 1248</p> 1249</section> 1250 1251<section> | 1080 </li> 1081</ul> 1082 1083<h3 id="vestigial">POSIX features no longer needed</h3> 1084<p> 1085POSIX and <a href="https://en.wikipedia.org/wiki/ISO_C"><abbr>ISO</abbr> C</a> 1086define some <a href="https://en.wikipedia.org/wiki/API"><abbr 1087title="application programming interface">API</abbr>s</a> that are vestigial: --- 160 unchanged lines hidden (view full) --- 1248If a calendar application records a future event in some location other 1249than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record, 1250the application should be robust in the presence of timezone splits 1251between now and the future time. 1252</p> 1253</section> 1254 1255<section> |
| 1256 <h2 id="leapsec">Leap seconds</h2> 1257<p> 1258The <code><abbr>tz</abbr></code> code and data can account for leap seconds, 1259thanks to code contributed by Bradley White. 1260However, the leap second support of this package is rarely used directly 1261because POSIX requires leap seconds to be excluded and many 1262software packages would mishandle leap seconds if they were present. 1263Instead, leap seconds are more commonly handled by occasionally adjusting 1264the operating system kernel clock as described in 1265<a href="tz-link.html#precision">Precision timekeeping</a>, 1266and this package by default installs a <samp>leapseconds</samp> file 1267commonly used by 1268<a href="http://www.ntp.org"><abbr title="Network Time Protocol">NTP</abbr></a> 1269software that adjusts the kernel clock. 1270However, kernel-clock twiddling approximates UTC only roughly, 1271and systems needing more-precise UTC can use this package's leap 1272second support directly. 1273</p> 1274 1275<p> 1276The directly-supported mechanism assumes that <code>time_t</code> 1277counts of seconds since the POSIX epoch normally include leap seconds, 1278as opposed to POSIX <code>time_t</code> counts which exclude leap seconds. 1279This modified timescale is converted to <abbr>UTC</abbr> 1280at the same point that time zone and DST adjustments are applied – 1281namely, at calls to <code>localtime</code> and analogous functions – 1282and the process is driven by leap second information 1283stored in alternate versions of the <abbr>TZif</abbr> files. 1284Because a leap second adjustment may be needed even 1285if no time zone correction is desired, 1286calls to <code>gmtime</code>-like functions 1287also need to consult a <abbr>TZif</abbr> file, 1288conventionally named <samp><abbr>GMT</abbr></samp>, 1289to see whether leap second corrections are needed. 1290To convert an application's <code>time_t</code> timestamps to or from 1291POSIX <code>time_t</code> timestamps (for use when, say, 1292embedding or interpreting timestamps in portable 1293<a href="https://en.wikipedia.org/wiki/Tar_(computing)"><code>tar</code></a> 1294files), 1295the application can call the utility functions 1296<code>time2posix</code> and <code>posix2time</code> 1297included with this package. 1298</p> 1299 1300<p> 1301If the POSIX-compatible <abbr>TZif</abbr> file set is installed 1302in a directory whose basename is <samp>zoneinfo</samp>, the 1303leap-second-aware file set is by default installed in a separate 1304directory <samp>zoneinfo-leaps</samp>. 1305Although each process can have its own time zone by setting 1306its <code>TZ</code> environment variable, there is no support for some 1307processes being leap-second aware while other processes are 1308POSIX-compatible; the leap-second choice is system-wide. 1309So if you configure your kernel to count leap seconds, you should also 1310discard <samp>zoneinfo</samp> and rename <samp>zoneinfo-leaps</samp> 1311to <samp>zoneinfo</samp>. 1312Alternatively, you can install just one set of <abbr>TZif</abbr> files 1313in the first place; see the <code>REDO</code> variable in this package's 1314<a href="https://en.wikipedia.org/wiki/Makefile">makefile</a>. 1315</p> 1316</section> 1317 1318<section> |
|
| 1252 <h2 id="calendar">Calendrical issues</h2> 1253<p> 1254Calendrical issues are a bit out of scope for a time zone database, 1255but they indicate the sort of problems that we would run into if we 1256extended the time zone database further into the past. 1257An excellent resource in this area is Edward M. Reingold 1258and Nachum Dershowitz, <cite><a 1259href="https://www.cambridge.org/fr/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition">Calendrical --- 126 unchanged lines hidden --- | 1319 <h2 id="calendar">Calendrical issues</h2> 1320<p> 1321Calendrical issues are a bit out of scope for a time zone database, 1322but they indicate the sort of problems that we would run into if we 1323extended the time zone database further into the past. 1324An excellent resource in this area is Edward M. Reingold 1325and Nachum Dershowitz, <cite><a 1326href="https://www.cambridge.org/fr/academic/subjects/computer-science/computing-general-interest/calendrical-calculations-ultimate-edition-4th-edition">Calendrical --- 126 unchanged lines hidden --- |