[PROPOSED] Avoid backward links in zone.tab

Recent changes caused zone.tab to refer to links defined in the 'backward' file, which means it no longer works in the now-rare case where 'backward' is not used. Fix this by changing zone.tab to refer to the primary name of each zone. * checktab.awk: Adjust to check the new setup. * zone.tab: Replace backward links in the 3rd column with the primary zone names. This lets us fix a longstanding problem with Vietnam, as zone.tab can now have a separate entry for north Vietnam's different time zone history in the 1970s (this was already true of zone1970.tab). --- checktab.awk | 48 +++++++-------- zone.tab | 161 ++++++++++++++++++++++++++------------------------- 2 files changed, 105 insertions(+), 104 deletions(-) diff --git a/checktab.awk b/checktab.awk index 54ac0a6..d5317ac 100644 --- a/checktab.awk +++ b/checktab.awk @@ -58,11 +58,12 @@ BEGIN { zone_table, zone_NR >>"/dev/stderr" status = 1 } - split($1, cca, /,/) - cc = cca[1] + ccs = input_ccs[zone_NR] = $1 coordinates = $2 tz = $3 - comments = $4 + comments = input_comments[zone_NR] = $4 + split(ccs, cca, /,/) + cc = cca[1] # Don't complain about a special case for Crimea in zone.tab. # FIXME: zone.tab should be removed, since it is obsolete. @@ -77,12 +78,9 @@ BEGIN { cc0 = cc tz0 = tz tztab[tz] = 1 - tz2comments[tz] = comments tz2NR[tz] = zone_NR for (i in cca) { cc = cca[i] - cctz = cc tz - cctztab[cctz] = 1 if (cc2name[cc]) { cc_used[cc]++ } else { @@ -99,27 +97,27 @@ BEGIN { } } - for (cctz in cctztab) { - cc = substr (cctz, 1, 2) - tz = substr (cctz, 3) - if (1 < cc_used[cc]) { - comments_needed[tz] = cc - } - } - for (cctz in cctztab) { - cc = substr (cctz, 1, 2) - tz = substr (cctz, 3) - if (!comments_needed[tz] && tz2comments[tz]) { + for (i = 1; i <= zone_NR; i++) { + ccs = input_ccs[i] + if (!ccs) continue + comments = input_comments[i] + split(ccs, cca, /,/) + used_max = 0 + for (j in cca) { + cc = cca[j] + if (used_max < cc_used[cc]) { + used_max = cc_used[cc] + } + } + if (used_max <= 1 && comments) { printf "%s:%d: unnecessary comment '%s'\n", \ - zone_table, tz2NR[tz], tz2comments[tz] \ - >>"/dev/stderr" - tz2comments[tz] = 0 + zone_table, i, comments \ + >>"/dev/stderr" status = 1 - } else if (comments_needed[tz] && !tz2comments[tz]) { + } else if (1 < cc_used[cc] && !comments) { printf "%s:%d: missing comment for %s\n", \ - zone_table, tz2NR[tz], comments_needed[tz] \ + zone_table, i, cc \ >>"/dev/stderr" - tz2comments[tz] = 1 status = 1 } } @@ -172,14 +170,12 @@ END { status = 1 } } - if (zone_table != "zone.tab") { - for (tz in tztab) { + for (tz in tztab) { if (!zoneSeen[tz]) { printf "%s:%d: no Zone table for '%s'\n", \ zone_table, tz2NR[tz], tz >>"/dev/stderr" status = 1 } - } } if (0 < want_warnings) { for (cc in cc2name) { diff --git a/zone.tab b/zone.tab index 14fceb9..fe53f0a 100644 --- a/zone.tab +++ b/zone.tab @@ -16,6 +16,10 @@ # clocks have agreed since 1970; this is a narrower definition than # that of zone1970.tab. # +# Unlike zone1970.tab, this file's third column can contain duplicates, +# and a row's third column does not necessarily name a location within +# the country identified by the row's first column. +# # This table is intended as an aid for users, to help them select timezones # appropriate for their practical needs. It is not intended to take or # endorse any position on legal or territorial claims. @@ -25,12 +29,12 @@ AD +4230+00131 Europe/Andorra AE +2518+05518 Asia/Dubai AF +3431+06912 Asia/Kabul -AG +1703-06148 America/Antigua -AI +1812-06304 America/Anguilla +AG +1703-06148 America/Port_of_Spain +AI +1812-06304 America/Port_of_Spain AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan -AO -0848+01314 Africa/Luanda -AQ -7750+16636 Antarctica/McMurdo New Zealand time - McMurdo, South Pole +AO -0848+01314 Africa/Lagos +AQ -7750+16636 Pacific/Auckland New Zealand time - McMurdo, South Pole AQ -6617+11031 Antarctica/Casey Casey AQ -6835+07758 Antarctica/Davis Davis AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville @@ -66,23 +70,23 @@ AU -3455+13835 Australia/Adelaide South Australia AU -1228+13050 Australia/Darwin Northern Territory AU -3157+11551 Australia/Perth Western Australia (most areas) AU -3143+12852 Australia/Eucla Western Australia (Eucla) -AW +1230-06958 America/Aruba -AX +6006+01957 Europe/Mariehamn +AW +1230-06958 America/Curacao +AX +6006+01957 Europe/Helsinki AZ +4023+04951 Asia/Baku -BA +4352+01825 Europe/Sarajevo +BA +4352+01825 Europe/Belgrade BB +1306-05937 America/Barbados BD +2343+09025 Asia/Dhaka BE +5050+00420 Europe/Brussels -BF +1222-00131 Africa/Ouagadougou +BF +1222-00131 Africa/Abidjan BG +4241+02319 Europe/Sofia -BH +2623+05035 Asia/Bahrain -BI -0323+02922 Africa/Bujumbura -BJ +0629+00237 Africa/Porto-Novo -BL +1753-06251 America/St_Barthelemy +BH +2623+05035 Asia/Qatar +BI -0323+02922 Africa/Maputo +BJ +0629+00237 Africa/Lagos +BL +1753-06251 America/Port_of_Spain BM +3217-06446 Atlantic/Bermuda BN +0456+11455 Asia/Brunei BO -1630-06809 America/La_Paz -BQ +120903-0681636 America/Kralendijk +BQ +120903-0681636 America/Curacao BR -0351-03225 America/Noronha Atlantic islands BR -0127-04829 America/Belem Para (east); Amapa BR -0343-03830 America/Fortaleza Brazil (northeast: MA, PI, CE, RN, PB) @@ -101,7 +105,7 @@ BR -0640-06952 America/Eirunepe Amazonas (west) BR -0958-06748 America/Rio_Branco Acre BS +2505-07721 America/Nassau BT +2728+08939 Asia/Thimphu -BW -2439+02555 Africa/Gaborone +BW -2439+02555 Africa/Maputo BY +5354+02734 Europe/Minsk BZ +1730-08812 America/Belize CA +4734-05243 America/St_Johns Newfoundland; Labrador (southeast) @@ -133,17 +137,17 @@ CA +6043-13503 America/Whitehorse MST - Yukon (east) CA +6404-13925 America/Dawson MST - Yukon (west) CA +4916-12307 America/Vancouver Pacific - BC (most areas) CC -1210+09655 Indian/Cocos -CD -0418+01518 Africa/Kinshasa Dem. Rep. of Congo (west) -CD -1140+02728 Africa/Lubumbashi Dem. Rep. of Congo (east) -CF +0422+01835 Africa/Bangui -CG -0416+01517 Africa/Brazzaville +CD -0418+01518 Africa/Lagos Dem. Rep. of Congo (west) +CD -1140+02728 Africa/Maputo Dem. Rep. of Congo (east) +CF +0422+01835 Africa/Lagos +CG -0416+01517 Africa/Lagos CH +4723+00832 Europe/Zurich CI +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago Chile (most areas) CL -5309-07055 America/Punta_Arenas Region of Magallanes CL -2709-10926 Pacific/Easter Easter Island -CM +0403+00942 Africa/Douala +CM +0403+00942 Africa/Lagos CN +3114+12128 Asia/Shanghai Beijing Time CN +4348+08735 Asia/Urumqi Xinjiang Time CO +0436-07405 America/Bogota @@ -156,10 +160,10 @@ CY +3510+03322 Asia/Nicosia Cyprus (most areas) CY +3507+03357 Asia/Famagusta Northern Cyprus CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) -DE +4742+00841 Europe/Busingen Busingen -DJ +1136+04309 Africa/Djibouti +DE +4742+00841 Europe/Zurich Swiss time +DJ +1136+04309 Africa/Nairobi DK +5540+01235 Europe/Copenhagen -DM +1518-06124 America/Dominica +DM +1518-06124 America/Port_of_Spain DO +1828-06954 America/Santo_Domingo DZ +3647+00303 Africa/Algiers EC -0210-07950 America/Guayaquil Ecuador (mainland) @@ -167,11 +171,11 @@ EC -0054-08936 Pacific/Galapagos Galapagos Islands EE +5925+02445 Europe/Tallinn EG +3003+03115 Africa/Cairo EH +2709-01312 Africa/El_Aaiun -ER +1520+03853 Africa/Asmara +ER +1520+03853 Africa/Nairobi ES +4024-00341 Europe/Madrid Spain (mainland) ES +3553-00519 Africa/Ceuta Ceuta, Melilla ES +2806-01524 Atlantic/Canary Canary Islands -ET +0902+03842 Africa/Addis_Ababa +ET +0902+03842 Africa/Nairobi FI +6010+02458 Europe/Helsinki FJ -1808+17825 Pacific/Fiji FK -5142-05751 Atlantic/Stanley @@ -180,22 +184,22 @@ FM +0658+15813 Pacific/Pohnpei Pohnpei/Ponape FM +0519+16259 Pacific/Kosrae Kosrae FO +6201-00646 Atlantic/Faroe FR +4852+00220 Europe/Paris -GA +0023+00927 Africa/Libreville +GA +0023+00927 Africa/Lagos GB +513030-0000731 Europe/London -GD +1203-06145 America/Grenada +GD +1203-06145 America/Port_of_Spain GE +4143+04449 Asia/Tbilisi GF +0456-05220 America/Cayenne -GG +492717-0023210 Europe/Guernsey +GG +492717-0023210 Europe/London GH +0533-00013 Africa/Accra GI +3608-00521 Europe/Gibraltar GL +6411-05144 America/Nuuk Greenland (most areas) GL +7646-01840 America/Danmarkshavn National Park (east coast) GL +7029-02158 America/Scoresbysund Scoresbysund/Ittoqqortoormiit GL +7634-06847 America/Thule Thule/Pituffik -GM +1328-01639 Africa/Banjul -GN +0931-01343 Africa/Conakry -GP +1614-06132 America/Guadeloupe -GQ +0345+00847 Africa/Malabo +GM +1328-01639 Africa/Abidjan +GN +0931-01343 Africa/Abidjan +GP +1614-06132 America/Port_of_Spain +GQ +0345+00847 Africa/Lagos GR +3758+02343 Europe/Athens GS -5416-03632 Atlantic/South_Georgia GT +1438-09031 America/Guatemala @@ -204,7 +208,7 @@ GW +1151-01535 Africa/Bissau GY +0648-05810 America/Guyana HK +2217+11409 Asia/Hong_Kong HN +1406-08713 America/Tegucigalpa -HR +4548+01558 Europe/Zagreb +HR +4548+01558 Europe/Belgrade HT +1832-07220 America/Port-au-Prince HU +4730+01905 Europe/Budapest ID -0610+10648 Asia/Jakarta Java, Sumatra @@ -213,29 +217,29 @@ ID -0507+11924 Asia/Makassar Borneo (east, south); Sulawesi/Celebes, Bali, Nusa ID -0232+14042 Asia/Jayapura New Guinea (West Papua / Irian Jaya); Malukus/Moluccas IE +5320-00615 Europe/Dublin IL +314650+0351326 Asia/Jerusalem -IM +5409-00428 Europe/Isle_of_Man +IM +5409-00428 Europe/London IN +2232+08822 Asia/Kolkata IO -0720+07225 Indian/Chagos IQ +3321+04425 Asia/Baghdad IR +3540+05126 Asia/Tehran IS +6409-02151 Atlantic/Reykjavik IT +4154+01229 Europe/Rome -JE +491101-0020624 Europe/Jersey +JE +491101-0020624 Europe/London JM +175805-0764736 America/Jamaica JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek -KH +1133+10455 Asia/Phnom_Penh +KH +1133+10455 Asia/Bangkok KI +0125+17300 Pacific/Tarawa Gilbert Islands KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands -KM -1141+04316 Indian/Comoro -KN +1718-06243 America/St_Kitts +KM -1141+04316 Africa/Nairobi +KN +1718-06243 America/Port_of_Spain KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul -KW +2920+04759 Asia/Kuwait -KY +1918-08123 America/Cayman +KW +2920+04759 Asia/Riyadh +KY +1918-08123 America/Panama KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) KZ +4448+06528 Asia/Qyzylorda Qyzylorda/Kyzylorda/Kzyl-Orda KZ +5312+06337 Asia/Qostanay Qostanay/Kostanay/Kustanay @@ -243,13 +247,13 @@ KZ +5017+05710 Asia/Aqtobe Aqtobe/Aktobe KZ +4431+05016 Asia/Aqtau Mangghystau/Mankistau KZ +4707+05156 Asia/Atyrau Atyrau/Atirau/Gur'yev KZ +5113+05121 Asia/Oral West Kazakhstan -LA +1758+10236 Asia/Vientiane +LA +1758+10236 Asia/Bangkok LB +3353+03530 Asia/Beirut -LC +1401-06100 America/St_Lucia -LI +4709+00931 Europe/Vaduz +LC +1401-06100 America/Port_of_Spain +LI +4709+00931 Europe/Zurich LK +0656+07951 Asia/Colombo LR +0618-01047 Africa/Monrovia -LS -2928+02730 Africa/Maseru +LS -2928+02730 Africa/Johannesburg LT +5441+02519 Europe/Vilnius LU +4936+00609 Europe/Luxembourg LV +5657+02406 Europe/Riga @@ -257,26 +261,26 @@ LY +3254+01311 Africa/Tripoli MA +3339-00735 Africa/Casablanca MC +4342+00723 Europe/Monaco MD +4700+02850 Europe/Chisinau -ME +4226+01916 Europe/Podgorica -MF +1804-06305 America/Marigot -MG -1855+04731 Indian/Antananarivo +ME +4226+01916 Europe/Belgrade +MF +1804-06305 America/Port_of_Spain +MG -1855+04731 Africa/Nairobi MH +0709+17112 Pacific/Majuro Marshall Islands (most areas) MH +0905+16720 Pacific/Kwajalein Kwajalein -MK +4159+02126 Europe/Skopje -ML +1239-00800 Africa/Bamako +MK +4159+02126 Europe/Belgrade +ML +1239-00800 Africa/Abidjan MM +1647+09610 Asia/Yangon MN +4755+10653 Asia/Ulaanbaatar Mongolia (most areas) MN +4801+09139 Asia/Hovd Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan MN +4804+11430 Asia/Choibalsan Dornod, Sukhbaatar MO +221150+1133230 Asia/Macau -MP +1512+14545 Pacific/Saipan +MP +1512+14545 Pacific/Guam MQ +1436-06105 America/Martinique -MR +1806-01557 Africa/Nouakchott -MS +1643-06213 America/Montserrat +MR +1806-01557 Africa/Abidjan +MS +1643-06213 America/Port_of_Spain MT +3554+01431 Europe/Malta MU -2010+05730 Indian/Mauritius MV +0410+07330 Indian/Maldives -MW -1547+03500 Africa/Blantyre +MW -1547+03500 Africa/Maputo MX +1924-09909 America/Mexico_City Central Time MX +2105-08646 America/Cancun Eastern Standard Time - Quintana Roo MX +2058-08937 America/Merida Central Time - Campeche, Yucatan @@ -293,7 +297,7 @@ MY +0133+11020 Asia/Kuching Sabah, Sarawak MZ -2558+03235 Africa/Maputo NA -2234+01706 Africa/Windhoek NC -2216+16627 Pacific/Noumea -NE +1331+00207 Africa/Niamey +NE +1331+00207 Africa/Lagos NF -2903+16758 Pacific/Norfolk NG +0627+00324 Africa/Lagos NI +1209-08617 America/Managua @@ -304,7 +308,7 @@ NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ -3652+17446 Pacific/Auckland New Zealand (most areas) NZ -4357-17633 Pacific/Chatham Chatham Islands -OM +2336+05835 Asia/Muscat +OM +2336+05835 Asia/Dubai PA +0858-07932 America/Panama PE -1203-07703 America/Lima PF -1732-14934 Pacific/Tahiti Society Islands @@ -359,32 +363,32 @@ RU +4658+14242 Asia/Sakhalin MSK+08 - Sakhalin Island RU +6728+15343 Asia/Srednekolymsk MSK+08 - Sakha (E); North Kuril Is RU +5301+15839 Asia/Kamchatka MSK+09 - Kamchatka RU +6445+17729 Asia/Anadyr MSK+09 - Bering Sea -RW -0157+03004 Africa/Kigali +RW -0157+03004 Africa/Maputo SA +2438+04643 Asia/Riyadh SB -0932+16012 Pacific/Guadalcanal SC -0440+05528 Indian/Mahe SD +1536+03232 Africa/Khartoum SE +5920+01803 Europe/Stockholm SG +0117+10351 Asia/Singapore -SH -1555-00542 Atlantic/St_Helena -SI +4603+01431 Europe/Ljubljana -SJ +7800+01600 Arctic/Longyearbyen -SK +4809+01707 Europe/Bratislava -SL +0830-01315 Africa/Freetown -SM +4355+01228 Europe/San_Marino -SN +1440-01726 Africa/Dakar -SO +0204+04522 Africa/Mogadishu +SH -1555-00542 Africa/Abidjan +SI +4603+01431 Europe/Belgrade +SJ +7800+01600 Europe/Oslo +SK +4809+01707 Europe/Prague +SL +0830-01315 Africa/Abidjan +SM +4355+01228 Europe/Rome +SN +1440-01726 Africa/Abidjan +SO +0204+04522 Africa/Nairobi SR +0550-05510 America/Paramaribo SS +0451+03137 Africa/Juba ST +0020+00644 Africa/Sao_Tome SV +1342-08912 America/El_Salvador -SX +180305-0630250 America/Lower_Princes +SX +180305-0630250 America/Curacao SY +3330+03618 Asia/Damascus -SZ -2618+03106 Africa/Mbabane +SZ -2618+03106 Africa/Johannesburg TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena TF -492110+0701303 Indian/Kerguelen -TG +0608+00113 Africa/Lome +TG +0608+00113 Africa/Abidjan TH +1345+10031 Asia/Bangkok TJ +3835+06848 Asia/Dushanbe TK -0922-17114 Pacific/Fakaofo @@ -396,12 +400,12 @@ TR +4101+02858 Europe/Istanbul TT +1039-06131 America/Port_of_Spain TV -0831+17913 Pacific/Funafuti TW +2503+12130 Asia/Taipei -TZ -0648+03917 Africa/Dar_es_Salaam +TZ -0648+03917 Africa/Nairobi UA +5026+03031 Europe/Kiev Ukraine (most areas) UA +4837+02218 Europe/Uzhgorod Transcarpathia UA +4750+03510 Europe/Zaporozhye Zaporozhye and east Lugansk -UG +0019+03225 Africa/Kampala -UM +2813-17722 Pacific/Midway Midway Islands +UG +0019+03225 Africa/Nairobi +UM +2813-17722 Pacific/Pago_Pago Midway Islands UM +1917+16637 Pacific/Wake Wake Island US +404251-0740023 America/New_York Eastern (most areas) US +421953-0830245 America/Detroit Eastern - MI (most areas) @@ -435,17 +439,18 @@ US +211825-1575130 Pacific/Honolulu Hawaii UY -345433-0561245 America/Montevideo UZ +3940+06648 Asia/Samarkand Uzbekistan (west) UZ +4120+06918 Asia/Tashkent Uzbekistan (east) -VA +415408+0122711 Europe/Vatican -VC +1309-06114 America/St_Vincent +VA +415408+0122711 Europe/Rome +VC +1309-06114 America/Port_of_Spain VE +1030-06656 America/Caracas -VG +1827-06437 America/Tortola -VI +1821-06456 America/St_Thomas -VN +1045+10640 Asia/Ho_Chi_Minh +VG +1827-06437 America/Port_of_Spain +VI +1821-06456 America/Port_of_Spain +VN +1045+10640 Asia/Bangkok Vietnam (north) +VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) VU -1740+16825 Pacific/Efate WF -1318-17610 Pacific/Wallis WS -1350-17144 Pacific/Apia -YE +1245+04512 Asia/Aden -YT -1247+04514 Indian/Mayotte +YE +1245+04512 Asia/Riyadh +YT -1247+04514 Africa/Nairobi ZA -2615+02800 Africa/Johannesburg -ZM -1525+02817 Africa/Lusaka -ZW -1750+03103 Africa/Harare +ZM -1525+02817 Africa/Maputo +ZW -1750+03103 Africa/Maputo -- 2.27.0

On 2021-05-09 08:45, Paul Eggert proposed:
+VN +1045+10640 Asia/Bangkok Vietnam (north)
Asia/Hanoi was not added to backward/ as a link, so it seems to be inappropriate to add it to zone.tab. But if it is added, then the coordinates should not be those of Ho Chi Minh City but those of Hanoi: +2102+10551 Michael Deckers.

On 5/9/21 3:41 AM, Michael H Deckers wrote:
+VN +1045+10640 Asia/Bangkok Vietnam (north)
Asia/Hanoi was not added to backward/ as a link, so it seems to be inappropriate to add it to zone.tab.
Asia/Hanoi is different from most of the other cases, as the situation with Hanoi was discovered after the guidelines were changed (so there was no need to add Asia/Hanoi) whereas most of the other cases (e.g., America/St_Thomas) were added before that. For example, had the new guideline been in place earlier, zone.tab would still have its current line "VI +1821-06456 America/Port_of_Spain" even though there would be no America/St_Thomas link in 'backward'. By the way, that "VI +1821-06456 America/Port_of_Spain" is not right; that line should refer to America/Puerto_Rico instead. Port-of-Spain and San Juan, Puerto Rico have agreed since 1970 and the latter is bigger, so America/Port_of_Spain should also be moved to 'backzone'. There are several other examples like that, and we could shrink the installed set of TZif files significantly if this sort of thing were fixed. I plan to take a look into that.
But if it is added, then the coordinates should not be those of Ho Chi Minh City but those of Hanoi: +2102+10551
Thanks, good point, I installed the attached. Although zone.tab is deprecated I imagine some apps are still using it.

On 5/9/21 6:30 PM, Paul Eggert wrote:
By the way, that "VI +1821-06456 America/Port_of_Spain" is not right; that line should refer to America/Puerto_Rico instead. Port-of-Spain and San Juan, Puerto Rico have agreed since 1970 and the latter is bigger, so America/Port_of_Spain should also be moved to 'backzone'. There are several other examples like that, and we could shrink the installed set of TZif files significantly if this sort of thing were fixed.
Attached is a proposed patch to do that. The idea is to move Zones into 'backward' if they're identical to some other Zone after 1970. In other words, this patch doesn't affect timestamps after 1970. In that sense, this patch builds on similar patches in 2014 and 2015 that moved out-of-scope Zones like Africa/Kinshasa to 'backzone', with backward-compatibility links in 'backward'. Although I've tested this patch, I'd like to do more tests before installing it into the development tzdb repository on GitHub. Also, the patch needs a proper NEWS entry and commit message before installing. Comments are welcome in the meantime.

On 2021-05-10 08:38, Paul Eggert wrote:
The idea is to move Zones into 'backward' if they're identical to some other Zone after 1970.
If these rules really hold for backzone (are they listed anywhere?), then America/Curacao also should go to backzone, and one of Africa/Johannesburg and Africa/Maputo and three of Pacific/Majuro, Pacific/Tarawa, Pacific/Funafuti, Pacific/Mata-Utu should go to backzone. By the way, do these rules imply that Pacific/Yap with the data as of 2005k belongs to backzone? A remark on backward compatibility: The proposed change is not conservative in the sense that information that could automatically be extracted from previous versions is no longer available in this way. To wit: It is no longer possible to automatically find geographical coordinates for the tzdb timezones described in backzone. In previous versions, the name of a tzdb timezone in backzone could also be found in zone.tab together with its country code and the coordinates for its location (except for backzone/Asia/Hanoi). After the change, there is no systematic way to find the right line in zone.tab with the coordinates, even if one supposes that one can automatically deduce the ISO country code for the name of a tzdb timezone in backzone (which is quite tricky and not so simple as in previous versions). Only the comment entry in a line of zone.tab (such as "Vietnam (south)") gives some indication on the name of the timezone (eg, Asia/Ho_Chi_Minh) whose geographic coordinates are contained in that line. I am aware that zone.tab is deprecated, so that one could say that the previously possible method was not guaranteed to work across versions -- but then the locations for backzone timezones could be omitted or put somewhere where they can be found automatically. Michael Deckers.

On 5/10/21 3:43 AM, Michael H Deckers wrote:
On 2021-05-10 08:38, Paul Eggert wrote:
The idea is to move Zones into 'backward' if they're identical to some other Zone after 1970.
If these rules really hold for backzone (are they listed anywhere?),
theory.html says that tzdb records civil time by "partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch". Although it's true that the existence of such a partition doesn't logically require that each Zone history be distinct after the Epoch, that is the intent nowadays. I suppose this should be stated more clearly once the patch is installed.
America/Curacao also should go to backzone,
Yes, the proposed patch does this.
and one of Africa/Johannesburg and Africa/Maputo and three of Pacific/Majuro, Pacific/Tarawa, Pacific/Funafuti, Pacific/Mata-Utu should go to backzone.
Although Africa/Johannesburg and Africa/Maputo have identical UTC offset histories after 1970, they disagree about time zone abbreviations and so are not coalesced in the proposed patch. The proposed patch does move those Pacific/* names to 'backzone', as they are all equivalent to Etc/GMT-12 after 1970. (tzdb uses 'Pacific/Wallis' instead of 'Pacific/Mata-Utu'.)
By the way, do these rules imply that Pacific/Yap with the data as of 2005k belongs to backzone?
I don't recall that entry, but if someone would submit a patch (git format-patch format, please) for it we could add it to 'backzone'.
In previous versions, the name of a tzdb timezone in backzone could also be found in zone.tab together with its country code and the coordinates for its location (except for backzone/Asia/Hanoi).
That was just luck having to do with a deprecated file; it wasn't intended. Perhaps someone could add systematically-formatted comments to 'backzone' giving geographical coordinates for names like Asia/Hanoi that are not already mentioned in 'zone1970.tab'. I wouldn't rely on 'zone.tab' as it's deprecated. PS. All my 'backzone' suggestions in this email are low priority, as stuff moved to 'backzone' is out of scope for tzdb proper. That's the main point of 'backzone', after all - to lessen the burden of data outside the scope of the project.

On 5/10/21 11:04 AM, Paul Eggert wrote:
theory.html says that tzdb records civil time by "partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch". Although it's true that the existence of such a partition doesn't logically require that each Zone history be distinct after the Epoch, that is the intent nowadays. I suppose this should be stated more clearly
On further thought, this point should be covered adequately later in theory.html, where it says "If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970." However, I did notice that the wording said all tzdb timezone names are location-based, which isn't true for timezones like Etc/GMT-10. I installed the attached to try to fix this.

On 2021-05-10 18:04, Paul Eggert wrote:
Perhaps someone could add systematically-formatted comments to 'backzone' giving geographical coordinates for names like Asia/Hanoi that are not already mentioned in 'zone1970.tab'.
Yes, I understand. Just to make sure: my point is not a question only for backzone data. What happens with the proposed change is that any location name of a timezone in the mainline tzdb data can no longer be (easily) connected with geographical coordinates as soon as the location name (is a link and) also occurs in the backzone file. Rather, the corresponding geographic coordinates in zone.tab are no longer connected with the timezone name, only with an ISO country code. The same holds for several proposed lines in zone1070.tab such as AQ,KW,SA,YE +2438+04643 Etc/GMT-3 Arabia, Syowa What are these geographical coordinates supposed to indicate? Of course, there is no error (all the advertised functions of tzdb will continue to work, except perhaps choosing Syowa with tzselect) -- it is only my failure to understand the conceptual schema of the tzdb data. One of the successful design choices of the tzdb database was to identify timezones by locations (rather than by areas or countries), so that location names and location coordinates are equivalent means of identifying timezones of locations. Is this still true? Michael Deckers.

On 5/11/21 5:32 AM, Michael H Deckers wrote:
Rather, the corresponding geographic coordinates in zone.tab are no longer connected with the timezone name, only with an ISO country code.
I wouldn't put it that way. In zone.tab, a line's geographic coordinates are connected with both the country code and the timezone name. That is, the coordinates identify a location that is both (a) in the country, and (b) has clocks that have agreed with the timezone since 1970.
The same holds for several proposed lines in zone1070.tab such as AQ,KW,SA,YE +2438+04643 Etc/GMT-3 Arabia, Syowa What are these geographical coordinates supposed to indicate?
They indicate a major location within the designated area. This is the same as the non-Etc lines in zone1970.tab, and it's the same role they play in zone.tab.
One of the successful design choices of the tzdb database was to identify timezones by locations (rather than by areas or countries), so that location names and location coordinates are equivalent means of identifying timezones of locations. Is this still true?
That depends on what one means by "equivalent" :-). Timezone names like Etc/GMT never identified single locations all that well. An alternative strategy to what's proposed in the patch, is to keep a single location-based Zone in place of each Etc/* name that the patch uses. For example, where the patch proposes making several names (Asia/Dubai, Asia/Muscat, Indian/Mahe, Indian/Reunion) backward-compatibility aliases for Etc/GMT-4, we could instead keep Asia/Dubai (the most-populous location) as a Zone, and have the other names be backward-compatibility aliases for Asia/Dubai. In the long run this approach would be a bit more work than what the patch proposes, as it'd mean we should continue to maintain out-of-scope (pre-1970) data for Asia/Dubai, Asia/Bangkok, etc. The main advantage of it would be avoiding Etc/* names as link targets and in zone*.tab files.

On 5/10/21 1:38 AM, Paul Eggert wrote:
I'd like to do more tests before installing it into the development tzdb repository on GitHub. Also, the patch needs a proper NEWS entry and commit message before installing.
I did that and installed the attached revised patch into the development repository. The second attachment 'adjustments.diff' attempts to records adjustments to this patch, compared to the patch I circulated ten days ago. 'adjustments.diff' is hand-edited due to merges and so is intended only for human consumption. The most significant adjustment was to add Link lines to 'backzone' so that people interested in out-of-scope pre-1970 data won't see any changes due to this patch. There are also some adjustments to commentary and a dependency fix in the Makefile.

On 2021-05-21 01:57:48 (+0800), Paul Eggert via tz wrote:
On 5/10/21 1:38 AM, Paul Eggert wrote:
I'd like to do more tests before installing it into the development tzdb repository on GitHub. Also, the patch needs a proper NEWS entry and commit message before installing.
I did that and installed the attached revised patch into the development repository.
The second attachment 'adjustments.diff' attempts to records adjustments to this patch, compared to the patch I circulated ten days ago. 'adjustments.diff' is hand-edited due to merges and so is intended only for human consumption.
The most significant adjustment was to add Link lines to 'backzone' so that people interested in out-of-scope pre-1970 data won't see any changes due to this patch. There are also some adjustments to commentary and a dependency fix in the Makefile.
I think the first part of this change (merging timezones with no changes post-1970) makes a lot of sense. I'm less convinced about the second part of the change (merging timezones into Etc). That feels like indirection for the sake of indirection. The end result looks correct though. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

On Sat, 22 May 2021 at 03:09, Philip Paeps via tz <tz@iana.org> wrote:
I think the first part of this change (merging timezones with no changes post-1970) makes a lot of sense. I'm less convinced about the second part of the change (merging timezones into Etc). That feels like indirection for the sake of indirection.
I'm inclined to agree here. In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices: 1. using fixed-offset zones for civil time with the blind expectation that it won't need to change 2. the "backwards" offset signs from POSIX 3. the outdated GMT-vs-UT(C) solecism Arguably, helping to prevent (1) is the entire point of this project. The others, while less of a concern, have been continually de-emphasized enough over the years here that I'm not sure that giving them increased prominence is a good thing. That said, I do broadly support the consolidation of purely geographical zones like Europe/Monaco -> Europe/Paris (retaining historical work in backzone). I think, in most cases, a stricter 1970 principle can be reasonably explained to passers-by. Especially since we deal with cities/communities and not borders, contiguity need not even be a requirement — though if any of the resulting pairings are particularly far-flung (I haven't checked thoroughly yet), a small amount of duplication may be advisable and otherwise unavoidable. -- Tim Parenti

On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
if any of the resulting pairings are particularly far-flung (I haven't checked thoroughly yet)
Some are far-flung but that should be OK. It shouldn't matter, for example, that Asia/Dubai and Asia/Reunion are aliases even though Dubai and Réunion are separated by 5000 km of ocean and disparate political systems. Users of those aliases shouldn't care, any more than users of Europe/Copenhagen and Europe/Berlin should care.

On May 22, 2021, at 11:33 AM, Paul Eggert via tz <tz@iana.org> wrote:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz
I.e., have Etc/GMT+4 be a link to America/La_Paz? If so, presumably we'd remember to break the link if Bolivia decides to adopt DST.

On 5/22/21 12:29 PM, Guy Harris wrote:
I.e., have Etc/GMT+4 be a link to America/La_Paz?
If so, presumably we'd remember to break the link if Bolivia decides to adopt DST.
Yes, quite so. It'd be treated like any other link-breaking.

Paul Eggert via tz <tz@iana.org> writes:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
That seems really bad. If I ask for Etc/GMT+4, I should get a fixed GMT+4 offset for all time, not whatever the heck Bolivia's pre-1970 behavior was. Those zone names are not, or at least should not be, conditional on political decisions. IMO, Etc/GMT+4 is just an alternative way to spell the '<-04>4' notation ... one that could be very handy if dealing with software that knows the tzdb names but not POSIX notation. regards, tom lane

On 2021-05-22 14:10, Tom Lane via tz wrote:
Paul Eggert via tz <tz@iana.org> writes:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
That seems really bad. If I ask for Etc/GMT+4, I should get a fixed GMT+4 offset for all time, not whatever the heck Bolivia's pre-1970 behavior was. Those zone names are not, or at least should not be, conditional on political decisions. IMO, Etc/GMT+4 is just an alternative way to spell the '<-04>4' notation ... one that could be very handy if dealing with software that knows the tzdb names but not POSIX notation.
+1 agreed - please *NEVER* merge fixed offset and political zones! They are not the same thing and a little duplication to avoid errors is good. I think I will also add local links with the expected offsets for Etc/UTC+-# to POSIX Etc/GMT-+#, to my current local links of phonetic and military zones. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

Brian Inglis via tz said:
On 2021-05-22 14:10, Tom Lane via tz wrote:
Paul Eggert via tz <tz@iana.org> writes:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
That seems really bad. If I ask for Etc/GMT+4, I should get a fixed GMT+4 offset for all time, not whatever the heck Bolivia's pre-1970 behavior was. Those zone names are not, or at least should not be, conditional on political decisions. IMO, Etc/GMT+4 is just an alternative way to spell the '<-04>4' notation ... one that could be very handy if dealing with software that knows the tzdb names but not POSIX notation.
+1 agreed - please *NEVER* merge fixed offset and political zones! They are not the same thing and a little duplication to avoid errors is good.
+2 agreed. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

+3 Mark On Sat, May 22, 2021 at 3:51 PM Clive D.W. Feather via tz <tz@iana.org> wrote:
Brian Inglis via tz said:
On 2021-05-22 14:10, Tom Lane via tz wrote:
Paul Eggert via tz <tz@iana.org> writes:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
That seems really bad. If I ask for Etc/GMT+4, I should get a fixed GMT+4 offset for all time, not whatever the heck Bolivia's pre-1970 behavior was. Those zone names are not, or at least should not be, conditional on political decisions. IMO, Etc/GMT+4 is just an alternative way to spell the '<-04>4' notation ... one that could be very handy if dealing with software that knows the tzdb names but not POSIX notation.
+1 agreed - please *NEVER* merge fixed offset and political zones! They are not the same thing and a little duplication to avoid errors is good.
+2 agreed.
-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 2021-05-23 02:33:22 (+0800), Paul Eggert wrote:
On 5/22/21 11:17 AM, Tim Parenti wrote:
In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
We could avoid these problems by merging Etc/GMT+4 into America/La_Paz rather than vice versa. That would be easy to arrange, and would result in the same number of timezones. A downside would be that TZ='Etc/GMT+4' would no longer be equivalent to TZ='<-04>4' for pre-1970 timestamps, but those timestamps are out of scope anyway.
While those timestamps are out of scope, software exists that is aware of tzdb names but not the intricate details of POSIX TZ strings. There are use cases where being able to set a fixed-offset timezone is desired. Breaking the current behaviour for pre-1970 timestamps would not be cool. I'd even suggest documenting explicitly that Etc/* are aliases for fixed offsets.
if any of the resulting pairings are particularly far-flung (I haven't checked thoroughly yet)
Some are far-flung but that should be OK. It shouldn't matter, for example, that Asia/Dubai and Asia/Reunion are aliases even though Dubai and Réunion are separated by 5000 km of ocean and disparate political systems. Users of those aliases shouldn't care, any more than users of Europe/Copenhagen and Europe/Berlin should care.
(I assume Indian/Reunion. :)) I agree that this should not be a concern. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

On 5/22/21 11:17 AM, Tim Parenti wrote:
I'm inclined to agree here. In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
Yes, it appears that I may have gone a bit too far in consolidating Etc/* names with other names. I undid that part of the change by installing the attached followup patch (first patch).

I examined the changes this makes using my tzdiff tool: https://github.com/jodastephen/tzdiff/commit/bbeef1aae8797ecdf28202b751fdd01... To me, this seems like an awful change. As can be seen in the link, many places (eg Anguilla, Antigua and Aruba) are now sharing time-zone history, and that history is **from some other zone**. That seems completely unacceptable. While I understand the motivation to remove the burden of pre-1970, that cannot come at the cost of giving a place the history of somewhere completely different. I ask that this change is completely reverted. Stephen On Thu, 27 May 2021 at 03:00, Paul Eggert via tz <tz@iana.org> wrote:
On 5/22/21 11:17 AM, Tim Parenti wrote:
I'm inclined to agree here. In particular, the latter group (things like America/La_Paz -> Etc/GMT+4) seems to encourage things or behaviors which historically cause confusion, especially for novices:
Yes, it appears that I may have gone a bit too far in consolidating Etc/* names with other names. I undid that part of the change by installing the attached followup patch (first patch).

Stephen Colebourne via tz said:
As can be seen in the link, many places (eg Anguilla, Antigua and Aruba) are now sharing time-zone history, and that history is **from some other zone**. That seems completely unacceptable.
While I understand the motivation to remove the burden of pre-1970, that cannot come at the cost of giving a place the history of somewhere completely different.
But that's been the case ever since we stopped creating new zones when we discovered a bit of pre-1970 history. All that's happened is that this is now being done across countries rather than only within a country. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Thu, May 27, 2021 at 11:50:39AM +0100, Clive D.W. Feather via tz wrote:
Stephen Colebourne via tz said:
As can be seen in the link, many places (eg Anguilla, Antigua and Aruba) are now sharing time-zone history, and that history is **from some other zone**. That seems completely unacceptable.
While I understand the motivation to remove the burden of pre-1970, that cannot come at the cost of giving a place the history of somewhere completely different.
But that's been the case ever since we stopped creating new zones when we discovered a bit of pre-1970 history. All that's happened is that this is now being done across countries rather than only within a country.
I think Stephen says that no place should have any pre-1970 history if this change is passed. The remaining superzones should also be stripped of any historical data since it would be incorrect for a whole lot more places in the zone than it is now. What will happen with all that data? It is quite interesting to read the tzdb sources as of now because of all the extra history. /MF

On 2021-05-28 17:10, Magnus Fromreide via tz wrote:
The remaining superzones should also be stripped of any historical data since it would be incorrect for a whole lot more places in the zone than it is now.
* "Stripping" historical data is not possible in the tzif format. A timezone with name N will give, before 1970, the correct values for some location, but not necessarily for the location named N (if the location named N does not appear in the file backzone then they are guaranteed to be for the location N, but this cannot be detected from the tzif files). In my opinion, this is better than the previous choice (where the data before 1970 could be incorrect for every location agreeing with N after 1970). *
What will happen with all that data? It is quite interesting to read the tzdb sources as of now because of all the extra history.
Yes, it is! The historical date are not (all) lost; most are kept in the file backzone and can be made to reappear with appropriate zic option (PACKRAT). Michael Deckers.

This change would make sense if no pre-1970 data was available for any zone (including LMT). But instead what users get is the data of somewhere else. For example, Norway's and Sweden's time zone history is being wiped out in favour of that of Germany. Can no-one here see the political sensitivity in that? This has a very serious impact on Joda-Time because it normalizes time-zone IDs. (It treats a Link as the key to the normalization, so anything at the weak end of a Link is replaced by the ID at the strong end. You might complain that it shouldn't do that, but it has operated that way for 20 years...) This code: DateTimeZone zone = DateTimeZone.forID("Europe/Stockholm"); System.out.println(zone); will print "Europe/Berlin" if this change is not reverted. I consider this to be catastrophic. I maintain, as I always have, that the bare minimum tzdb should provide is a full time-zone with history (not a Link) for each region identified by an ISO-3166-1 code. Stephen On Fri, 28 May 2021 at 20:52, Michael H Deckers <michael.h.deckers@googlemail.com> wrote:
On 2021-05-28 17:10, Magnus Fromreide via tz wrote:
The remaining superzones should also be stripped of any historical data since it would be incorrect for a whole lot more places in the zone than it is now.
* "Stripping" historical data is not possible in the tzif format.
A timezone with name N will give, before 1970, the correct values for some location, but not necessarily for the location named N (if the location named N does not appear in the file backzone then they are guaranteed to be for the location N, but this cannot be detected from the tzif files).
In my opinion, this is better than the previous choice (where the data before 1970 could be incorrect for every location agreeing with N after 1970). *
What will happen with all that data? It is quite interesting to read the tzdb sources as of now because of all the extra history.
Yes, it is! The historical date are not (all) lost; most are kept in the file backzone and can be made to reappear with appropriate zic option (PACKRAT).
Michael Deckers.

Stephen Colebourne wrote in <CACzrW9BnYgeYEcnfzDyVB6J4r2i_dZfnCE5jBDC-f6pdbAB+Uw@mail.gmail.com>: |This change would make sense if no pre-1970 data was available for any |zone (including LMT). But instead what users get is the data of |somewhere else. | |For example, Norway's and Sweden's time zone history is being wiped |out in favour of that of Germany. Can no-one here see the political |sensitivity in that? After they were marauding terribly in what is now Germany they started to instead marry the women ~170 years ago? (Do not get me started on the French!) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Steffen Nurpmeso wrote in <20210528222347.U4cDq%steffen@sdaoden.eu>: |Stephen Colebourne wrote in | <CACzrW9BnYgeYEcnfzDyVB6J4r2i_dZfnCE5jBDC-f6pdbAB+Uw@mail.gmail.com>: ||This change would make sense if no pre-1970 data was available for any ||zone (including LMT). But instead what users get is the data of ||somewhere else. || ||For example, Norway's and Sweden's time zone history is being wiped ||out in favour of that of Germany. Can no-one here see the political ||sensitivity in that? I find it astonishing that this comes up over and over again. Like i said in 2019, Paul Eggert once said something about numeric IDs. I like the idea of giving an anonymous ID to unique timezone "paths", and instead using links which point to the paths. You know, what now is Europe/Berlin would be whatever airplane registration, and Europe/Berlin /Stockholm /xy would simply point to that, for example Europe/001. Whereas i do not think this would stop problems (if new paths would have to be introduced which can only be linked to one location that someone does not want to be linked), it would not be that apparent. And do not get me started on the ship-hating Britons either. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Wed, 2 Jun 2021, Steffen Nurpmeso via tz wrote:
Steffen Nurpmeso wrote in <20210528222347.U4cDq%steffen@sdaoden.eu>: |Stephen Colebourne wrote in | <CACzrW9BnYgeYEcnfzDyVB6J4r2i_dZfnCE5jBDC-f6pdbAB+Uw@mail.gmail.com>: ||This change would make sense if no pre-1970 data was available for any ||zone (including LMT). But instead what users get is the data of ||somewhere else. || ||For example, Norway's and Sweden's time zone history is being wiped ||out in favour of that of Germany. Can no-one here see the political ||sensitivity in that?
I find it astonishing that this comes up over and over again. Like i said in 2019, Paul Eggert once said something about numeric IDs. I like the idea of giving an anonymous ID to unique timezone "paths", and instead using links which point to the paths. You know, what now is Europe/Berlin would be whatever airplane registration, and Europe/Berlin /Stockholm /xy would simply point to that, for example Europe/001. Whereas i do not think this would stop problems (if new paths would have to be introduced which can only be linked to one location that someone does not want to be linked), it would not be that apparent.
FWIW, the issue here isn't about the naming of zones. It is about removing historical data of one country, and replacing it by the historical data from a different country.
And do not get me started on the ship-hating Britons either.
I don't hate ships. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug

Derick Rethans wrote in <alpine.DEB.2.23.453.2106031721460.2842@singlemalt.home.derickrethans.nl>: |On Wed, 2 Jun 2021, Steffen Nurpmeso via tz wrote: |> Steffen Nurpmeso wrote in |> <20210528222347.U4cDq%steffen@sdaoden.eu>: |>|Stephen Colebourne wrote in |>| <CACzrW9BnYgeYEcnfzDyVB6J4r2i_dZfnCE5jBDC-f6pdbAB+Uw@mail.gmail.com>: |>||This change would make sense if no pre-1970 data was available for any |>||zone (including LMT). But instead what users get is the data of |>||somewhere else. |>|| |>||For example, Norway's and Sweden's time zone history is being wiped |>||out in favour of that of Germany. Can no-one here see the political |>||sensitivity in that? |> |> I find it astonishing that this comes up over and over again. |> Like i said in 2019, Paul Eggert once said something about numeric |> IDs. I like the idea of giving an anonymous ID to unique timezone |> "paths", and instead using links which point to the paths. You |> know, what now is Europe/Berlin would be whatever airplane |> registration, and Europe/Berlin /Stockholm /xy would simply point |> to that, for example Europe/001. |> Whereas i do not think this would stop problems (if new paths |> would have to be introduced which can only be linked to one |> location that someone does not want to be linked), it would not be |> that apparent. | |FWIW, the issue here isn't about the naming of zones. It is about |removing historical data of one country, and replacing it by the |historical data from a different country. You only have a string, either from $TZ or some direct user selection. You link this string to a set of rules. It happens that if you move the mask of the rules back and forth, the number of paths through the set of rules grows or shrinks. As long as you can link name->rules, and, at the time the data is packaged, rules->name, everything is fine, is it? I have no idea how one could end up with Europe/Berlin when the initial TZ was Europe/Stockholm, really. (I have not looked into that for now quite a lot of years, too, however. But as i recall you have by-zone begin/end tuples into the packed data.) Where is this "they are only ids, they are only ids?" They are only ids, no? If they are not, then they should be anonymized and the name->rules has to happen at packaging time. So if a small computer, say, a refrigerator, wants to pack data "from now on", it can ship a very small set of rules. |> And do not get me started on the ship-hating Britons either. | |I don't hate ships. Oh the terrible pain due to Britons wrecking beautiful Flying P-Liners! The beauty!, lost to beasts. It is a shame. But, am i complaining? We say Vaterland (father's land) not Mutterland (mother's land), otherwise i would say sometimes facts have to put on the table, and pointing with a finger onto Germany just misses the three fingers that point back. Cheerio. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Fri, Jun 4, 2021 at 10:26 PM Steffen Nurpmeso via tz <tz@iana.org> wrote:
Oh the terrible pain due to Britons wrecking beautiful Flying P-Liners! The beauty!, lost to beasts. It is a shame. But, am i complaining? We say Vaterland (father's land) not Mutterland (mother's land), otherwise i would say sometimes facts have to put on the table, and pointing with a finger onto Germany just misses the three fingers that point back.
... and that is why, Herren, I point out blame with my big toe! -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

Hello. Sanjeev Gupta wrote in <CAHZk5WfQic1J+_RQpPba22yjrnfaRaOUxcnibiJj+ZNKrpQZRA@mail.gmail.com>: |On Fri, Jun 4, 2021 at 10:26 PM Steffen Nurpmeso via tz <tz@iana.org> \ |wrote: |> Oh the terrible pain due to Britons wrecking beautiful Flying |> P-Liners! The beauty!, lost to beasts. It is a shame. |> But, am i complaining? We say Vaterland (father's land) not |> Mutterland (mother's land), otherwise i would say sometimes facts |> have to put on the table, and pointing with a finger onto Germany |> just misses the three fingers that point back. | |... and that is why, Herren, I point out blame with my big toe! ^"meine " ...and wait a bit. Of course we are white men too, this must not be forgotten. Our emperor was the grandson of the English queen, and our Duke here in Hesse was related also. We love the Brits, as a matter of fact. Our emperor said to Daily Telegraph, in England, in 1908, "You English are mad, mad, mad as March hares". With their paws high in the air. Anyhow this is completely off-topic, and all that is left to hope for 2021 (now that it only sees half a war on Iran) is that the new aircraft carrier that will cross Chinese waters in a few months as has been announced many months ago will not again cause the few whales that are still alive to try to leave the water as wargames are played. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Jun 3, 2021, at 12:41 PM, Steffen Nurpmeso via tz <tz@iana.org> wrote:
Derick Rethans wrote in <alpine.DEB.2.23.453.2106031721460.2842@singlemalt.home.derickrethans.nl>:
FWIW, the issue here isn't about the naming of zones. It is about removing historical data of one country, and replacing it by the historical data from a different country.
You only have a string, either from $TZ or some direct user selection. You link this string to a set of rules. It happens that if you move the mask of the rules back and forth, the number of paths through the set of rules grows or shrinks. As long as you can link name->rules, and, at the time the data is packaged, rules->name, everything is fine, is it? I have no idea how one could end up with Europe/Berlin when the initial TZ was Europe/Stockholm, really. (I have not looked into that for now quite a lot of years, too, however. But as i recall you have by-zone begin/end tuples into the packed data.)
You have the string Europe/Stockholm. Prior to Paul's change, it referred to a tzdb region with the lines Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 1:00:14 - SET 1900 Jan 1 # Swedish Time 1:00 - CET 1916 May 14 23:00 1:00 1:00 CEST 1916 Oct 1 1:00 1:00 - CET 1980 1:00 EU CE%sT After Paul's change, it's an alias for Europe/Berlin: Link Europe/Berlin Europe/Stockholm which is a tzdb region with the lines Zone Europe/Berlin 0:53:28 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 May 24 2:00 1:00 SovietZone CE%sT 1946 1:00 Germany CE%sT 1980 1:00 EU CE%sT Post-1980, they're the same. Preceding that: Obviously, LMT is different, but anybody who wants to know the offset from (proleptic) UTC for a given location before standard time was established in a region containing that location is best advised to use something other than the tzdb. The C-Eur rules are (most comments elided, we all know where the find the source files): # Older C-Eur rules are for convenience in the tables. # From 1977 on, C-Eur differs from EU only in that C-Eur uses standard time. Rule C-Eur 1916 only - Apr 30 23:00 1:00 S Rule C-Eur 1916 only - Oct 1 1:00 0 - Rule C-Eur 1917 1918 - Apr Mon>=15 2:00s 1:00 S Rule C-Eur 1917 1918 - Sep Mon>=15 2:00s 0 - Rule C-Eur 1940 only - Apr 1 2:00s 1:00 S Rule C-Eur 1942 only - Nov 2 2:00s 0 - Rule C-Eur 1943 only - Mar 29 2:00s 1:00 S Rule C-Eur 1943 only - Oct 4 2:00s 0 - Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S Rule C-Eur 1944 only - Oct 2 2:00s 0 - Rule C-Eur 1945 only - Sep 16 2:00s 0 - Rule C-Eur 1977 1980 - Apr Sun>=1 2:00s 1:00 S Rule C-Eur 1977 only - Sep lastSun 2:00s 0 - Rule C-Eur 1978 only - Oct 1 2:00s 0 - Rule C-Eur 1979 1995 - Sep lastSun 2:00s 0 - Rule C-Eur 1981 max - Mar lastSun 2:00s 1:00 S Rule C-Eur 1996 max - Oct lastSun 2:00s 0 - and the SovietZone rules are: Rule SovietZone 1945 only - May 24 2:00 2:00 M # Midsummer Rule SovietZone 1945 only - Sep 24 3:00 1:00 S Rule SovietZone 1945 only - Nov 18 2:00s 0 - and the Germany rules are: Rule Germany 1946 only - Apr 14 2:00s 1:00 S Rule Germany 1946 only - Oct 7 2:00s 0 - Rule Germany 1947 1949 - Oct Sun>=1 2:00s 0 - Rule Germany 1947 only - Apr 6 3:00s 1:00 S Rule Germany 1947 only - May 11 2:00s 2:00 M Rule Germany 1947 only - Jun 29 3:00 1:00 S Rule Germany 1948 only - Apr 18 2:00s 1:00 S Rule Germany 1949 only - Apr 10 2:00s 1:00 S so, for at least some times prior to 1980, using "Europe/Stockholm" before the change results in no summer time changes and using "Europe/Stockholm" after the change results in whatever summer time changes took place in Germany. It *looks* as if, after 1949, there were no such changes until 1980 when, apparently, both Sweden and Germany adopted the EU rules: Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S Rule EU 1977 only - Sep lastSun 1:00u 0 - Rule EU 1978 only - Oct 1 1:00u 0 - Rule EU 1979 1995 - Sep lastSun 1:00u 0 - Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - If so, then only pre-1949 times will convert differently; that's the "historical data" in question.

Hello. Guy Harris wrote in <19E9510C-884F-448F-8818-27C7DEB777CC@sonic.net>: |On Jun 3, 2021, at 12:41 PM, Steffen Nurpmeso via tz <tz@iana.org> wrote: |> Derick Rethans wrote in |> <alpine.DEB.2.23.453.2106031721460.2842@singlemalt.home.derickrethans.nl\ ... |>> FWIW, the issue here isn't about the naming of zones. It is about |>> removing historical data of one country, and replacing it by the |>> historical data from a different country. |> |> You only have a string, either from $TZ or some direct user |> selection. You link this string to a set of rules. |> It happens that if you move the mask of the rules back and forth, |> the number of paths through the set of rules grows or shrinks. |> As long as you can link name->rules, and, at the time the data is |> packaged, rules->name, everything is fine, is it? |> I have no idea how one could end up with Europe/Berlin when the |> initial TZ was Europe/Stockholm, really. (I have not looked into |> that for now quite a lot of years, too, however. But as i recall |> you have by-zone begin/end tuples into the packed data.) | |You have the string Europe/Stockholm. | |Prior to Paul's change, it referred to a tzdb region with the lines | |Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 | 1:00:14 - SET 1900 Jan 1 # Swedish Time | 1:00 - CET 1916 May 14 23:00 | 1:00 1:00 CEST 1916 Oct 1 1:00 | 1:00 - CET 1980 | 1:00 EU CE%sT | |After Paul's change, it's an alias for Europe/Berlin: | |Link Europe/Berlin Europe/Stockholm | |which is a tzdb region with the lines | |Zone Europe/Berlin 0:53:28 - LMT 1893 Apr | 1:00 C-Eur CE%sT 1945 May 24 2:00 | 1:00 SovietZone CE%sT 1946 | 1:00 Germany CE%sT 1980 | 1:00 EU CE%sT | |Post-1980, they're the same. I skip the rest of your explanation. Thank you for going all that way, but it was not meant "that" literally. So i have fetched myself a copy of the repository again, and i am thankful that the data as such, including the comments, is still there. It was what thrilled me so much over two decades ago when i first encountered the data, i was browsing in it for long hours. I did not know by then that behind the shiny dickeys of many entries there was nothing but hot air. I think tz is fantastic. I would not do it like this myself. I deem the data important, and i do not want to look into "backzone" after reading for example "europe" just to see if i missed something. I would rather change the extraction tools than the data itself. Also i think if i were to draw a line, where the epoch seems reasonable for C programming interfaces based upon time_t, then history cannot go further back. If i were to provide access to date and time before the epoch, however, available data should be included. I have not looked at PHP nor JAVA for twenty years, and never at NodeJS, but if these interfaces provide access to date and time outside the scope of the standardized C interfaces, then they surely parse the data and create databases on their own. This is what i did; unfortunately my code was neither bug free nor accounted for negative DST adjustments, to be honest. Today i think i would just extract data out of the compiled TZif files. As long as one can download a tarball and get away with a very portable "make PACKRATDATA=backzone zones" to have access to readily prepared full history, i would be satisfied, being happy to be able to get data from somewhere at all! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On 2021-05-28 20:44, Stephen Colebourne via tz wrote:
I maintain, as I always have, that the bare minimum tzdb should provide is a full time-zone with history (not a Link) for each region identified by an ISO-3166-1 code. I think you can have exactly that if you use the backzone data. This is even more stable than the non-backzone data), because a timezone changes only when the data for this very timezone are changed (as opposed to a timezone that was or is linked to it).
Michael Deckers.

On May 28, 2021, at 1:44 PM, Stephen Colebourne via tz <tz@iana.org> wrote:
I maintain, as I always have, that the bare minimum tzdb should provide is a full time-zone with history
History going back how far? And to what extent should we offer a guarantee of historical accuracy?
for each region identified by an ISO-3166-1 code.
What about regions that aren't? (Not all are.)

History going back how far?
And to what extent should we offer a guarantee of historical accuracy?
I didn't know there were any guarantees now for historical data, but correct me if I am wrong. BUt tz is the primary source for historical timezones, and I believe it therefore should be expanded wherever possible, and as accurately as possible - wherever and whenever possible. I also believe there should be at least one zone per country, with its historical data back as far as possible.

A philosophical note: maintaining and processing information about the oddball stuff that's been done in the past helps ensure the ability to cope if the same sort of oddball stuff is done in the future. @dashdashado On Fri, May 28, 2021, 9:07 PM David Patte via tz <tz@iana.org> wrote:
History going back how far?
And to what extent should we offer a guarantee of historical accuracy?
I didn't know there were any guarantees now for historical data, but correct me if I am wrong.
BUt tz is the primary source for historical timezones, and I believe it therefore should be expanded wherever possible, and as accurately as possible - wherever and whenever possible. I also believe there should be at least one zone per country, with its historical data back as far as possible.

On 5/28/21 6:16 PM, Arthur David Olson via tz wrote:
A philosophical note: maintaining and processing information about the oddball stuff that's been done in the past helps ensure the ability to cope if the same sort of oddball stuff is done in the future.
Yes, that's long been a stated goal of tzdb - you added a note to that effect to the README file in (let me check the repository...) 1986! Paul Ganssle followed up today with a similar comment. I think every tzdb feature used by 'backzone' also occurs in the other files, so backzone's practical contribution to exercising zic etc. is limited. That being said, we can be more systematic about using 'backzone' that way. Proposed patch attached, and installed in the development repository. If someone wants to contribute further improvements of automated testing of 'backzone' that would be nice. Realistically, though, 'backzone' will continue to be lower-quality than the other files, as we lack the human time to check and/or improve it despite its known problems. By the way, one problem I have with "make check_public" is its large amount of not-that-useful 'zic -v' chatter like 'warning: "europe", line 3679: rule goes past start/end of month; will not work with pre-2004 versions of zic (rule from "europe", line 3660)' which causes me (and I assume everyone else) to ignore the chatter. Perhaps we should add an option to zic controlling diagnostic age - pre-2004 is pretty old nowadays - and change the default for zic -v to not warn about stuff that's been in zic for five years or so. After all, there's no point having tests if people always ignore test results. On 6/1/21 11:42 AM, Paul Ganssle via tz wrote:
The conversation instead goes, "Here's the rule we're using" and the follow up is, "That's a stupid rule, you should change it." then a bunch of people pile on in both sides and no time is saved.
Yes, we've had our share of pile-ons. There is a distinction, though, between tz mailing-list politics (the focus of much of the recent discussion) and real-world politics (things like, "is Kosovo a country?"). My main worry is the latter not the former, in that I think it's worth making minor technical changes to tzdb now to help forestall potentially major real-world political problems down the road, problems that could be worse than being sued by astrologers. Admittedly not everyone sees things this way.

I support this. Oddball stuff can be considered valuable cultural heritage, and should not be sacrificed on the altar of short-sighted technocratic efficiency. On 29.05.21 03:16, Arthur David Olson via tz wrote:
A philosophical note: maintaining and processing information about the oddball stuff that's been done in the past helps ensure the ability to cope if the same sort of oddball stuff is done in the future.

On 5/28/21 1:44 PM, Stephen Colebourne via tz wrote:
For example, Norway's and Sweden's time zone history is being wiped out in favour of that of Germany. Can no-one here see the political sensitivity in that?
In hindsight it was a political decision to create entries for Norway and Sweden and thus elevate them above other regions that lack entries. So, yes, I can see political sensitivity in removing that elevation. Here's another way to put it. Why should we maintain Norway and Sweden's time zone histories, when we don't maintain the histories for Guangdong, KwaZulu-Natal, Thanh Hóa, or Uttar Pradesh? Aside from politics, these regions are similar: although all the regions have distinct timestamp histories with data that I can cite, all the regions can be merged into other tzdb regions (Norway into Berlin, Guangdong into Shanghai, etc.) if we consistently limit tzdb's scope to regions that differ after 1970. Given all that, why should Norway and Sweden continue to be special? These are not particularly-obscure examples, as Guangdong etc. all have more people than Norway or Sweden do. It would be political to continue to focus on Norway and Sweden while excluding Guangdong etc. purely for reasons unrelated to timekeeping.
This code: DateTimeZone zone = DateTimeZone.forID("Europe/Stockholm"); System.out.println(zone); will print "Europe/Berlin" if this change is not reverted. I consider this to be catastrophic.
Even in 2021a, Joda-Time already does that sort of thing for Asia/Istanbul, Asia/Kuwait, Europe/Bratislava, Europe/Vatican, etc. Whatever techniques people use for these longstanding links should also work for the new links.

In hindsight it was a political decision to create entries for Norway and Sweden and thus elevate them above other regions that lack entries. So, yes, I can see political sensitivity in removing that elevation.
One principle of conservatism and stability is, "What has been done should not be un-done." I think we have lost sight of that (or failed to value it sufficiently highly) a bit too often of late. -- jhawk@alum.mit.edu John Hawkinson

On 2021-05-28 20:02, Paul Eggert via tz wrote:
Given all that, why should Norway and Sweden continue to be special?
It may not be relevant to an American, but there are not two worlds, the USA, and the rest. Its notoriously arrogant to expect Swedes to use a timezone named Germany. I'm certainly on record already for being forced to use America/Toronto. I am not in Toronto, and America is the name of two continents, and also the nickname of the USA. I am not in the country called America, and America meaning two continents is ludicrous. Canada/Toronto is at least not 100% insulting, or North_America/Toronto either. How many USA cities are forced to use Mexico timezones?

On Sat, 29 May 2021 at 01:02, Paul Eggert via tz <tz@iana.org> wrote:
On 5/28/21 1:44 PM, Stephen Colebourne via tz wrote:
For example, Norway's and Sweden's time zone history is being wiped out in favour of that of Germany. Can no-one here see the political sensitivity in that?
In hindsight
In hindsight, it was a mistake for Joda-Time to accept null values in the API. But I don't go around breaking millions of people's code because my views on the topic have changed. Backwards compatibility matters.
it was a political decision to create entries for Norway and Sweden and thus elevate them above other regions that lack entries. So, yes, I can see political sensitivity in removing that elevation.
Nonsense. Regions have names. That makes them political. Norway and Sweden are *countries*, not regions. If I were to call up the Norwegian or Swedish ambassador on Monday and tell them you were wiping their country off the time zone map and replacing them with Germany, I suspect there might be a diplomatic incident by Friday.
Here's another way to put it. Why should we maintain Norway and Sweden's time zone histories, when we don't maintain the histories for Guangdong, KwaZulu-Natal, Thanh Hóa, or Uttar Pradesh?
Because they are regions of the same country! (today and in the recent past)
Aside from politics, these regions are similar: although all the regions have distinct timestamp histories with data that I can cite, all the regions can be merged into other tzdb regions (Norway into Berlin, Guangdong into Shanghai, etc.) if we consistently limit tzdb's scope to regions that differ after 1970. Given all that, why should Norway and Sweden continue to be special?
These are not particularly-obscure examples, as Guangdong etc. all have more people than Norway or Sweden do. It would be political to continue to focus on Norway and Sweden while excluding Guangdong etc. purely for reasons unrelated to timekeeping.
Time zone regions in tzdb don't exist for your convenience, they exist for downstream users who have certain expectations of the database. And those expectations are shaped by many years experience of tzdb and the world in general. Timekeeping is by its very nature a product of Governmental decision making. This means that Governmental authorities, whether recognized countries or not, are a natural part of the problem space. Guangdong et al are not modern countries. No Governmental authority has made a time zone decision in those areas for many years. I don't see anyone objecting to a lack of historic time zone data within a single modern country. But merging zones across modern countries isn't acceptable. Stephen

On 29 May 2021 10:00:54 BST, Stephen Colebourne via tz <tz@iana.org> wrote:
I don't see anyone objecting to a lack of historic time zone data within a single modern country. But merging zones across modern countries isn't acceptable.
As maintainer of the PHP (and Hack, and MongoDB) implementations and data packages, I can assure you that I'm 100% in agreement with everything Stephen is saying. Messing with the data by deleting large parts of it without any other benefit is a terrible idea. I'm annoyed to have to say that this recurring "cleaning up" has been happening since Paul has taken over the maintainership here. I very much preferred ado's stance of maintenence of current rules, and leaving the old data alone. As Stephen says, backwards compatibility matters. cheers, Derick

I've been following this debate for a while now. There is no real harm in leaving LMT and historical time zone entries in place. Removing them is nothing more than an aesthetic decision, but one that will break thousands of applications, confuse users, and cause a public-relations nightmare for our merry band of volunteers. While I completely understand the theoretical basis for merging pre-1970 time zones, and I completely understand the recurring admonishments from some contributors to the list that software should never expose the Country/City identifiers to users, I disagree with both points. That's not how user-facing software works. A bedrock principle of usability is that end users will take the easiest path to using software, and if it doesn't work as expected, they get mad. There's a reason software engineers get dinged frequently for not taking "human factors" into account, mainly because we frequently forget that humans use our software. The Country/City identifiers make perfect sense to users and thus to software engineers of average laziness: I mean, why spend time (and money) writing a mapping layer on top of a perfectly understandable UI element? And why do we think users won't want to get accurate wall-clock time for times before Unix 0? Astronomy (and astrology) and historical research are just two (three) disciplines that need historical wall-clock time. As for politics, Kyiv/Kiev is a triviality compared with the Oslo/Berlin thing. Despite technology purists' disdain for software engineers directly exposing Norway/Oslo to their end users as a time zone option, thousands of applications do just that. Technology purists can also tut-tut all the Norwegian end users who haven't taken the time to read the TZDB Theory file and, as a consequence, don't grasp the solid technical reasons for making Berlin their time zone "capital." But the fact is, Norway has some experience with their government being run from Berlin in living memory, and it's not a happy time in 20th century history. Before you accuse me of a Godwin's Law violation, I assure you this is a real historical fact—i.e., a "human factor"—that will cause real blowback. The arguments for doing nothing are a lot stronger than the arguments for cleaning up the historical entries. Just leave them alone. If messiness offends one's technical sensibilities, I suggest that software design for people might not be the right career choice. David Braverman https://www.nuget.org/packages/InnerDrive.TimeZones/

On 5/29/21 7:18 AM, David Braverman via tz wrote:
And why do we think users won't want to get accurate wall-clock time for times before Unix 0? Astronomy (and astrology) and historical research are just two (three) disciplines that need historical wall-clock time.
These users will continue to get sort-of-accurate time, which is all they're getting now. No serious astronomer etc. should expect accurate German wall-clock time from TZ='Europe/Berlin' for pre-1970 timestamps, and the same is true for Sweden, Kosovo, etc.
Removing them is nothing more than an aesthetic decision, but one that will break thousands of applications, confuse users, and cause a public-relations nightmare for our merry band of volunteers. We've been moving out-of-scope historical data to 'backzone' for years. It's worked just fine.

On 5/29/21 2:00 AM, Stephen Colebourne via tz wrote:
Why should we maintain Norway and Sweden's time zone histories, when we don't maintain the histories for Guangdong, KwaZulu-Natal, Thanh Hóa, or Uttar Pradesh?
Because they are regions of the same country!
Thanh Hóa is not in the same country as Bangkok (Asia/Bangkok's most-populous location).
merging zones across modern countries isn't acceptable.
The practice is clearly acceptable, as tzdb's zones have crossed national boundaries for decades in some cases (as I mentioned in an earlier email). Unfortunately we haven't been consistent about this, and our lack of consistency has led to understandable charges of political favoritism. If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have. There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this. In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future.

I disagree. If tz followed international standards for countries (ISO I assume), then you would totally decouple tz from these issues, since they could be issues in those standards instead. That is, in fact, the whole purpose of international standards. To reduce disagreements. On 2021-05-29 14:43, Paul Eggert via tz wrote:
On 5/29/21 2:00 AM, Stephen Colebourne via tz wrote:
Why should we maintain Norway and Sweden's time zone histories, when we don't maintain the histories for Guangdong, KwaZulu-Natal, Thanh Hóa, or Uttar Pradesh?
Because they are regions of the same country!
Thanh Hóa is not in the same country as Bangkok (Asia/Bangkok's most-populous location).
merging zones across modern countries isn't acceptable.
The practice is clearly acceptable, as tzdb's zones have crossed national boundaries for decades in some cases (as I mentioned in an earlier email). Unfortunately we haven't been consistent about this, and our lack of consistency has led to understandable charges of political favoritism.
If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have. There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this.
In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future.

Kosovo is not listed as an ISO-3166 country. Palestine is. This is what the ISO which includes all the world timezones has decided for now. If people have issues with that, they should have to contact the ISO, not tz. On 2021-05-29 14:43, Paul Eggert via tz wrote:
On 5/29/21 2:00 AM, Stephen Colebourne via tz wrote:
Why should we maintain Norway and Sweden's time zone histories, when we don't maintain the histories for Guangdong, KwaZulu-Natal, Thanh Hóa, or Uttar Pradesh?
Because they are regions of the same country!
Thanh Hóa is not in the same country as Bangkok (Asia/Bangkok's most-populous location).
merging zones across modern countries isn't acceptable.
The practice is clearly acceptable, as tzdb's zones have crossed national boundaries for decades in some cases (as I mentioned in an earlier email). Unfortunately we haven't been consistent about this, and our lack of consistency has led to understandable charges of political favoritism.
If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have. There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this.
In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future.

Paul Eggert <eggert@cs.ucla.edu> wrote on Sat, 29 May 2021 at 14:43:31 EDT in <ba58913a-d230-ceed-3e57-2f3db21438d7@cs.ucla.edu>:
merging zones across modern countries isn't acceptable.
The practice is clearly acceptable, as tzdb's zones have crossed national boundaries for decades in some cases (as I mentioned in an earlier email).
Paul: Words matter, details matter, language matters, and precision matters. Your statement is not correct, because you have blurred two different concepts. There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades." Taking an action that leads to a state is different from allowing that state to persist. Thus, you may not fairly say that THE PRACTICE of MERGING is "clearly acceptable." (At least, not for the reason you offered.) (Also, I think many would quibble with the claim that because the tzdb has done a thing, whether over complaint of the peanut gallery or not, that that thing is necessarily "acceptable." And with "acceptable" in question, I'm not sure what "clearly acceptable" means either.)
If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have. There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this.
Although this seems to be an oft-uttered sentiment, I am not entirely sure it were true. If every political controversy results in a split pair of zones, I'm not sure that is so bad. If we had, say, Russia/Crimea and Ukraine/Crimea, the politics would be in which one to choose, but not in the maintenance of either. We would certainly have a database with *more entries*, i.e. a larger database, but I don't think it is fair to say that means "more[ ]complicated." Complexity is a deeper concept than just number of entries, and if we go from 600 zones to 900 zones or 1200 zones, I don't know that would have any meaningful effect on anything that matters. I doubt the load on the maintainers would be greater, or that a twofold increase would imply any changes to user interfaces, or anything like that.
In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future.
But what does decoupling mean? Instead of fighting these political forces and maintain a steadfast refusal to acknowledge them and making people unhappy, why not just accept all the options and let the users choose? Wouldn't that be equally "decoupled"? -- jhawk@alum.mit.edu John Hawkinson

On 2021-05-29 14:09, John Hawkinson via tz wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote on Sat, 29 May 2021 at 14:43:31 EDT in <ba58913a-d230-ceed-3e57-2f3db21438d7@cs.ucla.edu>:
merging zones across modern countries isn't acceptable.
The practice is clearly acceptable, as tzdb's zones have crossed national boundaries for decades in some cases (as I mentioned in an earlier email).
Paul: Words matter, details matter, language matters, and precision matters. Your statement is not correct, because you have blurred two different concepts.
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
Taking an action that leads to a state is different from allowing that state to persist.
Thus, you may not fairly say that THE PRACTICE of MERGING is "clearly acceptable." (At least, not for the reason you offered.)
(Also, I think many would quibble with the claim that because the tzdb has done a thing, whether over complaint of the peanut gallery or not, that that thing is necessarily "acceptable." And with "acceptable" in question, I'm not sure what "clearly acceptable" means either.)
If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have. There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this.
Although this seems to be an oft-uttered sentiment, I am not entirely sure it were true.
If every political controversy results in a split pair of zones, I'm not sure that is so bad. If we had, say, Russia/Crimea and Ukraine/Crimea, the politics would be in which one to choose, but not in the maintenance of either.
More likely according to which is the largest municipality in each country's possession, and maybe something similar for E/Jerusalem.
We would certainly have a database with *more entries*, i.e. a larger database, but I don't think it is fair to say that means "more complicated." Complexity is a deeper concept than just number of entries, and if we go from 600 zones to 900 zones or 1200 zones, I don't know that would have any meaningful effect on anything that matters. I doubt the load on the maintainers would be greater, or that a twofold increase would imply any changes to user interfaces, or anything like that.
In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future.
Given that the tzdb whole reason for being is the problems caused by political entities, the focus should always be on dealing pragmatically with all the political problems those cause, not following a course because it may be technically more pure, and not dropping all historical information because it may be worse, without good reasons. Some(/many?/most?) downstreams maintain their own copies of older code and data and cherry pick updates to maintain maximal backward compatibility to avoid breaking their customers production systems, generating bug reports, that costs them effort, time, and money to deal with. Organizations don't care what's right, only what's unnecessarily different: IBM, MS, Oracle, RedHat, and others have downstream products whose maintained lifecycles are decades, and they like to keep customers decades old applications running the same next month as last.
But what does decoupling mean? Instead of fighting these political forces and maintain a steadfast refusal to acknowledge them and making people unhappy, why not just accept all the options and let the users choose? Wouldn't that be equally "decoupled"? If we keep the rules for regions common, but have similar zones for different political entities at similar longitudes, we can maintain a balance, and still reduce effort.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

On 5/29/21 3:14 PM, Brian Inglis via tz wrote:
Some(/many?/most?) downstreams maintain their own copies of older code and data and cherry pick updates to maintain maximal backward compatibility to avoid breaking their customers production systems, generating bug reports, that costs them effort, time, and money to deal with.
Yes, when we removed the SystemV/* names a couple of decades ago, some suppliers kept them around for awhile for compatibility reasons. I doubt whether that'd be useful for the current change, though, as it's a smaller change from the user viewpoint.
If we keep the rules for regions common, but have similar zones for different political entities at similar longitudes, we can maintain a balance, and still reduce effort.
I'm not so much worried by the technical effort of maintaining Sweden data separately now, as by the political effort of justifying why we treat Sweden differently from Kosovo or any number of similar candidates in the future. Saying "we've always done it that way" is not sufficient justification for a political decision.

On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users. The current patch was not prompted by purism. It was prompted by a complaint from a user who made a good point about the politics of tzdb 2021a, which can reasonably be interpreted to favor countries like Norway etc. over countries like Kosovo etc. Rejecting this kind of complaint and saying "we've always done it that way" is not a promising path forward. tzdb has had zones crossing international borders for decades, and it's been fine. We moved politically-motivated links to 'backward' starting eight years ago, and that worked fine. We moved politically-motivated zones to 'backzone' starting seven years ago and tzdb has rolled along just fine since then too. This is one patch in a long line, and as far as I can see it'll work out fine too.

On 30 May 2021 00:29:28 BST, Paul Eggert via tz <tz@iana.org> wrote:
On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users.
Referencing https://datatracker.ietf.org/doc/html/rfc6557 Dear Paul, you've had a lot of push back to this change, as per the "Procedures for Maintaining the Time Zone Database" the TZ Coordinator "SHOULD take into account views expressed on the mailing list." I would very much appreciate it if you'd at least listen to the feedback you've gotten on this change, and I'd argue that from what I've read, that this list is not OK with this proposed change. cheers, Derick

On 5/29/21 4:45 PM, Derick Rethans wrote:
I would very much appreciate it if you'd at least listen to the feedback you've gotten on this change,
I've been doing that, have responded to each point made as best I can, and have significantly scaled back the original proposal. There are competing objectives here, and unfortunately there is no way to make everybody happy. (I hope we can make a few people less unhappy. :-)

On 2021-05-30 07:45:45 (+0800), Derick Rethans via tz wrote:
On 30 May 2021 00:29:28 BST, Paul Eggert via tz <tz@iana.org> wrote:
On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users.
Referencing https://datatracker.ietf.org/doc/html/rfc6557
Dear Paul, you've had a lot of push back to this change, as per the "Procedures for Maintaining the Time Zone Database" the TZ Coordinator "SHOULD take into account views expressed on the mailing list."
I would very much appreciate it if you'd at least listen to the feedback you've gotten on this change, and I'd argue that from what I've read, that this list is not OK with this proposed change.
One of the things I like a lot about the tzdb project is the spirited discussions we have on this mailing list about proposed changes. Anyone who has been subscribed to the list for a while (or who spends some time reading the archives) will be aware that feedback is indeed taken into account. This specific change has evolved a lot since its initial proposal. It's also worth pointing out again to those unfamiliar with the way tzdb is usually distributed (e.g in operating systems distributions), that Paul's proposed change is largely invisible to most users. Most tzdb downstreams link in backzone. Data is merely being moved to a different place. It's not actually being removed. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

On Sun, 30 May 2021 at 03:35, Philip Paeps via tz <tz@iana.org> wrote:
It's also worth pointing out again to those unfamiliar with the way tzdb is usually distributed (e.g in operating systems distributions), that Paul's proposed change is largely invisible to most users. Most tzdb downstreams link in backzone. Data is merely being moved to a different place. It's not actually being removed.
Two incorrect things here. 1) tzdb is used in many, many more places than just operating systems. There are downstream consumers of the data for all major programming languages. Java 8 onwards also exposes all the source data (transitions and future rules) via a full public API. With Joda-Time, Europe/Oslo will be physically replaced by Europe/Berlin if this change proceeds. This narrow idea that tzdb exists to serve Linux-type operating systems is at the heart of the problem here - it's simply not true. 2) All major Java installations of tzdb (and probably others) do *not* use the backzone file. And it would be hugely disruptive to try and get them to do so. Data *is* being removed directly from many downstream consumers. Stephen

I'm not entirely clear on the current status of the proposal. If most people are getting all the data from `backzone` anyway and the data is still being maintained in the repository, does this really alleviate the maintenance burden? Is the idea that the tzdb project will stop accepting patches to `backzone`, and thus these are frozen in amber? I suspect that if this is invisible to the end user, it will not keep people from reporting bugs or complaining about what they feel the key structure should be, and if anything it will increase bugs, because if they use a system that doesn't link in backzone, they'll be very confused about why previously valid keys are no longer valid. I'll note that I'm not against the proposal and I certainly don't think that it should be stopped because it would merge zones across country boundaries — I don't think there needs to be a notion of countries in the tzdb any more than there needs to be a notion of specific cities, I just want to know what we're supposed to be getting for the change. Personally, I agree with ado about maintaining the old funky pre-1970 zones (or at least keeping them present in the database as-is, indefinitely) for the purposes of stress-testing the capabilities of the tzdb. I make fairly extensive use of pre-1970 zones in my various TZif parsing libraries (e.g. Python's dateutil and zoneinfo) because that's where you get weird stuff like double daylight saving time, large swings in offset and fractional-minute offsets. At the end of the day, I think the main problem that this is addressing is that Paul wants to have some consistency in the rules so that he can point to the rule and say, "Here's the rule we're using, please tell us if there's a violation of /this rule/, otherwise we don't want to engage." But the problem is that we already have this for the most contentious stuff and it's not really enforced. The conversation instead goes, "Here's the rule we're using" and the follow up is, "That's a stupid rule, you should change it." then a bunch of people pile on in both sides and no time is saved. If that's going to happen anyway and every time anyone shows up and complains about the rules a dozen people are going to pile on saying, "We should change the zone names to non-human-readable alphanumeric keys" or "We should make one zone per country" /and it's not a violation of the rules of the list to do this/, I don't see the value in trying to break backwards compatibility in even small ways to be more consistent about these rules. Best, Paul On 5/29/21 10:34 PM, Philip Paeps via tz wrote:
On 2021-05-30 07:45:45 (+0800), Derick Rethans via tz wrote:
On 30 May 2021 00:29:28 BST, Paul Eggert via tz <tz@iana.org> wrote:
On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users.
Referencing https://datatracker.ietf.org/doc/html/rfc6557
Dear Paul, you've had a lot of push back to this change, as per the "Procedures for Maintaining the Time Zone Database" the TZ Coordinator "SHOULD take into account views expressed on the mailing list."
I would very much appreciate it if you'd at least listen to the feedback you've gotten on this change, and I'd argue that from what I've read, that this list is not OK with this proposed change.
One of the things I like a lot about the tzdb project is the spirited discussions we have on this mailing list about proposed changes.
Anyone who has been subscribed to the list for a while (or who spends some time reading the archives) will be aware that feedback is indeed taken into account.
This specific change has evolved a lot since its initial proposal.
It's also worth pointing out again to those unfamiliar with the way tzdb is usually distributed (e.g in operating systems distributions), that Paul's proposed change is largely invisible to most users. Most tzdb downstreams link in backzone. Data is merely being moved to a different place. It's not actually being removed.
Philip

I am sorry to be blunt and overbearing on this particular narrow point: Paul Eggert <eggert@cs.ucla.edu> wrote on Sat, 29 May 2021 at 19:29:28 EDT in <234d77ef-69c4-0c7c-322d-afb88dfed3ad@cs.ucla.edu>:
On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users.
One can quibble about the magnitude of the difference, but there is no serious argument that the two are the same. When you, Paul, make logical arguments that equate different issues like this, and use that logical argument to make strong claims and base decisions on those claims, it is a problem. We have to trust that logical arguments stand on their own, without subjective evaluation, and to distinguish the unimpeachable logical arguments made from the subjective ones. Here, you masqueraded a subjective argument as logical one, and that's why I thought it was worth calling it out, both in my original message as well as here in the reply. Yes, we're in the weeds. But again, yes: words matter, details matter, language matters, and precision matters. Your statement was not correct, because you had blurred two different concepts. And, of course, this is especially important for you, Paul, because as the maintainer, you need a certain degree of neutrality and more importantly credibility. And credibility is damaged by this style of argumentation. I am tempted to reply to both your other comments (still quoted below) as well as whether it is "a big difference to users" (unsupported, conclusory, and I suspect not in fact true) but I will save that for another message, integrated with further comments from others in this thread, if at all. I'm trying to keep this hyper-focused on the one issue, because I think it is an important one with a reasonable probability of recurring if it's not addressed. Thanks. -- jhawk@alum.mit.edu John Hawkinson
The current patch was not prompted by purism. It was prompted by a complaint from a user who made a good point about the politics of tzdb 2021a, which can reasonably be interpreted to favor countries like Norway etc. over countries like Kosovo etc. Rejecting this kind of complaint and saying "we've always done it that way" is not a promising path forward.
tzdb has had zones crossing international borders for decades, and it's been fine. We moved politically-motivated links to 'backward' starting eight years ago, and that worked fine. We moved politically-motivated zones to 'backzone' starting seven years ago and tzdb has rolled along just fine since then too. This is one patch in a long line, and as far as I can see it'll work out fine too.

On Sat, 29 May 2021 at 19:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/29/21 2:00 AM, Stephen Colebourne via tz wrote: If we insisted on creating a new zone every time there was a different country, we'd have a more-complicated database and get into even bigger political messes than we already have.
It is hugely "political" to say that Norway or Sweden are of no importance to tzdb.
There was an example of this recently in the complaint about why there is no separate tzdb entry for Kosovo. I endured quite a bit of vitriol in private email about this.
On Kosovo, the current status is: "As of 4 September 2020, 98 out of 193 (51%) United Nations (UN) member states, 22 out of 27 (81%) European Union (EU) member states, 26 out of 30 (87%) NATO member states, and 31 out of 57 (54%) Organisation of Islamic Cooperation (OIC) member states have recognised Kosovo." https://en.wikipedia.org/wiki/International_recognition_of_Kosovo I would argue that it is already sufficiently widely accepted as a state to be included in tzdb (under the proposed rule of at least one non-Link zone per country). It is *your* actions that are making tzdb more political than it needs to be.
In the long run we are better off decoupling tzdb entries from political issues as much as we can. This will lessen the probability of similar vitriol (or worse) in the future. No it won't. Nor should an easy life for you be a factor in the decision making process. Time zones are political things, defined by Governments. And yes, countries sometimes fight wars. This cannot be hidden or brushed under the carpet.
Please try to understand that tzdb is used for much more than just getting an offset for an arbitrary meaningless ID. Every part of the source data is used by downstream systems. Every aspect of it has meaning.
We've been moving out-of-scope historical data to 'backzone' for years. It's worked just fine. And you've had repeated pushback from the list on your ill-advised "cleanups". I, and others, just want you to stop messing around. This project isn't your plaything.
I do not believe you have the consensus of the TZDB list to continue with this patch. It should be reverted entirely. Stephen

On 5/29/21 5:24 PM, Stephen Colebourne via tz wrote:
It is hugely "political" to say that Norway or Sweden are of no importance to tzdb.
It would be "political" to say that, but nobody is saying that. Norway and Sweden are just as important to tzdb as Angola, Slovakia, etc. Those other countries don't have distinct Zones, and there's no justification (other than inertia) for treating Norway and Sweden differently.
countries sometimes fight wars. This cannot be hidden or brushed under the carpet.
The guidelines say that tzdb doesn't attempt to track boundary changes due to wars in any detailed way. It would be impractical for tzdb to do otherwise, given its current organization. I haven't seen any realistic proposal to change this.
And you've had repeated pushback from the list on your ill-advised "cleanups".
And despite repeated predictions of serious problems, cleanups to remove unnecessarily political data have worked out well. To the extent that they've forestalled political disputes they've been a net plus for the project. (Of course it is hard to show a negative.)

Why should tz take on all the political fights itself and have to fight over Tibet, Gaza, Kosovo, Hong Kong? Its a waste of time. Are you really a better judge of world standards, sensitivities and world diplomacy than the ISO? Of course not. Punt this to the organization that is charged with this issue. Let people aregue with them. They are not perfect, but it is their job. Why force everyone downstream to have to make all those political decisions again when 98% will end up using ISO anyway? (1) To make tz far more useful to far more users, there should be a separate zone for each ISO country and at least the largest city in that country, ie: Canada/Toronto. Then every defined zone should have historical data as far back as possible. Splitting starting at some particular date (1970) is a good way of limiting the db size and relative accuracy. It then satisfies the need of far more people, more easily, without having to be processed downstream. Or (2) remove all politics, and country names, and go to only code-numbered zones, with the local name of the largest city in that zone, and let your downstream users add their politics themselves - most of which will split them into countries as was suggested in (1), most using standrized politics anyway by starting with ISO. It will make tz simpler, smaller, and less useful - but at least all the arguments here will be gone as well. But the way it is right now, even before this current suggestion, tz is half useful to many users, and tainted with its own political insensitivities. Remove all those sensitivities, or use a standard, making the DB more useful. On 2021-05-29 20:59, Paul Eggert via tz wrote:
I haven't seen any realistic proposal to change this.

On Sun, 30 May 2021 at 01:59, Paul Eggert via tz <tz@iana.org> wrote:
On 5/29/21 5:24 PM, Stephen Colebourne via tz wrote:
It is hugely "political" to say that Norway or Sweden are of no importance to tzdb.
It would be "political" to say that, but nobody is saying that. Norway and Sweden are just as important to tzdb as Angola, Slovakia, etc. Those other countries don't have distinct Zones, and there's no justification (other than inertia) for treating Norway and Sweden differently.
The politics is entirely of your own making. Each of these *countries* should have a full non-Link zone. It is entirely wrong that they do not.
The guidelines say that tzdb doesn't attempt to track boundary changes due to wars in any detailed way. It would be impractical for tzdb to do otherwise, given its current organization. I haven't seen any realistic proposal to change this.
No one is asking for tadb to track *borders* or boundary changes. I, and others, expect tzdb to track the impact that Governmental authorities (eg. countries) have on the time-zone of a location with a consistent reliable ID and data at a minimum per-country.
And you've had repeated pushback from the list on your ill-advised "cleanups".
And despite repeated predictions of serious problems, cleanups to remove unnecessarily political data have worked out well. To the extent that they've forestalled political disputes they've been a net plus for the project. (Of course it is hard to show a negative.)
Let me be clear - this change cannot stand. The reliability of TZDB has declined considerably over the past few years, but it is time to say enough is enough. This is where the line in the sand needs to be drawn. Stephen

On Fri, 28 May 2021, Paul Eggert via tz wrote:
On 5/28/21 1:44 PM, Stephen Colebourne via tz wrote:
For example, Norway's and Sweden's time zone history is being wiped out in favour of that of Germany. Can no-one here see the political sensitivity in that?
Given all that, why should Norway and Sweden continue to be special?
I'll turn this around, why do you think Germany (and it's tz history) is more important than Norway or Sweden? Norway and Sweden were countries before Germany. cheers, Derick

There is clearly a conflict of interest here: 1) On one hand, several people would like to simplify the main data table, reducing the number of individual zone records by merging them where they are the same since 1970. The advantage here is that its more concise, easier to maintain, and pretty much all political content could be removed (if country names are removed). I can understand the reasoning. In fact, for many in this group there would be no reason to even maintain any historical tz data in this table, as most downstream users of such a table are only interested in the current zones and their current and upcoming offsets. 2) On the other hand, several people would like to have tz be a source, maintain and collect more historical tz data and organize it by international standards so the historical data can be expanded per country. The key here would be to make the database more accessible to more users and complete for more than just the current zones. As far as I know there is no such database, and as tz moves closer and closer to (1), many users are losing this tz data that was once being collected in tz table per country. I, just one of many, don't want to lose the historical information for Toronto, or Stockholm. I would like it to remain part of the mandate of tz somehow. So, I have a question. And I'm not trying to difficult. Assuming that the goal of (1) is achieved, what can be done to not undermine type 2 users? If we have (1), but also want to maintain and expand historical data per country's zones, how could that be done? using a secondary table? Could the back table be improved, expanded and enhanced?

On 5/30/21 8:10 AM, David Patte via tz wrote:
1) On one hand, several people would like to simplify the main data table, reducing the number of individual zone records by merging them where they are the same since 1970....
2) On the other hand, several people would like to have tz be a source, maintain and collect more historical tz data and organize it by international standards so the historical data can be expanded per country....
So, I have a question. And I'm not trying to difficult.
Assuming that the goal of (1) is achieved, what can be done to not undermine type 2 users? If we have (1), but also want to maintain and expand historical data per country's zones, how could that be done? using a secondary table? Could the back table be improved, expanded and enhanced?
These are good questions. We have the 'backzone' file for type (2) data, but the 'backzone' approach is apparently unsatisfactory for some users of type (2) data. Part of the problem may be that 'backzone' is a mishmash quality-wise. Today there are only two simple options in the Makefile - use either all of 'backzone' or none of it - and there are real problems with using all of it. Perhaps we could add something that would give users more flexibility. For example, if a downstream user wants the 'backzone' entry for Europe/Stockholm which is well-documented, but doesn't want backzone's America/Montreal entry because it's not well-attested and is most likely wrong, the user could specify a list of backzone names that includes Europe/Stockholm but excludes America/Montreal. I think it would not be too much work to add something like this to the tzdb code. This would better support users who want a separate Zone for each country in 'backzone', but do not want all of 'backzone'.

But is the backzone data 'frozen'? Is it acceptable to propose corrections to the backzone data when more accurate historical data for a city becomes available? Also Is it possible to add new backzones, even if they may refer to an already existing primary zone? And could the backzones be organized in a way that is more user friendly to its primary users (ahem: always by current ISO country?) I think its clear that historical data is less accurate the further back we go. But for people that are using tz for historical localized timezone information, they already understand that. Historical data is always assumed to be murky, yet hopefully historical data quality improvements in tz are still accepted. I have no problem with merging all the zones in the primary database as suggested for (1), depending how much flexibility tz will accept in backzone enhancement. To me, the two tables provide very different needs to two very different sets of users. Let the O/S teams use table 1, let the history-related app developers use a constantly improving backtable. On 2021-06-01 19:48, Paul Eggert wrote:
On 5/30/21 8:10 AM, David Patte via tz wrote:
1) On one hand, several people would like to simplify the main data table, reducing the number of individual zone records by merging them where they are the same since 1970....
2) On the other hand, several people would like to have tz be a source, maintain and collect more historical tz data and organize it by international standards so the historical data can be expanded per country....
So, I have a question. And I'm not trying to difficult.
Assuming that the goal of (1) is achieved, what can be done to not undermine type 2 users? If we have (1), but also want to maintain and expand historical data per country's zones, how could that be done? using a secondary table? Could the back table be improved, expanded and enhanced?
These are good questions. We have the 'backzone' file for type (2) data, but the 'backzone' approach is apparently unsatisfactory for some users of type (2) data.
Part of the problem may be that 'backzone' is a mishmash quality-wise. Today there are only two simple options in the Makefile - use either all of 'backzone' or none of it - and there are real problems with using all of it. Perhaps we could add something that would give users more flexibility.
For example, if a downstream user wants the 'backzone' entry for Europe/Stockholm which is well-documented, but doesn't want backzone's America/Montreal entry because it's not well-attested and is most likely wrong, the user could specify a list of backzone names that includes Europe/Stockholm but excludes America/Montreal. I think it would not be too much work to add something like this to the tzdb code. This would better support users who want a separate Zone for each country in 'backzone', but do not want all of 'backzone'.

On 6/1/21 5:44 PM, David Patte wrote:
is the backzone data 'frozen'?
Not at all. The file is not a hotbed of activity (averaging 9 changes per year since 2014) but fixes are welcome. As befitting backzone's status, patches are not reviewed as carefully as other files' patches. As usual with fixes, please use 'git format-patch' to generate patches, and attach them to your email or send them via 'git send-email'. And it's helpful to test your patches with 'make check' or 'make public' before sending them out.

I should add that as an app developer, i do not use zic at all, so I have no need for enhancements to zic. I write both astronomy and family history apps, and I write my own parsers to extract the data I want from tz tables on the fly. I believe many using the historical data portion of tz would likely do the same thing. Type (2) people simply want to continuously improve the accessibility, locality and accuracy of historical tz data, for apps that want PAST tzdata, not future tz data. On 2021-06-01 19:48, Paul Eggert wrote:
On 5/30/21 8:10 AM, David Patte via tz wrote:
1) On one hand, several people would like to simplify the main data table, reducing the number of individual zone records by merging them where they are the same since 1970....
2) On the other hand, several people would like to have tz be a source, maintain and collect more historical tz data and organize it by international standards so the historical data can be expanded per country....
So, I have a question. And I'm not trying to difficult.
Assuming that the goal of (1) is achieved, what can be done to not undermine type 2 users? If we have (1), but also want to maintain and expand historical data per country's zones, how could that be done? using a secondary table? Could the back table be improved, expanded and enhanced?
These are good questions. We have the 'backzone' file for type (2) data, but the 'backzone' approach is apparently unsatisfactory for some users of type (2) data.
Part of the problem may be that 'backzone' is a mishmash quality-wise. Today there are only two simple options in the Makefile - use either all of 'backzone' or none of it - and there are real problems with using all of it. Perhaps we could add something that would give users more flexibility.
For example, if a downstream user wants the 'backzone' entry for Europe/Stockholm which is well-documented, but doesn't want backzone's America/Montreal entry because it's not well-attested and is most likely wrong, the user could specify a list of backzone names that includes Europe/Stockholm but excludes America/Montreal. I think it would not be too much work to add something like this to the tzdb code. This would better support users who want a separate Zone for each country in 'backzone', but do not want all of 'backzone'.

On Jun 1, 2021, at 5:57 PM, David Patte via tz <tz@iana.org> wrote:
I write both astronomy and family history apps, and I write my own parsers to extract the data I want from tz tables on the fly. I believe many using the historical data portion of tz would likely do the same thing. Type (2) people simply want to continuously improve the accessibility, locality and accuracy of historical tz data, for apps that want PAST tzdata, not future tz data.
It's not a difference between wanting past data vs. wanting future data. OSes definitely use past tz data: $ ls -lT /usr/local/bin/yacc -rwxr-xr-x 1 root wheel 123916 May 6 14:18:05 2018 /usr/local/bin/yacc The difference is how far back in time is useful, not whether the past is useful at all. For OS purposes, times before the OS's time stamp epoch are probably of less interest than times at or after the epoch, and for many OSes, even times after the epoch but before the first release of the first OS to use any file system supported by the OS are of less interest. The UNIX epoch is probably a good dividing line between the two groups.

Okay. Thanks for the clarity. And app developers also want more locations that have differences before 1970. 'Further-back data', which implies zones which are not relevant to o/s work. But the further you go back the more zones this implies, until we are all back to local solar time. So assuming we could add those somewhere, with so many potential zones how would one identify them... which is where I propose current ISO country/city ids for the backfiles, as a way of making them more accessible and also as a way of deferring political debate off this list and to ISO instead. I now have no problem with the effort to merge zones in the main table, and app developers with historical needs would focus more on using and improving the back files, potentially adding new pre-1970 zones only to the backfiles at some point. These extra zones could be ignored by zic, but I don't use zic, so I cannot really comment on that. On 2021-06-01 22:42, Guy Harris wrote:
OSes definitely use past tz data:

On 2021-06-01 20:42, Guy Harris via tz wrote:
On Jun 1, 2021, at 5:57 PM, David Patte via tz <tz@iana.org> wrote:
I write both astronomy and family history apps, and I write my own parsers to extract the data I want from tz tables on the fly. I believe many using the historical data portion of tz would likely do the same thing. Type (2) people simply want to continuously improve the accessibility, locality and accuracy of historical tz data, for apps that want PAST tzdata, not future tz data. It's not a difference between wanting past data vs. wanting future data. OSes definitely use past tz data: $ ls -lT /usr/local/bin/yacc -rwxr-xr-x 1 root wheel 123916 May 6 14:18:05 2018 /usr/local/bin/yacc The difference is how far back in time is useful, not whether the past is useful at all. For OS purposes, times before the OS's time stamp epoch are probably of less interest than times at or after the epoch, and for many OSes, even times after the epoch but before the first release of the first OS to use any file system supported by the OS are of less interest. The UNIX epoch is probably a good dividing line between the two groups.
It can be useful to tag (touch) (scans of) historical or official documents, pictures, media with real timestamps corresponding to the date issued, taken, or expired, as well as location, and time zone info. The current range covered by GNU date: @-67768040609740800 -2147481748 Jan 01 Mon 00:00:00 @67767976233532799 2147483647 Dec 31 Tue 23:59:59 is stupendously more than historical, supported on BtrFS, BSD UFS2; the MS Windows NTFS date range from 1601-01-01 (to 60056-05-28) is more useful than the Linux ext2-4 range from 1901-12-13 (to ext4 2446-05-10), and Apple FS from 1970-01-01. J/MPEG EXIF/IPTC/XMP metadata (exiftool) uses ISO-8601 strings, allowing for uncertain values specified as 00 or spaces <https://exiftool.org/forum/index.php?topic=5007.0;all> but not all file content formats support user specified metadata. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

Brian Inglis via tz <tz@iana.org> wrote on Wed, 2 Jun 2021 at 13:10:34 EDT in <974cf8e1-c2d8-36bf-ec10-8e99ec826956@SystematicSw.ab.ca>:
It can be useful to tag (touch) (scans of) historical or official documents, pictures, media with real timestamps corresponding to the date issued, taken, or expired, as well as location, and time zone info. The current range covered by GNU date:
@-67768040609740800 -2147481748 Jan 01 Mon 00:00:00 @67767976233532799 2147483647 Dec 31 Tue 23:59:59
That range isn't part of GNU date, I don't think. Under OS X, I get a different result. For the negative bound: pb3:xj2 jhawk$ gdate --version date (GNU coreutils) 8.30 ... pb3:xj2 jhawk$ gdate -d @-67768040609722801 gdate: time ‘-67768040609722801’ is out of range pb3:xj2 jhawk$ gdate -d @-67768040609722800 Thu Jan 1 00:00:00 EST -2147481748 pb3:xj2 jhawk$ Not that this matters critically. -- jhawk@alum.mit.edu John Hawkinson +1 617 797 0250

On 2021-06-02 17:24, John Hawkinson via tz wrote:
Brian Inglis via tz <tz@iana.org> wrote on Wed, 2 Jun 2021 at 13:10:34 EDT in <974cf8e1-c2d8-36bf-ec10-8e99ec826956@SystematicSw.ab.ca>:
@-67768040609740800 -2147481748 Jan 01 Mon 00:00:00 @67767976233532799 2147483647 Dec 31 Tue 23:59:59 That range isn't part of GNU date, I don't think. Under OS X, I get a different result. For the negative bound:
pb3:xj2 jhawk$ gdate --version date (GNU coreutils) 8.30 ... pb3:xj2 jhawk$ gdate -d @-67768040609722801 gdate: time ‘-67768040609722801’ is out of range pb3:xj2 jhawk$ gdate -d @-67768040609722800 Thu Jan 1 00:00:00 EST -2147481748 pb3:xj2 jhawk$
The value you have given, 1970-01-01 - 67 768 040 609 722 800 seconds, is the smallest value of UT for which the EST value U - 05 h is representable in struct tm. Brian Inglis has given the smallest and largest datetimes representable in a struct tm; this shifts the range by 5 hours. What I find surprising is that the days of the week as given by Brian are incorrect: the Gregorian dates -2147 481 748-01-01 +2147 485 548-01-01 are both Thursdays. Michael Deckers.

On 6/2/21 1:34 PM, Michael H Deckers via tz wrote:
What I find surprising is that the days of the week as given by Brian are incorrect: the Gregorian dates -2147 481 748-01-01 +2147 485 548-01-01 are both Thursdays.
The incorrect output in Brian's email was likely due to a longstanding signed integer overflow bug in tzcode, which I fixed on March 23: https://mm.icann.org/pipermail/tz/2021-March/029968.html https://github.com/eggert/tz/commit/b73daeca66d395f6815466767139ae8b02cafde3 Because of the bug, tzcode 'date -r' gave the wrong output for extreme dates, such as the dates Brian used. This fix should appear in the next tzdb release. Perhaps it's time for a new release, as that bug has bothered me too.

On 2021-06-02 16:06, Paul Eggert via tz wrote:
On 6/2/21 1:34 PM, Michael H Deckers via tz wrote:
On 2021-06-02 16:04, John Hawkinson wrote:
Oh dear. My comment to Brian was not intended for the list, sorry! And doh! Yes, UTC of course.
Sent to MHD and me - no worries - nothing we can say you can't post.
What I find surprising is that the days of the week as given by Brian are incorrect: the Gregorian dates -2147 481 748-01-01 +2147 485 548-01-01 are both Thursdays.
Shows what good decisions GNU and ISO made - both dates are ISO week 1. That output's UTC from a script that does a binary search across the 64 bit time_t space for the negative and positive limits which give a successful GNU date conversion, or set a file time using coreutils touch (and stat). Now I think of it, that script should allow for the lower limit to be zero (as on Apple FS) not just negative.
The incorrect output in Brian's email was likely due to a longstanding signed integer overflow bug in tzcode, which I fixed on March 23:
https://mm.icann.org/pipermail/tz/2021-March/029968.html https://github.com/eggert/tz/commit/b73daeca66d395f6815466767139ae8b02cafde3
Because of the bug, tzcode 'date -r' gave the wrong output for extreme dates, such as the dates Brian used.
This fix should appear in the next tzdb release. Perhaps it's time for a new release, as that bug has bothered me too.
I don't think that's a rush right now, as the values are so far out of any normally usable range, no one has yet complained, and most downstreams do not seem to directly use your code in libc. ;^< And as soon as you issue one release, something will come up so you have to immediately release the next. Kudos to those who thought of checking and noticed the bug! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

On Jun 2, 2021, at 10:10 AM, Brian Inglis via tz <tz@iana.org> wrote:
On 2021-06-01 20:42, Guy Harris via tz wrote:
For OS purposes, times before the OS's time stamp epoch are probably of less interest than times at or after the epoch, and for many OSes, even times after the epoch but before the first release of the first OS to use any file system supported by the OS are of less interest. The UNIX epoch is probably a good dividing line between the two groups.
It can be useful to tag (touch) (scans of) historical or official documents, pictures, media with real timestamps corresponding to the date issued,
Yes, but that doesn't mean that times before the OS's time stamp are necessarily of as much interest as times at or after the epoch. The number of files given retrospective creation or modification time stamps accessed by a given OS is probably a small fraction of all the files accessed by that OS.

On 2021-06-01 17:48, Paul Eggert via tz wrote:
These are good questions. We have the 'backzone' file for type (2) data, but the 'backzone' approach is apparently unsatisfactory for some users of type (2) data.
Part of the problem may be that 'backzone' is a mishmash quality-wise. Today there are only two simple options in the Makefile - use either all of 'backzone' or none of it - and there are real problems with using all of it. Perhaps we could add something that would give users more flexibility.
For example, if a downstream user wants the 'backzone' entry for Europe/Stockholm which is well-documented, but doesn't want backzone's America/Montreal entry because it's not well-attested and is most likely wrong, the user could specify a list of backzone names that includes Europe/Stockholm but excludes America/Montreal. I think it would not be too much work to add something like this to the tzdb code. This would better support users who want a separate Zone for each country in 'backzone', but do not want all of 'backzone'.
To see what some of the major distros do, look at the comments about Ruby on BSDs and package build specs: https://github.com/tzinfo/tzinfo/issues/15#issuecomment-41739379 https://github.com/freebsd/freebsd-src/tree/master/contrib/tzdata https://svnweb.freebsd.org/ports/head/misc/zoneinfo/ https://salsa.debian.org/glibc-team/tzdata/-/tree/sid/debian https://src.fedoraproject.org/rpms/tzdata/tree/rawhide https://build.opensuse.org/package/show/openSUSE:Factory/timezone - view https://github.com/bmwiedemann/openSUSE/tree/master/packages/t/timezone - raw download Most distros have some localized, possibly graphical, tzsetup utility. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

On Thu, May 20, 2021 at 10:57:48AM -0700, Paul Eggert via tz wrote:
On 5/10/21 1:38 AM, Paul Eggert wrote:
I'd like to do more tests before installing it into the development tzdb repository on GitHub. Also, the patch needs a proper NEWS entry and commit message before installing.
I did that and installed the attached revised patch into the development repository.
The second attachment 'adjustments.diff' attempts to records adjustments to this patch, compared to the patch I circulated ten days ago. 'adjustments.diff' is hand-edited due to merges and so is intended only for human consumption.
The most significant adjustment was to add Link lines to 'backzone' so that people interested in out-of-scope pre-1970 data won't see any changes due to this patch. There are also some adjustments to commentary and a dependency fix in the Makefile.
The EU timezones are up for changes any year now - they have this stop observing DST that is decided but was postponed to 2021 before the pandemic struck so we will see when it actually happens. /MF
From 1edbb16e933a6ba6dceefd2bd7057b5ce00dd13c Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Wed, 19 May 2021 19:09:40 -0700 Subject: [PROPOSED] Merge timezones that are alike since 1970 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
* NEWS: Describe the change and its motivation. * Makefile (TZS_DEPS, check_tables): Depend on YDATA, not just PRIMARY_YDATA, since etcetera matters here. * africa (Africa/Abidjan, Ghana, Africa/Accra, Indian/Reunion) (Indian/Mahe): * antarctica (Indian/Kerguelen, Antarctica/DumontDUrville) (Antarctica/Syowa, Antarctica/Vostok): * asia (Asia/Brunei, Asia/Urumqi, NBorneo, Asia/Kuala_Lumpur) (Asia/Kuching, Indian/Maldives, Asia/Riyadh, Asia/Bangkok) (Asia/Dubai): * australasia (Indian/Christmas, Indian/Cocos, Pacific/Gambier) (Pacific/Tahiti, Pacific/Tarawa, Pacific/Majuro, Pacific/Chuuk) (Pacific/Pohnpei, Pacific/Palau, Pacific/Port_Moresby) (Pacific/Guadalcanal, Pacific/Funafuti, Pacific/Wake) (Pacific/Wallis): * europe (Denmark, Europe/Copenhagen, Iceland, Atlantic/Reykjavik) (Lux, Europe/Luxembourg, Europe/Monaco, Neth, Europe/Amsterdam) (Norway, Europe/Oslo, Europe/Stockholm): * northamerica (America/Blanc-Sablon, America/Atikokan) (America/Creston, Bahamas, America/Nassau): * southamerica (America/La_Paz, America/Curacao, America/Cayenne) (Atlantic/South_Georgia, America/Port_of_Spain): Move these duplicate Zone entries to 'backzone', and add backward-compatibility links in 'backward'. * checktab.awk: Don’t worry about links to Etc/*. * theory.html: Change examples to avoid merged-away zones. Remove references to SET, and to Amsterdam, Bangkok, Copenhagen and Port Moresby Mean Times. * zone.tab, zone1970.tab: Change 3rd column to avoid links in 'backward', which might not be present. * zone1970.tab: Merge lines to match the above changes. --- Makefile | 6 +- NEWS | 17 + africa | 146 +------- antarctica | 59 +-- asia | 170 +-------- australasia | 101 +---- backward | 129 +++++-- backzone | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++- checktab.awk | 4 +- etcetera | 2 + europe | 313 +--------------- northamerica | 191 +--------- southamerica | 48 +-- theory.html | 29 +- zone.tab | 156 ++++---- zone1970.tab | 80 ++-- 16 files changed, 1314 insertions(+), 1148 deletions(-)
diff --git a/Makefile b/Makefile index d05f828..ce018ec 100644 --- a/Makefile +++ b/Makefile @@ -529,7 +529,7 @@ TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs TZS_NEW= to$(TZS_YEAR)new.tzs -TZS_DEPS= $(PRIMARY_YDATA) asctime.c localtime.c \ +TZS_DEPS= $(YDATA) asctime.c localtime.c \ private.h tzfile.h zdump.c zic.c # EIGHT_YARDS is just a yard short of the whole ENCHILADA. EIGHT_YARDS = $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) tzdata.zi @@ -802,9 +802,9 @@ check_links: checklinks.awk $(TDATA_TO_CHECK) tzdata.zi $(AWK) -f checklinks.awk tzdata.zi touch $@
-check_tables: checktab.awk $(PRIMARY_YDATA) $(ZONETABLES) +check_tables: checktab.awk $(YDATA) $(ZONETABLES) for tab in $(ZONETABLES); do \ - $(AWK) -f checktab.awk -v zone_table=$$tab $(PRIMARY_YDATA) \ + $(AWK) -f checktab.awk -v zone_table=$$tab $(YDATA) \ || exit; \ done touch $@ diff --git a/NEWS b/NEWS index 6d1cd09..435a40f 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,23 @@ Unreleased, experimental changes (Thanks to P Chan, Michael Deckers, Alexander Krivenyshev and Alois Treindl.)
+ Merge timezones whose timestamps agree since 1970, since pre-1970 + timestamps are out of scope. This change does not affect + post-1970 timestamps, and timezone historians who build with 'make + PACKRATDATA=backzone' should see no changes to pre-1970 timestamps. + When merging, keep the most-populous location's data, and move + data for other locations to 'backzone' with a backward + compatibility link in 'backward'. Also, merge timezones with + neither post-1970 clock changes nor alphabetic abbreviations into + their Etc counterparts. For example, move the Europe/Oslo data to + 'backzone' with a link in 'backward' from Europe/Berlin because + the two timezones' timestamps agree since 1970; this change + affects some pre-1966 timestamps in Europe/Oslo because Berlin and + Oslo disagreed before 1966. For another example, move the + Asia/Aden data to 'backzone' with a link in 'backward' from + Etc/GMT-3. Affected entries range from Africa/Abidjan to + Pacific/Yap. + Changes to maintenance procedure
The new file SECURITY covers how to report security-related bugs. diff --git a/africa b/africa index a867cc4..d842502 100644 --- a/africa +++ b/africa @@ -105,7 +105,7 @@ Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 16 # See Africa/Maputo.
# Burkina Faso -# See Africa/Abidjan. +# See Etc/GMT.
# Burundi # See Africa/Maputo. @@ -147,9 +147,7 @@ Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena # See Africa/Lagos.
# Côte d'Ivoire / Ivory Coast -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Abidjan -0:16:08 - LMT 1912 - 0:00 - GMT +# See Etc/GMT.
# Djibouti # See Africa/Nairobi. @@ -370,94 +368,9 @@ Zone Africa/Cairo 2:05:09 - LMT 1900 Oct # See Africa/Lagos.
# The Gambia -# See Africa/Abidjan. - # Ghana - -# From P Chan (2020-11-20): -# Interpretation Amendment Ordinance, 1915 (No.24 of 1915) [1915-11-02] -# Ordinances of the Gold Coast, Ashanti, Northern Territories 1915, p 69-71 -# https://books.google.com/books?id=ErA-AQAAIAAJ&pg=PA70 -# This Ordinance added "'Time' shall mean Greenwich Mean Time" to the -# Interpretation Ordinance, 1876. -# -# Determination of the Time Ordinance, 1919 (No. 18 of 1919) [1919-11-24] -# Ordinances of the Gold Coast, Ashanti, Northern Territories 1919, p 75-76 -# https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75 -# This Ordinance removed the previous definition of time and introduced DST. -# -# Time Determination Ordinance (Cap. 214) -# The Laws of the Gold Coast (including Togoland Under British Mandate) -# Vol. II (1937), p 2328 -# https://books.google.com/books?id=Z7M-AQAAIAAJ&pg=PA2328 -# Revised edition of the 1919 Ordinance. -# -# Time Determination (Amendment) Ordinance, 1940 (No. 9 of 1940) [1940-04-06] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1940, p 22 -# https://books.google.com/books?id=1ao-AQAAIAAJ&pg=PA22 -# This Ordinance changed the forward transition from September to May. -# -# Defence (Time Determination Ordinance Amendment) Regulations, 1942 -# (Regulations No. 6 of 1942) [1942-01-31, commenced on 1942-02-08] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1942, p 48 -# https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA48 -# These regulations advanced the [standard] time by thirty minutes. -# -# Defence (Time Determination Ordinance Amendment (No.2)) Regulations, -# 1942 (Regulations No. 28 of 1942) [1942-04-25] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1942, p 87 -# https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA87 -# These regulations abolished DST and changed the time to GMT+0:30. -# -# Defence (Revocation) (No.4) Regulations, 1945 (Regulations No. 45 of -# 1945) [1945-10-24, commenced on 1946-01-06] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1945, p 256 -# https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256 -# These regulations revoked the previous two sets of Regulations. -# -# Time Determination (Amendment) Ordinance, 1945 (No. 18 of 1945) [1946-01-06] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1945, p 69 -# https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA69 -# This Ordinance abolished DST. -# -# Time Determination (Amendment) Ordinance, 1950 (No. 26 of 1950) [1950-07-22] -# Annual Volume of the Laws of the Gold Coast: -# Containing All Legislation Enacted During Year 1950, p 35 -# https://books.google.com/books?id=e60-AQAAIAAJ&pg=PA35 -# This Ordinance restored DST but with thirty minutes offset. -# -# Time Determination Ordinance (Cap. 264) -# The Laws of the Gold Coast, Vol. V (1954), p 380 -# https://books.google.com/books?id=Mqc-AQAAIAAJ&pg=PA380 -# Revised edition of the Time Determination Ordinance. -# -# Time Determination (Amendment) Ordinance, 1956 (No. 21 of 1956) [1956-08-29] -# Annual Volume of the Ordinances of the Gold Coast Enacted During the -# Year 1956, p 83 -# https://books.google.com/books?id=VLE-AQAAIAAJ&pg=PA83 -# This Ordinance abolished DST. - -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Ghana 1919 only - Nov 24 0:00 0:20 +0020 -Rule Ghana 1920 1942 - Jan 1 2:00 0 GMT -Rule Ghana 1920 1939 - Sep 1 2:00 0:20 +0020 -Rule Ghana 1940 1941 - May 1 2:00 0:20 +0020 -Rule Ghana 1950 1955 - Sep 1 2:00 0:30 +0030 -Rule Ghana 1951 1956 - Jan 1 2:00 0 GMT - -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Accra -0:00:52 - LMT 1915 Nov 2 - 0:00 Ghana %s 1942 Feb 8 - 0:30 - +0030 1946 Jan 6 - 0:00 Ghana %s - # Guinea -# See Africa/Abidjan. +# See Etc/GMT.
# Guinea-Bissau # @@ -612,7 +525,7 @@ Zone Africa/Tripoli 0:52:44 - LMT 1920
# Mali # Mauritania -# See Africa/Abidjan. +# See Etc/GMT.
# Mauritius
@@ -711,7 +624,7 @@ Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis # See Africa/Nairobi.
# Morocco -# See the 'europe' file for Spanish Morocco (Africa/Ceuta). +# See Africa/Ceuta for Spanish Morocco.
# From Alex Krivenyshev (2008-05-09): # Here is an article that Morocco plan to introduce Daylight Saving Time between @@ -1356,29 +1269,15 @@ Zone Africa/Lagos 0:13:35 - LMT 1905 Jul 1 1:00 - WAT
# Réunion -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis - 4:00 - +04 +# See Etc/GMT-4. # # Crozet Islands also observes Réunion time; see the 'antarctica' file. -# -# Scattered Islands (Îles Éparses) administered from Réunion are as follows. -# The following information about them is taken from -# Îles Éparses (<http://www.outre-mer.gouv.fr/domtom/ile.htm>, 1997-07-22, -# in French; no longer available as of 1999-08-17). -# We have no info about their time zone histories. -# -# Bassas da India - uninhabited -# Europa Island - inhabited from 1905 to 1910 by two families -# Glorioso Is - inhabited until at least 1958 -# Juan de Nova - uninhabited -# Tromelin - inhabited until at least 1958
# Rwanda # See Africa/Maputo.
# St Helena -# See Africa/Abidjan. +# See Etc/GMT. # The other parts of the St Helena territory are similar: # Tristan da Cunha: on GMT, say Whitman and the CIA # Ascension: on GMT, say the USNO (1995-12-21) and the CIA @@ -1413,34 +1312,13 @@ Zone Africa/Sao_Tome 0:26:56 - LMT 1884 0:00 - GMT
# Senegal -# See Africa/Abidjan. +# See Etc/GMT.
# Seychelles - -# From P Chan (2020-11-27): -# Standard Time was adopted on 1907-01-01. -# -# Standard Time Ordinance (Chapter 237) -# The Laws of Seychelles in Force on the 31st December, 1971, Vol. 6, p 571 -# https://books.google.com/books?id=efE-AQAAIAAJ&pg=PA571 -# -# From Tim Parenti (2020-12-05): -# A footnote on https://books.google.com/books?id=DYdDAQAAMAAJ&pg=PA1689 -# confirms that Ordinance No. 9 of 1906 "was brought into force on the 1st -# January, 1907." - -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Mahe 3:41:48 - LMT 1907 Jan 1 # Victoria - 4:00 - +04 -# From Paul Eggert (2001-05-30): -# Aldabra, Farquhar, and Desroches, originally dependencies of the -# Seychelles, were transferred to the British Indian Ocean Territory -# in 1965 and returned to Seychelles control in 1976. We don't know -# whether this affected their time zone, so omit this for now. -# Possibly the islands were uninhabited. +# See Etc/GMT-4.
# Sierra Leone -# See Africa/Abidjan. +# See Etc/GMT.
# Somalia # See Africa/Nairobi. @@ -1505,7 +1383,7 @@ Zone Africa/Juba 2:06:28 - LMT 1931 # See Africa/Nairobi.
# Togo -# See Africa/Abidjan. +# See Etc/GMT.
# Tunisia
@@ -1599,7 +1477,7 @@ Rule Tunisia 2005 only - Sep 30 1:00s 0 - Rule Tunisia 2006 2008 - Mar lastSun 2:00s 1:00 S Rule Tunisia 2006 2008 - Oct lastSun 2:00s 0 -
-# See Europe/Paris for PMT-related transitions. +# See Europe/Paris commentary for PMT-related transitions. # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Africa/Tunis 0:40:44 - LMT 1881 May 12 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time diff --git a/antarctica b/antarctica index ed750a8..6b100a7 100644 --- a/antarctica +++ b/antarctica @@ -148,7 +148,7 @@ Zone Antarctica/Mawson 0 - -00 1954 Feb 13 # # Alfred Faure, Possession Island, Crozet Islands, -462551+0515152, since 1964; # sealing & whaling stations operated variously 1802/1911+; -# see Indian/Reunion. +# see Etc/GMT-4. # # Martin-de-Viviès, Amsterdam Island, -374105+0773155, since 1950 # Port-aux-Français, Kerguelen Islands, -492110+0701303, since 1951; @@ -157,22 +157,10 @@ Zone Antarctica/Mawson 0 - -00 1954 Feb 13 # St Paul Island - near Amsterdam, uninhabited # fishing stations operated variously 1819/1931 # -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Kerguelen 0 - -00 1950 # Port-aux-Français - 5:00 - +05 +# Kerguelen - see Etc/GMT-5. # # year-round base in the main continent -# Dumont d'Urville, Île des Pétrels, -6640+14001, since 1956-11 -# <https://en.wikipedia.org/wiki/Dumont_d'Urville_Station> (2005-12-05) -# -# Another base at Port-Martin, 50km east, began operation in 1947. -# It was destroyed by fire on 1952-01-14. -# -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Antarctica/DumontDUrville 0 - -00 1947 - 10:00 - +10 1952 Jan 14 - 0 - -00 1956 Nov - 10:00 - +10 +# Dumont d'Urville - see Etc/GMT-10.
# France & Italy - year-round base # Concordia, -750600+1232000, since 2005 @@ -188,20 +176,7 @@ Zone Antarctica/DumontDUrville 0 - -00 1947 # Zuchelli, Terra Nova Bay, -744140+1640647, since 1986
# Japan - year-round bases -# Syowa (also known as Showa), -690022+0393524, since 1957 -# -# From Hideyuki Suzuki (1999-02-06): -# In all Japanese stations, +0300 is used as the standard time. -# -# Syowa station, which is the first antarctic station of Japan, -# was established on 1957-01-29. Since Syowa station is still the main -# station of Japan, it's appropriate for the principal location. -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Antarctica/Syowa 0 - -00 1957 Jan 29 - 3:00 - +03 -# See: -# NIPR Antarctic Research Activities (1999-08-17) -# http://www.nipr.ac.jp/english/ara01.html +# See Etc/GMT-3.
# S Korea - year-round base # Jang Bogo, Terra Nova Bay, -743700+1641205 since 2014 @@ -265,31 +240,7 @@ Zone Antarctica/Troll 0 - -00 2005 Feb 12 # year-round from 1960/61 to 1992
# Vostok, since 1957-12-16, temporarily closed 1994-02/1994-11 -# From Craig Mundell (1994-12-15): -# http://quest.arc.nasa.gov/antarctica/QA/computers/Directions,Time,ZIP -# Vostok, which is one of the Russian stations, is set on the same -# time as Moscow, Russia. -# -# From Lee Hotz (2001-03-08): -# I queried the folks at Columbia who spent the summer at Vostok and this is -# what they had to say about time there: -# "in the US Camp (East Camp) we have been on New Zealand (McMurdo) -# time, which is 12 hours ahead of GMT. The Russian Station Vostok was -# 6 hours behind that (although only 2 miles away, i.e. 6 hours ahead -# of GMT). This is a time zone I think two hours east of Moscow. The -# natural time zone is in between the two: 8 hours ahead of GMT." -# -# From Paul Eggert (2001-05-04): -# This seems to be hopelessly confusing, so I asked Lee Hotz about it -# in person. He said that some Antarctic locations set their local -# time so that noon is the warmest part of the day, and that this -# changes during the year and does not necessarily correspond to mean -# solar noon. So the Vostok time might have been whatever the clocks -# happened to be during their visit. So we still don't really know what time -# it is at Vostok. But we'll guess +06. -# -Zone Antarctica/Vostok 0 - -00 1957 Dec 16 - 6:00 - +06 +# See Etc/GMT-6.
# S Africa - year-round bases # Marion Island, -4653+03752 diff --git a/asia b/asia index e2f6446..f1c3d7d 100644 --- a/asia +++ b/asia @@ -255,10 +255,7 @@ Zone Indian/Chagos 4:49:40 - LMT 1907 6:00 - +06
# Brunei -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Brunei 7:39:40 - LMT 1926 Mar # Bandar Seri Begawan - 7:30 - +0730 1933 - 8:00 - +08 +# See Etc/GMT-8.
# Burma / Myanmar
@@ -278,7 +275,7 @@ Zone Asia/Yangon 6:24:47 - LMT 1880 # or Rangoon 6:30 - +0630
# Cambodia -# See Asia/Bangkok. +# See Etc/GMT-7.
# China @@ -534,7 +531,7 @@ Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # In earlier versions of this file, China had many separate Zone entries, but # this was based on what were apparently incorrect data in Shanks & Pottenger. # This has now been simplified to the two entries Asia/Shanghai and -# Asia/Urumqi, with the others being links for backward compatibility. +# Etc/GMT-6, with the others being links for backward compatibility. # Proposed in 1918 and theoretically in effect until 1949 (although in practice # mainly observed in coastal areas), the five zones were: # @@ -556,7 +553,7 @@ Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # Yangchun, Yangjiang, Yu'nan, and Yunfu. # # Xin-zang Time ("Xinjiang-Tibet Time") UT +06 -# This region is now part of either Asia/Urumqi or Asia/Shanghai with +# This region is now part of either Etc/GMT-6 or Asia/Shanghai with # current boundaries uncertain; times before 1970 for areas that # disagree with Ürümqi or Shanghai are not recorded here. # The Gansu counties Aksay, Anxi, Dunhuang, Subei; west Qinghai; @@ -609,68 +606,14 @@ Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # 2. Kashi... # 3. Urumqi... # 4. Kashgar... -# ... -# 5. It seems that Uyghurs in Ürümqi has been using Xinjiang since at least the -# 1960's. I know of one Han, now over 50, who grew up in the surrounding -# countryside and used Xinjiang time as a child. -# -# 6. Likewise for Kashgar and the rest of south Xinjiang I don't know of any -# start date for Xinjiang time. -# -# Without having access to local historical records, nor the ability to legally -# publish them, I would go with October 1, 1949, when Xinjiang became the Uyghur -# Autonomous Region under the PRC. (Before that Uyghurs, of course, would also -# not be using Beijing time, but some local time.) - -# From David Cochrane (2014-03-26): -# Just a confirmation that Ürümqi time was implemented in Ürümqi on 1 Feb 1986: -# https://content.time.com/time/magazine/article/0,9171,960684,00.html - -# From Luther Ma (2014-04-22): -# I have interviewed numerous people of various nationalities and from -# different localities in Xinjiang and can confirm the information in Guo's -# report regarding Xinjiang, as well as the Time article reference by David -# Cochrane. Whether officially recognized or not (and both are officially -# recognized), two separate times have been in use in Xinjiang since at least -# the Cultural Revolution: Xinjiang Time (XJT), aka Ürümqi Time or local time; -# and Beijing Time. There is no confusion in Xinjiang as to which name refers -# to which time. Both are widely used in the province, although in some -# population groups might be use one to the exclusion of the other. The only -# problem is that computers and smart phones list Ürümqi (or Kashgar) as -# having the same time as Beijing. - -# From Paul Eggert (2014-06-30): -# In the early days of the PRC, Tibet was given its own time zone (UT +06) -# but this was withdrawn in 1959 and never reinstated; see Tubten Khétsun, -# Memories of life in Lhasa under Chinese Rule, Columbia U Press, ISBN -# 978-0231142861 (2008), translator's introduction by Matthew Akester, p x. -# As this is before our 1970 cutoff, Tibet doesn't need a separate zone. -# -# Xinjiang Time is well-documented as being officially recognized. E.g., see -# "The Working-Calendar for The Xinjiang Uygur Autonomous Region Government" -# <http://www.sinkiang.gov.cn/service/ourworking/> (2014-04-22). -# Unfortunately, we have no good records of time in Xinjiang before 1986. -# During the 20th century parts of Xinjiang were ruled by the Qing dynasty, -# the Republic of China, various warlords, the First and Second East Turkestan -# Republics, the Soviet Union, the Kuomintang, and the People's Republic of -# China, and tracking down all these organizations' timekeeping rules would be -# quite a trick. Approximate this lost history by a transition from LMT to -# UT +06 at the start of 1928, the year of accession of the warlord Jin Shuren, -# which happens to be the date given by Shanks & Pottenger (no doubt as a -# guess) as the transition from LMT. Ignore the usage of +08 before -# 1986-02-01 under the theory that the transition date to +08 is unknown and -# that the sort of users who prefer Asia/Urumqi now typically ignored the -# +08 mandate back then.
# Zone NAME STDOFF RULES FORMAT [UNTIL] # Beijing time, used throughout China; represented by Shanghai. Zone Asia/Shanghai 8:05:43 - LMT 1901 8:00 Shang C%sT 1949 May 28 8:00 PRC C%sT -# Xinjiang time, used by many in western China; represented by Ürümqi / Ürümchi -# / Wulumuqi. (Please use Asia/Shanghai if you prefer Beijing time.) -Zone Asia/Urumqi 5:50:20 - LMT 1928 - 6:00 - +06 +# See Etc/GMT-6 for Xinjiang time, used by many in western China. +# (Please use Asia/Shanghai if you prefer Beijing time.)
# Hong Kong @@ -2693,10 +2636,10 @@ Zone Asia/Pyongyang 8:23:00 - LMT 1908 Apr 1 ###############################################################################
# Kuwait -# See Asia/Riyadh. +# See Etc/GMT-3.
# Laos -# See Asia/Bangkok. +# See Etc/GMT-7.
# Lebanon @@ -2730,39 +2673,12 @@ Zone Asia/Beirut 2:22:00 - LMT 1880 2:00 Lebanon EE%sT
# Malaysia -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 - -Rule NBorneo 1935 1941 - Dec 14 0:00 0 - -# -# peninsular Malaysia -# taken from Mok Ly Yng (2003-10-30) -# http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 - 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. - 7:00 - +07 1933 Jan 1 - 7:00 0:20 +0720 1936 Jan 1 - 7:20 - +0720 1941 Sep 1 - 7:30 - +0730 1942 Feb 16 - 9:00 - +09 1945 Sep 12 - 7:30 - +0730 1982 Jan 1 - 8:00 - +08 -# Sabah & Sarawak -# From Paul Eggert (2014-08-12): -# The data entries here are mostly from Shanks & Pottenger, but the 1942, 1945 -# and 1982 transition dates are from Mok Ly Yng. -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Kuching 7:21:20 - LMT 1926 Mar - 7:30 - +0730 1933 - 8:00 NBorneo +08/+0820 1942 Feb 16 - 9:00 - +09 1945 Sep 12 - 8:00 - +08 +# For peninsular Malaysia see Asia/Singapore. +# For Sabah & Sarawak see Etc/GMT-8.
# Maldives -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Maldives 4:54:00 - LMT 1880 # Malé - 4:54:00 - MMT 1960 # Malé Mean Time - 5:00 - +05 +# See Etc/GMT-5. +
# Mongolia
@@ -2926,7 +2842,7 @@ Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:45 - +0545
# Oman -# See Asia/Dubai. +# See Etc/GMT-4.
# Pakistan
@@ -3523,54 +3439,11 @@ Zone Asia/Qatar 3:26:08 - LMT 1920 # Al Dawhah / Doha 3:00 - +03
# Saudi Arabia -# -# From Paul Eggert (2018-08-29): -# Time in Saudi Arabia and other countries in the Arabian peninsula was not -# standardized until 1968 or so; we don't know exactly when, and possibly it -# has never been made official. Richard P Hunt, in "Islam city yielding to -# modern times", New York Times (1961-04-09), p 20, wrote that only airlines -# observed standard time, and that people in Jeddah mostly observed quasi-solar -# time, doing so by setting their watches at sunrise to 6 o'clock (or to 12 -# o'clock for "Arab" time). -# -# Timekeeping differed depending on who you were and which part of Saudi -# Arabia you were in. In 1969, Elias Antar wrote that although a common -# practice had been to set one's watch to 12:00 (i.e., midnight) at sunset - -# which meant that the time on one side of a mountain could differ greatly from -# the time on the other side - many foreigners set their watches to 6pm -# instead, while airlines instead used UTC +03 (except in Dhahran, where they -# used UTC +04), Aramco used UTC +03 with DST, and the Trans-Arabian Pipe Line -# Company used Aramco time in eastern Saudi Arabia and airline time in western. -# (The American Military Aid Advisory Group used plain UTC.) Antar writes, -# "A man named Higgins, so the story goes, used to run a local power -# station. One day, the whole thing became too much for Higgins and he -# assembled his staff and laid down the law. 'I've had enough of this,' he -# shrieked. 'It is now 12 o'clock Higgins Time, and from now on this station is -# going to run on Higgins Time.' And so, until last year, it did." See: -# Antar E. Dinner at When? Saudi Aramco World, 1969 March/April. 2-3. -# http://archive.aramcoworld.com/issue/196902/dinner.at.when.htm -# Also see: Antar EN. Arabian flying is confusing. -# Port Angeles (WA) Evening News. 1965-03-10. page 3. -# -# The TZ database cannot represent quasi-solar time; airline time is the best -# we can do. The 1946 foreign air news digest of the U.S. Civil Aeronautics -# Board (OCLC 42299995) reported that the "... Arabian Government, inaugurated -# a weekly Dhahran-Cairo service, via the Saudi Arabian cities of Riyadh and -# Jidda, on March 14, 1947". Shanks & Pottenger guessed 1950; go with the -# earlier date. -# -# Shanks & Pottenger also state that until 1968-05-01 Saudi Arabia had two -# time zones; the other zone, at UT +04, was in the far eastern part of -# the country. Presumably this is documenting airline time. Ignore this, -# as it's before our 1970 cutoff. -# -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 - 3:00 - +03 +# See Etc/GMT-3.
# Singapore # taken from Mok Ly Yng (2003-10-30) -# http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html +# https://web.archive.org/web/20190822231045/http://www.math.nus.edu.sg/~mathe... # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. @@ -3819,10 +3692,7 @@ Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 5:00 - +05
# Thailand -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Bangkok 6:42:04 - LMT 1880 - 6:42:04 - BMT 1920 Apr # Bangkok Mean Time - 7:00 - +07 +# See Etc/GMT-7.
# Turkmenistan # From Shanks & Pottenger. @@ -3834,9 +3704,7 @@ Zone Asia/Ashgabat 3:53:32 - LMT 1924 May 2 # or Ashkhabad 5:00 - +05
# United Arab Emirates -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Asia/Dubai 3:41:12 - LMT 1920 - 4:00 - +04 +# See Etc/GMT-4.
# Uzbekistan # Byalokoz 1919 says Uzbekistan was 4:27:53. @@ -3926,9 +3794,9 @@ Zone Asia/Ho_Chi_Minh 7:06:40 - LMT 1906 Jul 1 # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), -# use Asia/Bangkok; see the VN entries in the file zone1970.tab. +# use Etc/GMT-7; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.
# Yemen -# See Asia/Riyadh. +# See Etc/GMT-3. diff --git a/australasia b/australasia index 18dfd93..9d3cd2f 100644 --- a/australasia +++ b/australasia @@ -252,16 +252,10 @@ Zone Antarctica/Macquarie 0 - -00 1899 Nov 10:00 AT AE%sT
# Christmas -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Christmas 7:02:52 - LMT 1895 Feb - 7:00 - +07 +# See Etc/GMT-7.
# Cocos (Keeling) Is -# These islands were ruled by the Ross family from about 1830 to 1978. -# We don't know when standard time was introduced; for now, we guess 1900. -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Indian/Cocos 6:27:40 - LMT 1900 - 6:30 - +0630 +# See Asia/Yangon.
# Fiji @@ -409,12 +403,9 @@ Zone Pacific/Fiji 11:55:44 - LMT 1915 Oct 26 # Suva
# French Polynesia # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea - -9:00 - -09 Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct -9:30 - -0930 -Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct # Papeete - -10:00 - -10 +# See Etc/GMT+9 for the Gambier Islands and Etc/GMT+10 for the Society Islands. # Clipperton (near North America) is administered from French Polynesia; # it is uninhabited.
@@ -460,9 +451,8 @@ Zone Pacific/Guam -14:21:00 - LMT 1844 Dec 31 10:00 - ChST # Chamorro Standard Time
# Kiribati +# See Etc/GMT-12 for the Gilbert Islands. # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki - 12:00 - +12 Zone Pacific/Enderbury -11:24:20 - LMT 1901 -12:00 - -12 1979 Oct -11:00 - -11 1994 Dec 31 @@ -476,15 +466,8 @@ Zone Pacific/Kiritimati -10:29:20 - LMT 1901 # See Pacific/Guam.
# Marshall Is +# See Etc/GMT-12 for most locations. # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Majuro 11:24:48 - LMT 1901 - 11:00 - +11 1914 Oct - 9:00 - +09 1919 Feb 1 - 11:00 - +11 1937 - 10:00 - +10 1941 Apr 1 - 9:00 - +09 1944 Jan 30 - 11:00 - +11 1969 Oct - 12:00 - +12 Zone Pacific/Kwajalein 11:09:20 - LMT 1901 11:00 - +11 1937 10:00 - +10 1941 Apr 1 @@ -494,22 +477,9 @@ Zone Pacific/Kwajalein 11:09:20 - LMT 1901 12:00 - +12
# Micronesia +# For Chuuk and Yap see Etc/GMT-10. +# For Pohnpei see Etc/GMT-11. # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 - 10:07:08 - LMT 1901 - 10:00 - +10 1914 Oct - 9:00 - +09 1919 Feb 1 - 10:00 - +10 1941 Apr 1 - 9:00 - +09 1945 Aug - 10:00 - +10 -Zone Pacific/Pohnpei -13:27:08 - LMT 1844 Dec 31 # Kolonia - 10:32:52 - LMT 1901 - 11:00 - +11 1914 Oct - 9:00 - +09 1919 Feb 1 - 11:00 - +11 1937 - 10:00 - +10 1941 Apr 1 - 9:00 - +09 1945 Aug - 11:00 - +11 Zone Pacific/Kosrae -13:08:04 - LMT 1844 Dec 31 10:51:56 - LMT 1901 11:00 - +11 1914 Oct @@ -658,16 +628,10 @@ Zone Pacific/Norfolk 11:11:52 - LMT 1901 # Kingston 11:00 AN +11/+12
# Palau (Belau) -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Palau -15:02:04 - LMT 1844 Dec 31 # Koror - 8:57:56 - LMT 1901 - 9:00 - +09 +# See Etc/GMT-9.
# Papua New Guinea -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Port_Moresby 9:48:40 - LMT 1880 - 9:48:32 - PMMT 1895 # Port Moresby Mean Time - 10:00 - +10 +# See Etc/GMT-10 for most locations. # # From Paul Eggert (2014-10-13): # Base the Bougainville entry on the Arawa-Kieta region, which appears to have @@ -787,9 +751,8 @@ Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5
# Solomon Is # excludes Bougainville, for which see Papua New Guinea -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara - 11:00 - +11 +# See Etc/GMT-11. +
# Tokelau # @@ -830,9 +793,7 @@ Zone Pacific/Tongatapu 12:19:12 - LMT 1945 Sep 10 13:00 Tonga +13/+14
# Tuvalu -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Funafuti 11:56:52 - LMT 1901 - 12:00 - +12 +# See Etc/GMT-12.
# US minor outlying islands @@ -891,9 +852,7 @@ Zone Pacific/Funafuti 11:56:52 - LMT 1901 # uninhabited since World War II; was probably like Pacific/Kiritimati
# Wake -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Wake 11:06:28 - LMT 1901 - 12:00 - +12 +# See Etc/GMT-12.
# Vanuatu @@ -932,9 +891,7 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila 11:00 Vanuatu +11/+12
# Wallis and Futuna -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Wallis 12:15:20 - LMT 1901 - 12:00 - +12 +# See Etc/GMT-12.
###############################################################################
@@ -1834,13 +1791,6 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # Like the Ladrones (see Guam commentary), assume the Spanish East Indies # kept American time until the Philippines switched at the end of 1844.
-# Alan Eugene Davis writes (1996-03-16), -# "I am certain, having lived there for the past decade, that 'Truk' -# (now properly known as Chuuk) ... is in the time zone GMT+10." -# -# Shanks & Pottenger write that Truk switched from UT +10 to +11 -# on 1978-10-01; ignore this for now. - # From Paul Eggert (1999-10-29): # The Federated States of Micronesia Visitors Board writes in # The Federated States of Micronesia - Visitor Information (1999-01-26) @@ -2001,9 +1951,6 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # From Michael Deckers (2019-08-14): # https://www.legislation.gov.au/Details/F2019C00010
-# Palau -# See commentary for Micronesia. - # Pitcairn
# From Rives McDow (1999-11-08): @@ -2173,26 +2120,6 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # For now, guess that DST is discontinued. That's what the IATA is guessing.
-# Wake - -# From Vernice Anderson, Personal Secretary to Philip Jessup, -# US Ambassador At Large (oral history interview, 1971-02-02): -# -# Saturday, the 14th [of October, 1950] - ... The time was all the -# more confusing at that point, because we had crossed the -# International Date Line, thus getting two Sundays. Furthermore, we -# discovered that Wake Island had two hours of daylight saving time -# making calculation of time in Washington difficult if not almost -# impossible. -# -# https://www.trumanlibrary.org/oralhist/andrsonv.htm - -# From Paul Eggert (2003-03-23): -# We have no other report of DST in Wake Island, so omit this info for now. - -# See also the commentary for Micronesia. - - ###############################################################################
# The International Date Line diff --git a/backward b/backward index 9b5e6d0..0d9ecfa 100644 --- a/backward +++ b/backward @@ -5,30 +5,35 @@
# This file provides links between current names for timezones # and their old names. Many names changed in late 1993. +# Many others were moved here in 2021. Several of these names are +# also present in the file 'backzone', which has data important only +# for pre-1970 timestamps and so is out of scope for tzdb proper.
# Link TARGET LINK-NAME +Link Etc/GMT Africa/Abidjan +Link Etc/GMT Africa/Accra Link Africa/Nairobi Africa/Addis_Ababa Link Africa/Nairobi Africa/Asmara Link Africa/Nairobi Africa/Asmera -Link Africa/Abidjan Africa/Bamako +Link Etc/GMT Africa/Bamako Link Africa/Lagos Africa/Bangui -Link Africa/Abidjan Africa/Banjul +Link Etc/GMT Africa/Banjul Link Africa/Maputo Africa/Blantyre Link Africa/Lagos Africa/Brazzaville Link Africa/Maputo Africa/Bujumbura -Link Africa/Abidjan Africa/Conakry -Link Africa/Abidjan Africa/Dakar +Link Etc/GMT Africa/Conakry +Link Etc/GMT Africa/Dakar Link Africa/Nairobi Africa/Dar_es_Salaam Link Africa/Nairobi Africa/Djibouti Link Africa/Lagos Africa/Douala -Link Africa/Abidjan Africa/Freetown +Link Etc/GMT Africa/Freetown Link Africa/Maputo Africa/Gaborone Link Africa/Maputo Africa/Harare Link Africa/Nairobi Africa/Kampala Link Africa/Maputo Africa/Kigali Link Africa/Lagos Africa/Kinshasa Link Africa/Lagos Africa/Libreville -Link Africa/Abidjan Africa/Lome +Link Etc/GMT Africa/Lome Link Africa/Lagos Africa/Luanda Link Africa/Maputo Africa/Lubumbashi Link Africa/Maputo Africa/Lusaka @@ -37,75 +42,95 @@ Link Africa/Johannesburg Africa/Maseru Link Africa/Johannesburg Africa/Mbabane Link Africa/Nairobi Africa/Mogadishu Link Africa/Lagos Africa/Niamey -Link Africa/Abidjan Africa/Nouakchott -Link Africa/Abidjan Africa/Ouagadougou +Link Etc/GMT Africa/Nouakchott +Link Etc/GMT Africa/Ouagadougou Link Africa/Lagos Africa/Porto-Novo -Link Africa/Abidjan Africa/Timbuktu -Link America/Port_of_Spain America/Anguilla -Link America/Port_of_Spain America/Antigua +Link Etc/GMT Africa/Timbuktu +Link America/Puerto_Rico America/Anguilla +Link America/Puerto_Rico America/Antigua Link America/Argentina/Catamarca America/Argentina/ComodRivadavia -Link America/Curacao America/Aruba +Link America/Puerto_Rico America/Aruba +Link America/Panama America/Atikokan Link America/Adak America/Atka +Link America/Puerto_Rico America/Blanc-Sablon Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca +Link Etc/GMT+3 America/Cayenne Link America/Panama America/Cayman -Link America/Atikokan America/Coral_Harbour +Link America/Panama America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba -Link America/Port_of_Spain America/Dominica +Link America/Phoenix America/Creston +Link America/Puerto_Rico America/Curacao +Link America/Puerto_Rico America/Dominica Link America/Tijuana America/Ensenada Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Nuuk America/Godthab -Link America/Port_of_Spain America/Grenada -Link America/Port_of_Spain America/Guadeloupe +Link America/Puerto_Rico America/Grenada +Link America/Puerto_Rico America/Guadeloupe Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Indiana/Knox America/Knox_IN -Link America/Curacao America/Kralendijk +Link America/Puerto_Rico America/Kralendijk +Link Etc/GMT+4 America/La_Paz Link America/Kentucky/Louisville America/Louisville -Link America/Curacao America/Lower_Princes -Link America/Port_of_Spain America/Marigot +Link America/Puerto_Rico America/Lower_Princes +Link America/Puerto_Rico America/Marigot Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal -Link America/Port_of_Spain America/Montserrat +Link America/Puerto_Rico America/Montserrat +Link America/Toronto America/Nassau +Link America/Puerto_Rico America/Port_of_Spain Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock -Link America/Port_of_Spain America/St_Barthelemy -Link America/Port_of_Spain America/St_Kitts -Link America/Port_of_Spain America/St_Lucia -Link America/Port_of_Spain America/St_Thomas -Link America/Port_of_Spain America/St_Vincent -Link America/Port_of_Spain America/Tortola -Link America/Port_of_Spain America/Virgin +Link America/Puerto_Rico America/St_Barthelemy +Link America/Puerto_Rico America/St_Kitts +Link America/Puerto_Rico America/St_Lucia +Link America/Puerto_Rico America/St_Thomas +Link America/Puerto_Rico America/St_Vincent +Link America/Puerto_Rico America/Tortola +Link America/Puerto_Rico America/Virgin +Link Etc/GMT-10 Antarctica/DumontDUrville Link Pacific/Auckland Antarctica/McMurdo Link Pacific/Auckland Antarctica/South_Pole -Link Europe/Oslo Arctic/Longyearbyen -Link Asia/Riyadh Asia/Aden +Link Etc/GMT-3 Antarctica/Syowa +Link Etc/GMT-6 Antarctica/Vostok +Link Europe/Berlin Arctic/Longyearbyen +Link Etc/GMT-3 Asia/Aden Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Qatar Asia/Bahrain +Link Etc/GMT-7 Asia/Bangkok +Link Etc/GMT-8 Asia/Brunei Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca +Link Etc/GMT-4 Asia/Dubai Link Asia/Shanghai Asia/Harbin Link Europe/Istanbul Asia/Istanbul -Link Asia/Urumqi Asia/Kashgar +Link Etc/GMT-6 Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu -Link Asia/Riyadh Asia/Kuwait +Link Asia/Singapore Asia/Kuala_Lumpur +Link Etc/GMT-8 Asia/Kuching +Link Etc/GMT-3 Asia/Kuwait Link Asia/Macau Asia/Macao -Link Asia/Dubai Asia/Muscat -Link Asia/Bangkok Asia/Phnom_Penh +Link Etc/GMT-4 Asia/Muscat +Link Etc/GMT-7 Asia/Phnom_Penh Link Asia/Yangon Asia/Rangoon +Link Etc/GMT-3 Asia/Riyadh Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Jerusalem Asia/Tel_Aviv Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator -Link Asia/Bangkok Asia/Vientiane +Link Etc/GMT-6 Asia/Urumqi +Link Etc/GMT-7 Asia/Vientiane Link Atlantic/Faroe Atlantic/Faeroe -Link Europe/Oslo Atlantic/Jan_Mayen -Link Africa/Abidjan Atlantic/St_Helena +Link Europe/Berlin Atlantic/Jan_Mayen +Link Etc/GMT Atlantic/Reykjavik +Link Etc/GMT+2 Atlantic/South_Georgia +Link Etc/GMT Atlantic/St_Helena Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Hobart Australia/Currie @@ -139,19 +164,25 @@ Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Etc/UTC Etc/UCT +Link Europe/Brussels Europe/Amsterdam Link Europe/London Europe/Belfast Link Europe/Prague Europe/Bratislava Link Europe/Zurich Europe/Busingen +Link Europe/Berlin Europe/Copenhagen Link Europe/London Europe/Guernsey Link Europe/London Europe/Isle_of_Man Link Europe/London Europe/Jersey Link Europe/Belgrade Europe/Ljubljana +Link Europe/Brussels Europe/Luxembourg Link Europe/Helsinki Europe/Mariehamn +Link Europe/Paris Europe/Monaco Link Asia/Nicosia Europe/Nicosia +Link Europe/Berlin Europe/Oslo Link Europe/Belgrade Europe/Podgorica Link Europe/Rome Europe/San_Marino Link Europe/Belgrade Europe/Sarajevo Link Europe/Belgrade Europe/Skopje +Link Europe/Berlin Europe/Stockholm Link Europe/Chisinau Europe/Tiraspol Link Europe/Zurich Europe/Vaduz Link Europe/Rome Europe/Vatican @@ -163,10 +194,16 @@ Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong -Link Atlantic/Reykjavik Iceland +Link Etc/GMT Iceland Link Africa/Nairobi Indian/Antananarivo +Link Etc/GMT-7 Indian/Christmas +Link Asia/Yangon Indian/Cocos Link Africa/Nairobi Indian/Comoro +Link Etc/GMT-5 Indian/Kerguelen +Link Etc/GMT-4 Indian/Mahe +Link Etc/GMT-5 Indian/Maldives Link Africa/Nairobi Indian/Mayotte +Link Etc/GMT-4 Indian/Reunion Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica @@ -180,13 +217,25 @@ Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC +Link Etc/GMT-10 Pacific/Chuuk +Link Etc/GMT-12 Pacific/Funafuti +Link Etc/GMT+9 Pacific/Gambier +Link Etc/GMT-11 Pacific/Guadalcanal Link Pacific/Honolulu Pacific/Johnston +Link Etc/GMT-12 Pacific/Majuro Link Pacific/Pago_Pago Pacific/Midway -Link Pacific/Pohnpei Pacific/Ponape +Link Etc/GMT-9 Pacific/Palau +Link Etc/GMT-11 Pacific/Pohnpei +Link Etc/GMT-11 Pacific/Ponape +Link Etc/GMT-10 Pacific/Port_Moresby Link Pacific/Guam Pacific/Saipan Link Pacific/Pago_Pago Pacific/Samoa -Link Pacific/Chuuk Pacific/Truk -Link Pacific/Chuuk Pacific/Yap +Link Etc/GMT+10 Pacific/Tahiti +Link Etc/GMT-12 Pacific/Tarawa +Link Etc/GMT-10 Pacific/Truk +Link Etc/GMT-12 Pacific/Wake +Link Etc/GMT-12 Pacific/Wallis +Link Etc/GMT-10 Pacific/Yap Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC diff --git a/backzone b/backzone index 8e4f97a..b58f4d8 100644 --- a/backzone +++ b/backzone @@ -68,6 +68,96 @@ # # As explained in the zic man page, the zone columns are: # Zone NAME STDOFF RULES FORMAT [UNTIL] +# and the rule columns are: +# Rule NAME FROM TO - IN ON AT SAVE LETTER/S + + +# Côte d'Ivoire / Ivory Coast +Zone Africa/Abidjan -0:16:08 - LMT 1912 + 0:00 - GMT + + +# Ghana + +# From P Chan (2020-11-20): +# Interpretation Amendment Ordinance, 1915 (No.24 of 1915) [1915-11-02] +# Ordinances of the Gold Coast, Ashanti, Northern Territories 1915, p 69-71 +# https://books.google.com/books?id=ErA-AQAAIAAJ&pg=PA70 +# This Ordinance added "'Time' shall mean Greenwich Mean Time" to the +# Interpretation Ordinance, 1876. +# +# Determination of the Time Ordinance, 1919 (No. 18 of 1919) [1919-11-24] +# Ordinances of the Gold Coast, Ashanti, Northern Territories 1919, p 75-76 +# https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75 +# This Ordinance removed the previous definition of time and introduced DST. +# +# Time Determination Ordinance (Cap. 214) +# The Laws of the Gold Coast (including Togoland Under British Mandate) +# Vol. II (1937), p 2328 +# https://books.google.com/books?id=Z7M-AQAAIAAJ&pg=PA2328 +# Revised edition of the 1919 Ordinance. +# +# Time Determination (Amendment) Ordinance, 1940 (No. 9 of 1940) [1940-04-06] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1940, p 22 +# https://books.google.com/books?id=1ao-AQAAIAAJ&pg=PA22 +# This Ordinance changed the forward transition from September to May. +# +# Defence (Time Determination Ordinance Amendment) Regulations, 1942 +# (Regulations No. 6 of 1942) [1942-01-31, commenced on 1942-02-08] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1942, p 48 +# https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA48 +# These regulations advanced the [standard] time by thirty minutes. +# +# Defence (Time Determination Ordinance Amendment (No.2)) Regulations, +# 1942 (Regulations No. 28 of 1942) [1942-04-25] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1942, p 87 +# https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA87 +# These regulations abolished DST and changed the time to GMT+0:30. +# +# Defence (Revocation) (No.4) Regulations, 1945 (Regulations No. 45 of +# 1945) [1945-10-24, commenced on 1946-01-06] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1945, p 256 +# https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256 +# These regulations revoked the previous two sets of Regulations. +# +# Time Determination (Amendment) Ordinance, 1945 (No. 18 of 1945) [1946-01-06] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1945, p 69 +# https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA69 +# This Ordinance abolished DST. +# +# Time Determination (Amendment) Ordinance, 1950 (No. 26 of 1950) [1950-07-22] +# Annual Volume of the Laws of the Gold Coast: +# Containing All Legislation Enacted During Year 1950, p 35 +# https://books.google.com/books?id=e60-AQAAIAAJ&pg=PA35 +# This Ordinance restored DST but with thirty minutes offset. +# +# Time Determination Ordinance (Cap. 264) +# The Laws of the Gold Coast, Vol. V (1954), p 380 +# https://books.google.com/books?id=Mqc-AQAAIAAJ&pg=PA380 +# Revised edition of the Time Determination Ordinance. +# +# Time Determination (Amendment) Ordinance, 1956 (No. 21 of 1956) [1956-08-29] +# Annual Volume of the Ordinances of the Gold Coast Enacted During the +# Year 1956, p 83 +# https://books.google.com/books?id=VLE-AQAAIAAJ&pg=PA83 +# This Ordinance abolished DST. + +Rule Ghana 1919 only - Nov 24 0:00 0:20 +0020 +Rule Ghana 1920 1942 - Jan 1 2:00 0 GMT +Rule Ghana 1920 1939 - Sep 1 2:00 0:20 +0020 +Rule Ghana 1940 1941 - May 1 2:00 0:20 +0020 +Rule Ghana 1950 1955 - Sep 1 2:00 0:30 +0030 +Rule Ghana 1951 1956 - Jan 1 2:00 0 GMT + +Zone Africa/Accra -0:00:52 - LMT 1915 Nov 2 + 0:00 Ghana %s 1942 Feb 8 + 0:30 - +0030 1946 Jan 6 + 0:00 Ghana %s
# Ethiopia # From Paul Eggert (2014-07-31): @@ -201,7 +291,6 @@ Zone Africa/Douala 0:38:48 - LMT 1912 # https://mm.icann.org/pipermail/tz/2021-February/029866.html # Go with the above.
-# Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule SL 1932 only - Dec 1 0:00 0:20 -0040 Rule SL 1933 1938 - Mar 31 24:00 0 -01 Rule SL 1933 1939 - Aug 31 24:00 0:20 -0040 @@ -350,6 +439,90 @@ Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad -4:30 - -0430 1965 -4:00 - AST
+# Atikokan, Ontario + +# From Paul Eggert (1997-10-17): +# Mark Brader writes that an article in the 1997-10-14 Toronto Star +# says that Atikokan, Ontario currently does not observe DST, +# but will vote on 11-10 whether to use EST/EDT. +# He also writes that the Ontario Time Act (1990, Chapter T.9) +# http://www.gov.on.ca/MBS/english/publications/statregs/conttext.html +# says that Ontario east of 90W uses EST/EDT, and west of 90W uses CST/CDT. +# Officially Atikokan is therefore on CST/CDT, and most likely this report +# concerns a non-official time observed as a matter of local practice. +# +# From Paul Eggert (2000-10-02): +# Matthews and Vincent (1998) write that Atikokan, Pickle Lake, and +# New Osnaburgh observe CST all year, that Big Trout Lake observes +# CST/CDT, and that Upsala and Shebandowan observe EST/EDT, all in +# violation of the official Ontario rules. +# +# From Paul Eggert (2006-07-09): +# Chris Walton (2006-07-06) mentioned an article by Stephanie MacLellan in the +# 2005-07-21 Chronicle-Journal, which said: +# +# The clocks in Atikokan stay set on standard time year-round. +# This means they spend about half the time on central time and +# the other half on eastern time. +# +# For the most part, the system works, Mayor Dennis Brown said. +# +# "The majority of businesses in Atikokan deal more with Eastern +# Canada, but there are some that deal with Western Canada," he +# said. "I don't see any changes happening here." +# +# Walton also writes "Supposedly Pickle Lake and Mishkeegogamang +# [New Osnaburgh] follow the same practice." + +# From Garry McKinnon (2006-07-14) via Chris Walton: +# I chatted with a member of my board who has an outstanding memory +# and a long history in Atikokan (and in the telecom industry) and he +# can say for certain that Atikokan has been practicing the current +# time keeping since 1952, at least. + +# From Paul Eggert (2006-07-17): +# Shanks & Pottenger say that Atikokan has agreed with Rainy River +# ever since standard time was introduced, but the information from +# McKinnon sounds more authoritative. For now, assume that Atikokan +# switched to EST immediately after WWII era daylight saving time +# ended. This matches the old (less-populous) America/Coral_Harbour +# entry since our cutoff date of 1970, so we can move +# America/Coral_Harbour to the 'backward' file. + +Zone America/Atikokan -6:06:28 - LMT 1895 + -6:00 Canada C%sT 1940 Sep 29 + -6:00 1:00 CDT 1942 Feb 9 2:00s + -6:00 Canada C%sT 1945 Sep 30 2:00 + -5:00 - EST + +# Quebec east of Natashquan + +# From Paul Eggert (2021-05-09): +# H. David Matthews and Mary Vincent's map +# "It's about TIME", _Canadian Geographic_ (September-October 1998) +# http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp +# says that Quebec east of the -63 meridian is supposed to observe +# AST, but residents as far east as Natashquan use EST/EDT, and +# residents east of Natashquan use AST. +# The Quebec department of justice writes in +# "The situation in Minganie and Basse-Côte-Nord" +# https://www.justice.gouv.qc.ca/en/department/ministre/functions-and-responsa... +# that the coastal strip from just east of Natashquan to Blanc-Sablon +# observes Atlantic standard time all year round. +# This common practice was codified into law as of 2007; see Legal Time Act, +# CQLR c T-5.1 <http://legisquebec.gouv.qc.ca/en/ShowDoc/cs/T-5.1>. +# For lack of better info, guess this practice began around 1970, contra to +# Shanks & Pottenger who have this region observing AST/ADT. + +Zone America/Blanc-Sablon -3:48:28 - LMT 1884 + -4:00 Canada A%sT 1970 + -4:00 - AST + +# French Guiana +Zone America/Cayenne -3:29:20 - LMT 1911 Jul + -4:00 - -04 1967 Oct + -3:00 - -03 + # Cayman Is Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown -5:07:10 - KMT 1912 Feb # Kingston Mean Time @@ -370,6 +543,85 @@ Zone America/Coral_Harbour -5:32:40 - LMT 1884 -5:00 NT_YK E%sT 1946 -5:00 - EST
+# From Chris Walton (2011-12-01): +# There are two areas within the Canadian province of British Columbia +# that do not currently observe daylight saving: +# a) The Creston Valley (includes the town of Creston and surrounding area) +# b) The eastern half of the Peace River Regional District +# (includes the cities of Dawson Creek and Fort St. John) + +# Earlier this year I stumbled across a detailed article about the time +# keeping history of Creston; it was written by Tammy Hardwick who is the +# manager of the Creston & District Museum. The article was written in May 2009. +# http://www.ilovecreston.com/?p=articles&t=spec&ar=260 +# According to the article, Creston has not changed its clocks since June 1918. +# i.e. Creston has been stuck on UT-7 for 93 years. +# Dawson Creek, on the other hand, changed its clocks as recently as April 1972. + +# Unfortunately the exact date for the time change in June 1918 remains +# unknown and will be difficult to ascertain. I e-mailed Tammy a few months +# ago to ask if Sunday June 2 was a reasonable guess. She said it was just +# as plausible as any other date (in June). She also said that after writing +# the article she had discovered another time change in 1916; this is the +# subject of another article which she wrote in October 2010. +# http://www.creston.museum.bc.ca/index.php?module=comments&uop=view_comment&c... + +# Here is a summary of the three clock change events in Creston's history: +# 1. 1884 or 1885: adoption of Mountain Standard Time (GMT-7) +# Exact date unknown +# 2. Oct 1916: switch to Pacific Standard Time (GMT-8) +# Exact date in October unknown; Sunday October 1 is a reasonable guess. +# 3. June 1918: switch to Pacific Daylight Time (GMT-7) +# Exact date in June unknown; Sunday June 2 is a reasonable guess. +# note 1: +# On Oct 27/1918 when daylight saving ended in the rest of Canada, +# Creston did not change its clocks. +# note 2: +# During WWII when the Federal Government legislated a mandatory clock change, +# Creston did not oblige. +# note 3: +# There is no guarantee that Creston will remain on Mountain Standard Time +# (UTC-7) forever. +# The subject was debated at least once this year by the town Council. +# http://www.bclocalnews.com/kootenay_rockies/crestonvalleyadvance/news/116760... + +# During a period WWII, summer time (Daylight saying) was mandatory in Canada. +# In Creston, that was handled by shifting the area to PST (-8:00) then applying +# summer time to cause the offset to be -7:00, the same as it had been before +# the change. It can be argued that the timezone abbreviation during this +# period should be PDT rather than MST, but that doesn't seem important enough +# (to anyone) to further complicate the rules. + +# The transition dates (and times) are guesses. + +Zone America/Creston -7:46:04 - LMT 1884 + -7:00 - MST 1916 Oct 1 + -8:00 - PST 1918 Jun 2 + -7:00 - MST + +# Curaçao +# Milne gives 4:35:46.9 for Curaçao mean time; round to nearest. +# +# From Paul Eggert (2006-03-22): +# Shanks & Pottenger say that The Bottom and Philipsburg have been at +# -4:00 since standard time was introduced on 1912-03-02; and that +# Kralendijk and Rincon used Kralendijk Mean Time (-4:33:08) from +# 1912-02-02 to 1965-01-01. The former is dubious, since S&P also say +# Saba Island has been like Curaçao. +# This all predates our 1970 cutoff, though. +# +# By July 2007 Curaçao and St Maarten are planned to become +# associated states within the Netherlands, much like Aruba; +# Bonaire, Saba and St Eustatius would become directly part of the +# Netherlands as Kingdom Islands. This won't affect their time zones +# though, as far as we know. +# +Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad + -4:30 - -0430 1965 + -4:00 - AST +Link America/Curacao America/Kralendijk +Link America/Curacao America/Lower_Princes + # Dominica Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau -4:00 - AST @@ -392,6 +644,12 @@ Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe-à-Pitre -4:00 - AST
+# Bolivia +Zone America/La_Paz -4:32:36 - LMT 1890 + -4:32:36 - CMT 1931 Oct 15 # Calamarca MT + -4:32:36 1:00 BST 1932 Mar 21 # Bolivia ST + -4:00 - -04 + # Canada # # From Paul Eggert (2015-03-24): @@ -403,7 +661,6 @@ Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe-à-Pitre # Pottenger data. The post-1970 entries have been corrected, but the # pre-1970 entries are unchecked and probably have errors. # -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mont 1917 only - Mar 25 2:00 1:00 D Rule Mont 1917 only - Apr 24 0:00 0 S Rule Mont 1919 only - Mar 31 2:30 1:00 D @@ -439,6 +696,48 @@ Zone America/Montreal -4:54:16 - LMT 1884 Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill -4:00 - AST
+# The Bahamas +# +# For 1899 Milne gives -5:09:29.5; round that. +# +# From P Chan (2020-11-27, corrected on 2020-12-02): +# There were two periods of DST observed in 1942-1945: 1942-05-01 +# midnight to 1944-12-31 midnight and 1945-02-01 to 1945-10-17 midnight. +# "midnight" should mean 24:00 from the context. +# +# War Time Order 1942 [1942-05-01] and War Time (No. 2) Order 1942 [1942-09-29] +# Appendix to the Statutes of 7 George VI. and the Year 1942. p 34, 43 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA34 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA43 +# +# War Time Order 1943 [1943-03-31] and War Time Order 1944 [1943-12-29] +# Appendix to the Statutes of 8 George VI. and the Year 1943. p 9-10, 28-29 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA9 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA28 +# +# War Time Order 1945 [1945-01-31] and the Order which revoke War Time Order +# 1945 [1945-10-16] Appendix to the Statutes of 9 George VI. and the Year +# 1945. p 160, 247-248 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA160 +# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA247 +# +# From Sue Williams (2006-12-07): +# The Bahamas announced about a month ago that they plan to change their DST +# rules to sync with the U.S. starting in 2007.... +# http://www.jonesbahamas.com/?c=45&a=10412 + +Rule Bahamas 1942 only - May 1 24:00 1:00 W +Rule Bahamas 1944 only - Dec 31 24:00 0 S +Rule Bahamas 1945 only - Feb 1 0:00 1:00 W +Rule Bahamas 1945 only - Aug 14 23:00u 1:00 P # Peace +Rule Bahamas 1945 only - Oct 17 24:00 0 S +Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S +Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D + +Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 + -5:00 Bahamas E%sT 1976 + -5:00 US E%sT + # United States # # From Paul Eggert (2018-03-18): @@ -463,6 +762,13 @@ Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill # https://cdnc.ucr.edu/cgi-bin/cdnc?a=d&d=DS19470110 # front page reports on end.
+# Trinidad and Tobago +Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 + -4:00 - AST +Link America/Port_of_Spain America/Marigot +Link America/Port_of_Spain America/St_Barthelemy +Link America/Port_of_Spain America/Virgin + # Argentina # This entry was intended for the following areas, but has been superseded by # more detailed zones. @@ -486,7 +792,7 @@ Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries -4:04:00 - CMT 1912 # Castries Mean Time -4:00 - AST
-# Virgin Is +# US Virgin Is Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie -4:00 - AST
@@ -499,11 +805,65 @@ Zone America/St_Vincent -4:04:56 - LMT 1890 # Kingstown Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town -4:00 - AST
+# Dumont d'Urville, Île des Pétrels, -6640+14001, since 1956-11 +# <https://en.wikipedia.org/wiki/Dumont_d'Urville_Station> (2005-12-05) +# +# Another base at Port-Martin, 50km east, began operation in 1947. +# It was destroyed by fire on 1952-01-14. +# +Zone Antarctica/DumontDUrville 0 - -00 1947 + 10:00 - +10 1952 Jan 14 + 0 - -00 1956 Nov + 10:00 - +10 + # McMurdo, Ross Island, since 1955-12 Zone Antarctica/McMurdo 0 - -00 1956 12:00 NZ NZ%sT Link Antarctica/McMurdo Antarctica/South_Pole
+# Syowa, Antarctica +# +# From Hideyuki Suzuki (1999-02-06): +# In all Japanese stations, +0300 is used as the standard time. +# +# Syowa station, which is the first antarctic station of Japan, +# was established on 1957-01-29. Since Syowa station is still the main +# station of Japan, it's appropriate for the principal location. +Zone Antarctica/Syowa 0 - -00 1957 Jan 29 + 3:00 - +03 +# See: +# NIPR Antarctic Research Activities (1999-08-17) +# http://www.nipr.ac.jp/english/ara01.html + +# Vostok, Antarctica +# +# Vostok, since 1957-12-16, temporarily closed 1994-02/1994-11 +# From Craig Mundell (1994-12-15): +# http://quest.arc.nasa.gov/antarctica/QA/computers/Directions,Time,ZIP +# Vostok, which is one of the Russian stations, is set on the same +# time as Moscow, Russia. +# +# From Lee Hotz (2001-03-08): +# I queried the folks at Columbia who spent the summer at Vostok and this is +# what they had to say about time there: +# "in the US Camp (East Camp) we have been on New Zealand (McMurdo) +# time, which is 12 hours ahead of GMT. The Russian Station Vostok was +# 6 hours behind that (although only 2 miles away, i.e. 6 hours ahead +# of GMT). This is a time zone I think two hours east of Moscow. The +# natural time zone is in between the two: 8 hours ahead of GMT." +# +# From Paul Eggert (2001-05-04): +# This seems to be hopelessly confusing, so I asked Lee Hotz about it +# in person. He said that some Antarctic locations set their local +# time so that noon is the warmest part of the day, and that this +# changes during the year and does not necessarily correspond to mean +# solar noon. So the Vostok time might have been whatever the clocks +# happened to be during their visit. So we still don't really know what time +# it is at Vostok. But we'll guess +06. +# +Zone Antarctica/Vostok 0 - -00 1957 Dec 16 + 6:00 - +06 + # Yemen # Milne says 2:59:54 was the meridian of the saluting battery at Aden, # and that Yemen was at 1:55:56, the meridian of the Hagia Sophia. @@ -542,6 +902,16 @@ Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah 4:00 - +04 1972 Jun 3:00 - +03
+# Thailand +Zone Asia/Bangkok 6:42:04 - LMT 1880 + 6:42:04 - BMT 1920 Apr # Bangkok Mean Time + 7:00 - +07 + +# Brunei +Zone Asia/Brunei 7:39:40 - LMT 1926 Mar # Bandar Seri Begawan + 7:30 - +0730 1933 + 8:00 - +08 + # India # # From Paul Eggert (2014-09-06): @@ -567,6 +937,10 @@ Zone Asia/Chongqing 7:06:20 - LMT 1928 # or Chungking 8:00 PRC C%sT Link Asia/Chongqing Asia/Chungking
+# United Arab Emirates +Zone Asia/Dubai 3:41:12 - LMT 1920 + 4:00 - +04 + # Vietnam # From Paul Eggert (2014-10-13): # See Asia/Ho_Chi_Minh for the source for this data. @@ -597,6 +971,32 @@ Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:00 - +05 1980 May 8:00 PRC C%sT
+# peninsular Malaysia +# taken from Mok Ly Yng (2003-10-30) +# https://web.archive.org/web/20190822231045/http://www.math.nus.edu.sg/~mathe... +# This agrees with Singapore since 1905-06-01. +Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 + 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. + 7:00 - +07 1933 Jan 1 + 7:00 0:20 +0720 1936 Jan 1 + 7:20 - +0720 1941 Sep 1 + 7:30 - +0730 1942 Feb 16 + 9:00 - +09 1945 Sep 12 + 7:30 - +0730 1982 Jan 1 + 8:00 - +08 +# +# Sabah & Sarawak +# From Paul Eggert (2014-08-12): +# The data entries here are mostly from Shanks & Pottenger, but the 1942, 1945 +# and 1982 transition dates are from Mok Ly Yng. +Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 - +Rule NBorneo 1935 1941 - Dec 14 0:00 0 - +Zone Asia/Kuching 7:21:20 - LMT 1926 Mar + 7:30 - +0730 1933 + 8:00 NBorneo +08/+0820 1942 Feb 16 + 9:00 - +09 1945 Sep 12 + 8:00 - +08 + # Kuwait Zone Asia/Kuwait 3:11:56 - LMT 1950 3:00 - +03 @@ -646,11 +1046,118 @@ Zone Asia/Phnom_Penh 6:59:40 - LMT 1906 Jul 1 9:00 - +09 1945 Sep 2 7:00 - +07
+# Saudi Arabia +# +# From Paul Eggert (2018-08-29): +# Time in Saudi Arabia and other countries in the Arabian peninsula was not +# standardized until 1968 or so; we don't know exactly when, and possibly it +# has never been made official. Richard P Hunt, in "Islam city yielding to +# modern times", New York Times (1961-04-09), p 20, wrote that only airlines +# observed standard time, and that people in Jeddah mostly observed quasi-solar +# time, doing so by setting their watches at sunrise to 6 o'clock (or to 12 +# o'clock for "Arab" time). +# +# Timekeeping differed depending on who you were and which part of Saudi +# Arabia you were in. In 1969, Elias Antar wrote that although a common +# practice had been to set one's watch to 12:00 (i.e., midnight) at sunset - +# which meant that the time on one side of a mountain could differ greatly from +# the time on the other side - many foreigners set their watches to 6pm +# instead, while airlines instead used UTC +03 (except in Dhahran, where they +# used UTC +04), Aramco used UTC +03 with DST, and the Trans-Arabian Pipe Line +# Company used Aramco time in eastern Saudi Arabia and airline time in western. +# (The American Military Aid Advisory Group used plain UTC.) Antar writes, +# "A man named Higgins, so the story goes, used to run a local power +# station. One day, the whole thing became too much for Higgins and he +# assembled his staff and laid down the law. 'I've had enough of this,' he +# shrieked. 'It is now 12 o'clock Higgins Time, and from now on this station is +# going to run on Higgins Time.' And so, until last year, it did." See: +# Antar E. Dinner at When? Saudi Aramco World, 1969 March/April. 2-3. +# http://archive.aramcoworld.com/issue/196902/dinner.at.when.htm +# Also see: Antar EN. Arabian flying is confusing. +# Port Angeles (WA) Evening News. 1965-03-10. page 3. +# +# The TZ database cannot represent quasi-solar time; airline time is the best +# we can do. The 1946 foreign air news digest of the U.S. Civil Aeronautics +# Board (OCLC 42299995) reported that the "... Arabian Government, inaugurated +# a weekly Dhahran-Cairo service, via the Saudi Arabian cities of Riyadh and +# Jidda, on March 14, 1947". Shanks & Pottenger guessed 1950; go with the +# earlier date. +# +# Shanks & Pottenger also state that until 1968-05-01 Saudi Arabia had two +# time zones; the other zone, at UT +04, was in the far eastern part of +# the country. Presumably this is documenting airline time. Ignore this, +# as it's before our 1970 cutoff. +# +Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 + 3:00 - +03 + + # Israel Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 2:21 - JMT 1918 2:00 Zion I%sT
+ +# Xinjiang + +# From Luther Ma (2009-11-19): +# It seems that Uyghurs in Ürümqi has been using Xinjiang since at least the +# 1960's. I know of one Han, now over 50, who grew up in the surrounding +# countryside and used Xinjiang time as a child. +# +# 6. Likewise for Kashgar and the rest of south Xinjiang I don't know of any +# start date for Xinjiang time. +# +# Without having access to local historical records, nor the ability to legally +# publish them, I would go with October 1, 1949, when Xinjiang became the Uyghur +# Autonomous Region under the PRC. (Before that Uyghurs, of course, would also +# not be using Beijing time, but some local time.) + +# From David Cochrane (2014-03-26): +# Just a confirmation that Ürümqi time was implemented in Ürümqi on 1 Feb 1986: +# https://content.time.com/time/magazine/article/0,9171,960684,00.html + +# From Luther Ma (2014-04-22): +# I have interviewed numerous people of various nationalities and from +# different localities in Xinjiang and can confirm the information in Guo's +# report regarding Xinjiang, as well as the Time article reference by David +# Cochrane. Whether officially recognized or not (and both are officially +# recognized), two separate times have been in use in Xinjiang since at least +# the Cultural Revolution: Xinjiang Time (XJT), aka Ürümqi Time or local time; +# and Beijing Time. There is no confusion in Xinjiang as to which name refers +# to which time. Both are widely used in the province, although in some +# population groups might be use one to the exclusion of the other. The only +# problem is that computers and smart phones list Ürümqi (or Kashgar) as +# having the same time as Beijing. + +# From Paul Eggert (2014-06-30): +# In the early days of the PRC, Tibet was given its own time zone (UT +06) +# but this was withdrawn in 1959 and never reinstated; see Tubten Khétsun, +# Memories of life in Lhasa under Chinese Rule, Columbia U Press, ISBN +# 978-0231142861 (2008), translator's introduction by Matthew Akester, p x. +# As this is before our 1970 cutoff, Tibet doesn't need a separate zone. +# +# Xinjiang Time is well-documented as being officially recognized. E.g., see +# "The Working-Calendar for The Xinjiang Uygur Autonomous Region Government" +# <http://www.sinkiang.gov.cn/service/ourworking/> (2014-04-22). +# Unfortunately, we have no good records of time in Xinjiang before 1986. +# During the 20th century parts of Xinjiang were ruled by the Qing dynasty, +# the Republic of China, various warlords, the First and Second East Turkestan +# Republics, the Soviet Union, the Kuomintang, and the People's Republic of +# China, and tracking down all these organizations' timekeeping rules would be +# quite a trick. Approximate this lost history by a transition from LMT to +# UT +06 at the start of 1928, the year of accession of the warlord Jin Shuren, +# which happens to be the date given by Shanks & Pottenger (no doubt as a +# guess) as the transition from LMT. Ignore the usage of +08 before +# 1986-02-01 under the theory that the transition date to +08 is unknown and +# that the sort of users who prefer Etc/GMT-6 now typically ignored the +# +08 mandate back then. + +# Xinjiang time, used by many in western China; represented by Ürümqi / Ürümchi +# / Wulumuqi. (Please use Asia/Shanghai if you prefer Beijing time.) +Zone Asia/Urumqi 5:50:20 - LMT 1928 + 6:00 - +06 + # Laos # From Paul Eggert (2014-10-11): # See Asia/Ho_Chi_Minh for the source for most of this data. @@ -670,6 +1177,68 @@ Zone Asia/Vientiane 6:50:24 - LMT 1906 Jul 1 # From Whitman: Zone Atlantic/Jan_Mayen -1:00 - -01
+# Iceland +# +# From Adam David (1993-11-06): +# The name of the timezone in Iceland for system / mail / news purposes is GMT. +# +# (1993-12-05): +# This material is paraphrased from the 1988 edition of the University of +# Iceland Almanak. +# +# From January 1st, 1908 the whole of Iceland was standardised at 1 hour +# behind GMT. Previously, local mean solar time was used in different parts +# of Iceland, the almanak had been based on Reykjavík mean solar time which +# was 1 hour and 28 minutes behind GMT. +# +# "first day of winter" referred to [below] means the first day of the 26 weeks +# of winter, according to the old icelandic calendar that dates back to the +# time the norsemen first settled Iceland. The first day of winter is always +# Saturday, but is not dependent on the Julian or Gregorian calendars. +# +# (1993-12-10): +# I have a reference from the Oxford Icelandic-English dictionary for the +# beginning of winter, which ties it to the ecclesiastical calendar (and thus +# to the julian/gregorian calendar) over the period in question. +# the winter begins on the Saturday next before St. Luke's day +# (old style), or on St. Luke's day, if a Saturday. +# St. Luke's day ought to be traceable from ecclesiastical sources. "old style" +# might be a reference to the Julian calendar as opposed to Gregorian, or it +# might mean something else (???). +# +# From Paul Eggert (2014-11-22): +# The information below is taken from the 1988 Almanak; see +# http://www.almanak.hi.is/klukkan.html +# +Rule Iceland 1917 1919 - Feb 19 23:00 1:00 - +Rule Iceland 1917 only - Oct 21 1:00 0 - +Rule Iceland 1918 1919 - Nov 16 1:00 0 - +Rule Iceland 1921 only - Mar 19 23:00 1:00 - +Rule Iceland 1921 only - Jun 23 1:00 0 - +Rule Iceland 1939 only - Apr 29 23:00 1:00 - +Rule Iceland 1939 only - Oct 29 2:00 0 - +Rule Iceland 1940 only - Feb 25 2:00 1:00 - +Rule Iceland 1940 1941 - Nov Sun>=2 1:00s 0 - +Rule Iceland 1941 1942 - Mar Sun>=2 1:00s 1:00 - +# 1943-1946 - first Sunday in March until first Sunday in winter +Rule Iceland 1943 1946 - Mar Sun>=1 1:00s 1:00 - +Rule Iceland 1942 1948 - Oct Sun>=22 1:00s 0 - +# 1947-1967 - first Sunday in April until first Sunday in winter +Rule Iceland 1947 1967 - Apr Sun>=1 1:00s 1:00 - +# 1949 and 1967 Oct transitions delayed by 1 week +Rule Iceland 1949 only - Oct 30 1:00s 0 - +Rule Iceland 1950 1966 - Oct Sun>=22 1:00s 0 - +Rule Iceland 1967 only - Oct 29 1:00s 0 - + +Zone Atlantic/Reykjavik -1:28 - LMT 1908 + -1:00 Iceland -01/+00 1968 Apr 7 1:00s + 0:00 - GMT +Link Atlantic/Reykjavik Iceland + +# South Georgia +Zone Atlantic/South_Georgia -2:26:08 - LMT 1890 # Grytviken + -2:00 - -02 + # St Helena Zone Atlantic/St_Helena -0:22:48 - LMT 1890 # Jamestown -0:22:48 - JMT 1951 # Jamestown Mean Time @@ -681,6 +1250,85 @@ Zone Australia/Currie 9:35:28 - LMT 1895 Sep 10:00 Aus AE%sT 1968 Oct 15 10:00 AT AE%sT
+ +# Netherlands + +# Howse writes that the Netherlands' railways used GMT between 1892 and 1940, +# but for other purposes the Netherlands used Amsterdam mean time. + +# However, Robert H. van Gent writes (2001-04-01): +# Howse's statement is only correct up to 1909. From 1909-05-01 (00:00:00 +# Amsterdam mean time) onwards, the whole of the Netherlands (including +# the Dutch railways) was required by law to observe Amsterdam mean time +# (19 minutes 32.13 seconds ahead of GMT). This had already been the +# common practice (except for the railways) for many decades but it was +# not until 1909 when the Dutch government finally defined this by law. +# On 1937-07-01 this was changed to 20 minutes (exactly) ahead of GMT and +# was generally known as Dutch Time ("Nederlandse Tijd"). +# +# (2001-04-08): +# 1892-05-01 was the date when the Dutch railways were by law required to +# observe GMT while the remainder of the Netherlands adhered to the common +# practice of following Amsterdam mean time. +# +# (2001-04-09): +# In 1835 the authorities of the province of North Holland requested the +# municipal authorities of the towns and cities in the province to observe +# Amsterdam mean time but I do not know in how many cases this request was +# actually followed. +# +# From 1852 onwards the Dutch telegraph offices were by law required to +# observe Amsterdam mean time. As the time signals from the observatory of +# Leiden were also distributed by the telegraph system, I assume that most +# places linked up with the telegraph (and railway) system automatically +# adopted Amsterdam mean time. +# +# Although the early Dutch railway companies initially observed a variety +# of times, most of them had adopted Amsterdam mean time by 1858 but it +# was not until 1866 when they were all required by law to observe +# Amsterdam mean time. + +# The data entries before 1945 are taken from +# https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm + +# From Paul Eggert (2021-05-09): +# I invented the abbreviations AMT for Amsterdam Mean Time and NST for +# Netherlands Summer Time, used in the Netherlands from 1835 to 1937. + +Rule Neth 1916 only - May 1 0:00 1:00 NST # Netherlands Summer Time +Rule Neth 1916 only - Oct 1 0:00 0 AMT # Amsterdam Mean Time +Rule Neth 1917 only - Apr 16 2:00s 1:00 NST +Rule Neth 1917 only - Sep 17 2:00s 0 AMT +Rule Neth 1918 1921 - Apr Mon>=1 2:00s 1:00 NST +Rule Neth 1918 1921 - Sep lastMon 2:00s 0 AMT +Rule Neth 1922 only - Mar lastSun 2:00s 1:00 NST +Rule Neth 1922 1936 - Oct Sun>=2 2:00s 0 AMT +Rule Neth 1923 only - Jun Fri>=1 2:00s 1:00 NST +Rule Neth 1924 only - Mar lastSun 2:00s 1:00 NST +Rule Neth 1925 only - Jun Fri>=1 2:00s 1:00 NST +# From 1926 through 1939 DST began 05-15, except that it was delayed by a week +# in years when 05-15 fell in the Pentecost weekend. +Rule Neth 1926 1931 - May 15 2:00s 1:00 NST +Rule Neth 1932 only - May 22 2:00s 1:00 NST +Rule Neth 1933 1936 - May 15 2:00s 1:00 NST +Rule Neth 1937 only - May 22 2:00s 1:00 NST +Rule Neth 1937 only - Jul 1 0:00 1:00 S +Rule Neth 1937 1939 - Oct Sun>=2 2:00s 0 - +Rule Neth 1938 1939 - May 15 2:00s 1:00 S +Rule Neth 1945 only - Apr 2 2:00s 1:00 S +Rule Neth 1945 only - Sep 16 2:00s 0 - +# +# Amsterdam Mean Time was +00:19:32.13, but the .13 is omitted +# below because the current format requires STDOFF to be an integer. +# +Zone Europe/Amsterdam 0:19:32 - LMT 1835 + 0:19:32 Neth %s 1937 Jul 1 + 0:20 Neth +0020/+0120 1940 May 16 0:00 + 1:00 C-Eur CE%sT 1945 Apr 2 2:00 + 1:00 Neth CE%sT 1977 + 1:00 EU CE%sT + + # Northern Ireland Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 @@ -692,6 +1340,60 @@ Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 0:00 GB-Eire %s 1996 0:00 EU GMT/BST
+ +# Denmark + +# From Jesper Nørgaard Welen (2005-04-26): +# the law [introducing standard time] was in effect from 1894-01-01.... +# The page https://www.retsinformation.dk/eli/lta/1893/83 +# confirms this, and states that the law was put forth 1893-03-29. +# +# The EU [actually, EEC and Euratom] treaty with effect from 1973: +# https://www.retsinformation.dk/eli/lta/1972/21100 +# +# This provoked a new law from 1974 to make possible summer time changes +# in subsequent decrees with the law +# https://www.retsinformation.dk/eli/lta/1974/223 +# +# It seems however that no decree was set forward until 1980. I have +# not found any decree, but in another related law, the effecting DST +# changes are stated explicitly to be from 1980-04-06 at 02:00 to +# 1980-09-28 at 02:00. If this is true, this differs slightly from +# the EU rule in that DST runs to 02:00, not 03:00. We don't know +# when Denmark began using the EU rule correctly, but we have only +# confirmation of the 1980-time, so I presume it was correct in 1981: +# The law is about the management of the extra hour, concerning +# working hours reported and effect on obligatory-rest rules (which +# was suspended on that night): +# https://web.archive.org/web/20140104053304/https://www.retsinformation.dk/Fo... + +# From Jesper Nørgaard Welen (2005-06-11): +# The Herning Folkeblad (1980-09-26) reported that the night between +# Saturday and Sunday the clock is set back from three to two. + +# From Paul Eggert (2005-06-11): +# Hence the "02:00" of the 1980 law refers to standard time, not +# wall-clock time, and so the EU rules were in effect in 1980. + +Rule Denmark 1916 only - May 14 23:00 1:00 S +Rule Denmark 1916 only - Sep 30 23:00 0 - +Rule Denmark 1940 only - May 15 0:00 1:00 S +Rule Denmark 1945 only - Apr 2 2:00s 1:00 S +Rule Denmark 1945 only - Aug 15 2:00s 0 - +Rule Denmark 1946 only - May 1 2:00s 1:00 S +Rule Denmark 1946 only - Sep 1 2:00s 0 - +Rule Denmark 1947 only - May 4 2:00s 1:00 S +Rule Denmark 1947 only - Aug 10 2:00s 0 - +Rule Denmark 1948 only - May 9 2:00s 1:00 S +Rule Denmark 1948 only - Aug 8 2:00s 0 - +# +Zone Europe/Copenhagen 0:50:20 - LMT 1890 + 0:50:20 - CMT 1894 Jan 1 # Copenhagen MT + 1:00 Denmark CE%sT 1942 Nov 2 2:00s + 1:00 C-Eur CE%sT 1945 Apr 2 2:00 + 1:00 Denmark CE%sT 1980 + 1:00 EU CE%sT + # Guernsey # Data from Joseph S. Myers # https://mm.icann.org/pipermail/tz/2013-September/019883.html @@ -747,6 +1449,85 @@ Zone Europe/Ljubljana 0:58:04 - LMT 1884 1:00 - CET 1982 Nov 27 1:00 EU CE%sT
+ +# Luxembourg + +# Whitman disagrees with most of these dates in minor ways; +# go with Shanks & Pottenger. +Rule Lux 1916 only - May 14 23:00 1:00 S +Rule Lux 1916 only - Oct 1 1:00 0 - +Rule Lux 1917 only - Apr 28 23:00 1:00 S +Rule Lux 1917 only - Sep 17 1:00 0 - +Rule Lux 1918 only - Apr Mon>=15 2:00s 1:00 S +Rule Lux 1918 only - Sep Mon>=15 2:00s 0 - +Rule Lux 1919 only - Mar 1 23:00 1:00 S +Rule Lux 1919 only - Oct 5 3:00 0 - +Rule Lux 1920 only - Feb 14 23:00 1:00 S +Rule Lux 1920 only - Oct 24 2:00 0 - +Rule Lux 1921 only - Mar 14 23:00 1:00 S +Rule Lux 1921 only - Oct 26 2:00 0 - +Rule Lux 1922 only - Mar 25 23:00 1:00 S +Rule Lux 1922 only - Oct Sun>=2 1:00 0 - +Rule Lux 1923 only - Apr 21 23:00 1:00 S +Rule Lux 1923 only - Oct Sun>=2 2:00 0 - +Rule Lux 1924 only - Mar 29 23:00 1:00 S +Rule Lux 1924 1928 - Oct Sun>=2 1:00 0 - +Rule Lux 1925 only - Apr 5 23:00 1:00 S +Rule Lux 1926 only - Apr 17 23:00 1:00 S +Rule Lux 1927 only - Apr 9 23:00 1:00 S +Rule Lux 1928 only - Apr 14 23:00 1:00 S +Rule Lux 1929 only - Apr 20 23:00 1:00 S + +Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun + 1:00 Lux CE%sT 1918 Nov 25 + 0:00 Lux WE%sT 1929 Oct 6 2:00s + 0:00 Belgium WE%sT 1940 May 14 3:00 + 1:00 C-Eur WE%sT 1944 Sep 18 3:00 + 1:00 Belgium CE%sT 1977 + 1:00 EU CE%sT + +# Monaco +# +# From Michael Deckers (2020-06-12): +# In the "Journal de Monaco" of 1892-05-24, online at +# https://journaldemonaco.gouv.mc/var/jdm/storage/original/application/b1c67c1... +# we read: ... +# [In virtue of a Sovereign Ordinance of the May 13 of the current [year], +# legal time in the Principality will be set to, from the date of June 1, +# 1892 onwards, to the meridian of Paris, as in France.] +# In the "Journal de Monaco" of 1911-03-28, online at +# https://journaldemonaco.gouv.mc/var/jdm/storage/original/application/de74ffb... +# we read an ordinance of 1911-03-16: ... +# [Legal time in the Principality will be set, from the date of promulgation +# of the present ordinance, to legal time in France.... Consequently, legal +# time will be retarded by 9 minutes and 21 seconds.] +# +Zone Europe/Monaco 0:29:32 - LMT 1892 Jun 1 + 0:09:21 - PMT 1911 Mar 29 # Paris Mean Time + 0:00 France WE%sT 1945 Sep 16 3:00 + 1:00 France CE%sT 1977 + 1:00 EU CE%sT + + +# Norway + +# http://met.no/met/met_lex/q_u/sommertid.html (2004-01) agrees with Shanks & +# Pottenger. +Rule Norway 1916 only - May 22 1:00 1:00 S +Rule Norway 1916 only - Sep 30 0:00 0 - +Rule Norway 1945 only - Apr 2 2:00s 1:00 S +Rule Norway 1945 only - Oct 1 2:00s 0 - +Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S +Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 - +Rule Norway 1965 only - Apr 25 2:00s 1:00 S + +Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 + 1:00 Norway CE%sT 1940 Aug 10 23:00 + 1:00 C-Eur CE%sT 1945 Apr 2 2:00 + 1:00 Norway CE%sT 1980 + 1:00 EU CE%sT +Link Europe/Oslo Arctic/Longyearbyen + # Bosnia and Herzegovina Zone Europe/Sarajevo 1:13:40 - LMT 1884 1:00 - CET 1941 Apr 18 23:00 @@ -763,6 +1544,64 @@ Zone Europe/Skopje 1:25:44 - LMT 1884 1:00 - CET 1982 Nov 27 1:00 EU CE%sT
+ +# Sweden + +# From Ivan Nilsson (2001-04-13), superseding Shanks & Pottenger: +# +# The law "Svensk författningssamling 1878, no 14" about standard time in 1879: +# From the beginning of 1879 (that is 01-01 00:00) the time for all +# places in the country is "the mean solar time for the meridian at +# three degrees, or twelve minutes of time, to the west of the +# meridian of the Observatory of Stockholm". The law is dated 1878-05-31. +# +# The observatory at that time had the meridian 18° 03' 30" +# eastern longitude = 01:12:14 in time. Less 12 minutes gives the +# national standard time as 01:00:14 ahead of GMT.... +# +# About the beginning of CET in Sweden. The lawtext ("Svensk +# författningssamling 1899, no 44") states, that "from the beginning +# of 1900... ... the same as the mean solar time for the meridian at +# the distance of one hour of time from the meridian of the English +# observatory at Greenwich, or at 12 minutes 14 seconds to the west +# from the meridian of the Observatory of Stockholm". The law is dated +# 1899-06-16. In short: At 1900-01-01 00:00:00 the new standard time +# in Sweden is 01:00:00 ahead of GMT. +# +# 1916: The lawtext ("Svensk författningssamling 1916, no 124") states +# that "1916-05-15 is considered to begin one hour earlier". It is +# pretty obvious that at 05-14 23:00 the clocks are set to 05-15 00:00.... +# Further the law says, that "1916-09-30 is considered to end one hour later". +# +# The laws regulating [DST] are available on the site of the Swedish +# Parliament beginning with 1985 - the laws regulating 1980/1984 are +# not available on the site (to my knowledge they are only available +# in Swedish): <http://www.riksdagen.se/english/work/sfst.asp> (type +# "sommartid" without the quotes in the field "Fritext" and then click +# the Sök-button). +# +# (2001-05-13): +# +# I have now found a newspaper stating that at 1916-10-01 01:00 +# summertime the church-clocks etc were set back one hour to show +# 1916-10-01 00:00 standard time. The article also reports that some +# people thought the switch to standard time would take place already +# at 1916-10-01 00:00 summer time, but they had to wait for another +# hour before the event took place. +# +# Source: The newspaper "Dagens Nyheter", 1916-10-01, page 7 upper left. + +# An extra-special abbreviation style is SET for Swedish Time (svensk +# normaltid) 1879-1899, 3° west of the Stockholm Observatory. + +Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 + 1:00:14 - SET 1900 Jan 1 # Swedish Time + 1:00 - CET 1916 May 14 23:00 + 1:00 1:00 CEST 1916 Oct 1 1:00 + 1:00 - CET 1980 + 1:00 EU CE%sT + + # Moldova / Transnistria Zone Europe/Tiraspol 1:58:32 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT @@ -793,18 +1632,118 @@ Zone Indian/Antananarivo 3:10:04 - LMT 1911 Jul 3:00 1:00 EAST 1954 May 29 23:00s 3:00 - EAT
+# Christmas +Zone Indian/Christmas 7:02:52 - LMT 1895 Feb + 7:00 - +07 + +# Cocos (Keeling) Is +# These islands were ruled by the Ross family from about 1830 to 1978. +# We don't know when standard time was introduced; for now, we guess 1900. +Zone Indian/Cocos 6:27:40 - LMT 1900 + 6:30 - +0630 + # Comoros Zone Indian/Comoro 2:53:04 - LMT 1911 Jul # Moroni, Gran Comoro 3:00 - EAT
+# Kerguelen +Zone Indian/Kerguelen 0 - -00 1950 # Port-aux-Français + 5:00 - +05 + +# Seychelles +# +# From P Chan (2020-11-27): +# Standard Time was adopted on 1907-01-01. +# +# Standard Time Ordinance (Chapter 237) +# The Laws of Seychelles in Force on the 31st December, 1971, Vol. 6, p 571 +# https://books.google.com/books?id=efE-AQAAIAAJ&pg=PA571 +# +# From Tim Parenti (2020-12-05): +# A footnote on https://books.google.com/books?id=DYdDAQAAMAAJ&pg=PA1689 +# confirms that Ordinance No. 9 of 1906 "was brought into force on the 1st +# January, 1907." + +Zone Indian/Mahe 3:41:48 - LMT 1907 Jan 1 # Victoria + 4:00 - +04 +# From Paul Eggert (2001-05-30): +# Aldabra, Farquhar, and Desroches, originally dependencies of the +# Seychelles, were transferred to the British Indian Ocean Territory +# in 1965 and returned to Seychelles control in 1976. We don't know +# whether this affected their time zone, so omit this for now. +# Possibly the islands were uninhabited. + + +# Maldives +Zone Indian/Maldives 4:54:00 - LMT 1880 # Malé + 4:54:00 - MMT 1960 # Malé Mean Time + 5:00 - +05 + # Mayotte Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou 3:00 - EAT
-# US minor outlying islands +# Réunion +Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis + 4:00 - +04 +# +# Scattered Islands (Îles Éparses) administered from Réunion are as follows. +# The following information about them is taken from +# Îles Éparses (<http://www.outre-mer.gouv.fr/domtom/ile.htm>, 1997-07-22, +# in French; no longer available as of 1999-08-17). +# We have no info about their time zone histories. +# +# Bassas da India - uninhabited +# Europa Island - inhabited from 1905 to 1910 by two families +# Glorioso Is - inhabited until at least 1958 +# Juan de Nova - uninhabited +# Tromelin - inhabited until at least 1958 + +# Micronesia +# Also see commentary for Micronesia in 'australasia'. +# +# From Paul Eggert (2018-11-18): +# Alan Eugene Davis writes (1996-03-16), +# "I am certain, having lived there for the past decade, that 'Truk' +# (now properly known as Chuuk) ... is in the time zone GMT+10." +# Shanks & Pottenger write that Truk switched from UT +10 to +11 +# on 1978-10-01; ignore this for now. +Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 + 10:07:08 - LMT 1901 + 10:00 - +10 1914 Oct + 9:00 - +09 1919 Feb 1 + 10:00 - +10 1941 Apr 1 + 9:00 - +09 1945 Aug + 10:00 - +10 +Link Pacific/Chuuk Pacific/Truk +Link Pacific/Chuuk Pacific/Yap + +# Tuvalu +Zone Pacific/Funafuti 11:56:52 - LMT 1901 + 12:00 - +12 + +# Gambier Islands +Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea + -9:00 - -09 + +# Solomon Islands +Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara + 11:00 - +11 + +# Johnston Zone Pacific/Johnston -10:00 - HST
-# US minor outlying islands +# Marshall Is +Zone Pacific/Majuro 11:24:48 - LMT 1901 + 11:00 - +11 1914 Oct + 9:00 - +09 1919 Feb 1 + 11:00 - +11 1937 + 10:00 - +10 1941 Apr 1 + 9:00 - +09 1944 Jan 30 + 11:00 - +11 1969 Oct + 12:00 - +12 + +# Midway # # From Mark Brader (2005-01-23): # [Fallacies and Fantasies of Air Transport History, by R.E.G. Davies, @@ -821,9 +1760,71 @@ Zone Pacific/Midway -11:49:28 - LMT 1901 -11:00 1:00 -10 1956 Sep 2 -11:00 - -11
+# Palau (Belau) +# See commentary for Micronesia in 'australasia'. +Zone Pacific/Palau -15:02:04 - LMT 1844 Dec 31 # Koror + 8:57:56 - LMT 1901 + 9:00 - +09 + +# Micronesia +# See commentary for Micronesia in 'australasia'. +Zone Pacific/Pohnpei -13:27:08 - LMT 1844 Dec 31 # Kolonia + 10:32:52 - LMT 1901 + 11:00 - +11 1914 Oct + 9:00 - +09 1919 Feb 1 + 11:00 - +11 1937 + 10:00 - +10 1941 Apr 1 + 9:00 - +09 1945 Aug + 11:00 - +11 +Link Pacific/Pohnpei Pacific/Ponape + +# Papua New Guinea +Zone Pacific/Port_Moresby 9:48:40 - LMT 1880 + 9:48:32 - PMMT 1895 # Port Moresby Mean Time + 10:00 - +10 + # N Mariana Is Zone Pacific/Saipan -14:17:00 - LMT 1844 Dec 31 9:43:00 - LMT 1901 9:00 - +09 1969 Oct 10:00 - +10 2000 Dec 23 10:00 - ChST # Chamorro Standard Time + +# Society Islands +Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct # Papeete + -10:00 - -10 + +# Gilbert Islands +Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki + 12:00 - +12 + + +# Wake + +# From Vernice Anderson, Personal Secretary to Philip Jessup, +# US Ambassador At Large (oral history interview, 1971-02-02): +# +# Saturday, the 14th [of October, 1950] - ... The time was all the +# more confusing at that point, because we had crossed the +# International Date Line, thus getting two Sundays. Furthermore, we +# discovered that Wake Island had two hours of daylight saving time +# making calculation of time in Washington difficult if not almost +# impossible. +# +# https://www.trumanlibrary.org/oralhist/andrsonv.htm + +# From Paul Eggert (2003-03-23): +# We have no other report of DST in Wake Island, so omit this info for now. + +# Also see commentary for Micronesia in 'australasia'. +Zone Pacific/Wake 11:06:28 - LMT 1901 + 12:00 - +12 + + +# Wallis and Futuna +Zone Pacific/Wallis 12:15:20 - LMT 1901 + 12:00 - +12 + +# Local Variables: +# coding: utf-8 +# End: diff --git a/checktab.awk b/checktab.awk index d5317ac..5748341 100644 --- a/checktab.awk +++ b/checktab.awk @@ -147,7 +147,7 @@ $1 ~ /^#/ { next } ruleUsed[$2] = 1 if ($3 ~ /%/) rulePercentUsed[$2] = 1 } - if (tz && tz ~ /\//) { + if (tz && tz ~ /\// && tz !~ /^Etc\//) { if (!tztab[tz]) { printf "%s: no data for '%s'\n", zone_table, tz \ >>"/dev/stderr" @@ -171,7 +171,7 @@ END { } } for (tz in tztab) { - if (!zoneSeen[tz]) { + if (!zoneSeen[tz] && tz !~ /^Etc\//) { printf "%s:%d: no Zone table for '%s'\n", \ zone_table, tz2NR[tz], tz >>"/dev/stderr" status = 1 diff --git a/etcetera b/etcetera index 1dc7411..dc21c4d 100644 --- a/etcetera +++ b/etcetera @@ -12,6 +12,8 @@ # Starting with POSIX 1003.1-2001, the entries below are all # unnecessary as settings for the TZ environment variable. E.g., # instead of TZ='Etc/GMT+4' one can use the POSIX setting TZ='<-04>+4'. +# However, some entries are needed if 'backward' is used: +# for example, the 'backward' file links Etc/GMT to Africa/Abidjan. # # Do not use a POSIX TZ setting like TZ='GMT+4', which is four hours # behind GMT but uses the completely misleading abbreviation "GMT". diff --git a/europe b/europe index 9e73fa9..b9289d3 100644 --- a/europe +++ b/europe @@ -68,7 +68,6 @@ # 0:00 GMT BST BDST Greenwich, British Summer # 0:00 GMT IST Greenwich, Irish Summer # 0:00 WET WEST WEMT Western Europe -# 0:19:32.13 AMT* NST* Amsterdam, Netherlands Summer (1835-1937) # 1:00 BST British Standard (1968-1971) # 1:00 IST GMT Irish Standard (1968-) with winter DST # 1:00 CET CEST CEMT Central Europe @@ -1024,59 +1023,8 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # Use Europe/Prague also for Slovakia.
# Denmark, Faroe Islands, and Greenland +# For Denmark see Europe/Berlin.
-# From Jesper Nørgaard Welen (2005-04-26): -# the law [introducing standard time] was in effect from 1894-01-01.... -# The page https://www.retsinformation.dk/eli/lta/1893/83 -# confirms this, and states that the law was put forth 1893-03-29. -# -# The EU [actually, EEC and Euratom] treaty with effect from 1973: -# https://www.retsinformation.dk/eli/lta/1972/21100 -# -# This provoked a new law from 1974 to make possible summer time changes -# in subsequent decrees with the law -# https://www.retsinformation.dk/eli/lta/1974/223 -# -# It seems however that no decree was set forward until 1980. I have -# not found any decree, but in another related law, the effecting DST -# changes are stated explicitly to be from 1980-04-06 at 02:00 to -# 1980-09-28 at 02:00. If this is true, this differs slightly from -# the EU rule in that DST runs to 02:00, not 03:00. We don't know -# when Denmark began using the EU rule correctly, but we have only -# confirmation of the 1980-time, so I presume it was correct in 1981: -# The law is about the management of the extra hour, concerning -# working hours reported and effect on obligatory-rest rules (which -# was suspended on that night): -# https://web.archive.org/web/20140104053304/https://www.retsinformation.dk/Fo... - -# From Jesper Nørgaard Welen (2005-06-11): -# The Herning Folkeblad (1980-09-26) reported that the night between -# Saturday and Sunday the clock is set back from three to two. - -# From Paul Eggert (2005-06-11): -# Hence the "02:00" of the 1980 law refers to standard time, not -# wall-clock time, and so the EU rules were in effect in 1980. - -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Denmark 1916 only - May 14 23:00 1:00 S -Rule Denmark 1916 only - Sep 30 23:00 0 - -Rule Denmark 1940 only - May 15 0:00 1:00 S -Rule Denmark 1945 only - Apr 2 2:00s 1:00 S -Rule Denmark 1945 only - Aug 15 2:00s 0 - -Rule Denmark 1946 only - May 1 2:00s 1:00 S -Rule Denmark 1946 only - Sep 1 2:00s 0 - -Rule Denmark 1947 only - May 4 2:00s 1:00 S -Rule Denmark 1947 only - Aug 10 2:00s 0 - -Rule Denmark 1948 only - May 9 2:00s 1:00 S -Rule Denmark 1948 only - Aug 8 2:00s 0 - -# -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Copenhagen 0:50:20 - LMT 1890 - 0:50:20 - CMT 1894 Jan 1 # Copenhagen MT - 1:00 Denmark CE%sT 1942 Nov 2 2:00s - 1:00 C-Eur CE%sT 1945 Apr 2 2:00 - 1:00 Denmark CE%sT 1980 - 1:00 EU CE%sT Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn 0:00 - WET 1981 0:00 EU WE%sT @@ -1621,62 +1569,7 @@ Zone Europe/Budapest 1:16:20 - LMT 1890 Nov 1 1:00 EU CE%sT
# Iceland -# -# From Adam David (1993-11-06): -# The name of the timezone in Iceland for system / mail / news purposes is GMT. -# -# (1993-12-05): -# This material is paraphrased from the 1988 edition of the University of -# Iceland Almanak. -# -# From January 1st, 1908 the whole of Iceland was standardised at 1 hour -# behind GMT. Previously, local mean solar time was used in different parts -# of Iceland, the almanak had been based on Reykjavík mean solar time which -# was 1 hour and 28 minutes behind GMT. -# -# "first day of winter" referred to [below] means the first day of the 26 weeks -# of winter, according to the old icelandic calendar that dates back to the -# time the norsemen first settled Iceland. The first day of winter is always -# Saturday, but is not dependent on the Julian or Gregorian calendars. -# -# (1993-12-10): -# I have a reference from the Oxford Icelandic-English dictionary for the -# beginning of winter, which ties it to the ecclesiastical calendar (and thus -# to the julian/gregorian calendar) over the period in question. -# the winter begins on the Saturday next before St. Luke's day -# (old style), or on St. Luke's day, if a Saturday. -# St. Luke's day ought to be traceable from ecclesiastical sources. "old style" -# might be a reference to the Julian calendar as opposed to Gregorian, or it -# might mean something else (???). -# -# From Paul Eggert (2014-11-22): -# The information below is taken from the 1988 Almanak; see -# http://www.almanak.hi.is/klukkan.html -# -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Iceland 1917 1919 - Feb 19 23:00 1:00 - -Rule Iceland 1917 only - Oct 21 1:00 0 - -Rule Iceland 1918 1919 - Nov 16 1:00 0 - -Rule Iceland 1921 only - Mar 19 23:00 1:00 - -Rule Iceland 1921 only - Jun 23 1:00 0 - -Rule Iceland 1939 only - Apr 29 23:00 1:00 - -Rule Iceland 1939 only - Oct 29 2:00 0 - -Rule Iceland 1940 only - Feb 25 2:00 1:00 - -Rule Iceland 1940 1941 - Nov Sun>=2 1:00s 0 - -Rule Iceland 1941 1942 - Mar Sun>=2 1:00s 1:00 - -# 1943-1946 - first Sunday in March until first Sunday in winter -Rule Iceland 1943 1946 - Mar Sun>=1 1:00s 1:00 - -Rule Iceland 1942 1948 - Oct Sun>=22 1:00s 0 - -# 1947-1967 - first Sunday in April until first Sunday in winter -Rule Iceland 1947 1967 - Apr Sun>=1 1:00s 1:00 - -# 1949 and 1967 Oct transitions delayed by 1 week -Rule Iceland 1949 only - Oct 30 1:00s 0 - -Rule Iceland 1950 1966 - Oct Sun>=22 1:00s 0 - -Rule Iceland 1967 only - Oct 29 1:00s 0 - -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Atlantic/Reykjavik -1:28 - LMT 1908 - -1:00 Iceland -01/+00 1968 Apr 7 1:00s - 0:00 - GMT +# See Etc/GMT.
# Italy # @@ -1947,40 +1840,7 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 EU EE%sT
# Luxembourg -# Whitman disagrees with most of these dates in minor ways; -# go with Shanks & Pottenger. -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Lux 1916 only - May 14 23:00 1:00 S -Rule Lux 1916 only - Oct 1 1:00 0 - -Rule Lux 1917 only - Apr 28 23:00 1:00 S -Rule Lux 1917 only - Sep 17 1:00 0 - -Rule Lux 1918 only - Apr Mon>=15 2:00s 1:00 S -Rule Lux 1918 only - Sep Mon>=15 2:00s 0 - -Rule Lux 1919 only - Mar 1 23:00 1:00 S -Rule Lux 1919 only - Oct 5 3:00 0 - -Rule Lux 1920 only - Feb 14 23:00 1:00 S -Rule Lux 1920 only - Oct 24 2:00 0 - -Rule Lux 1921 only - Mar 14 23:00 1:00 S -Rule Lux 1921 only - Oct 26 2:00 0 - -Rule Lux 1922 only - Mar 25 23:00 1:00 S -Rule Lux 1922 only - Oct Sun>=2 1:00 0 - -Rule Lux 1923 only - Apr 21 23:00 1:00 S -Rule Lux 1923 only - Oct Sun>=2 2:00 0 - -Rule Lux 1924 only - Mar 29 23:00 1:00 S -Rule Lux 1924 1928 - Oct Sun>=2 1:00 0 - -Rule Lux 1925 only - Apr 5 23:00 1:00 S -Rule Lux 1926 only - Apr 17 23:00 1:00 S -Rule Lux 1927 only - Apr 9 23:00 1:00 S -Rule Lux 1928 only - Apr 14 23:00 1:00 S -Rule Lux 1929 only - Apr 20 23:00 1:00 S -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun - 1:00 Lux CE%sT 1918 Nov 25 - 0:00 Lux WE%sT 1929 Oct 6 2:00s - 0:00 Belgium WE%sT 1940 May 14 3:00 - 1:00 C-Eur WE%sT 1944 Sep 18 3:00 - 1:00 Belgium CE%sT 1977 - 1:00 EU CE%sT +# See Europe/Brussels.
# North Macedonia # See Europe/Belgrade. @@ -2081,122 +1941,16 @@ Zone Europe/Chisinau 1:55:20 - LMT 1880 2:00 Moldova EE%sT
# Monaco -# -# From Michael Deckers (2020-06-12): -# In the "Journal de Monaco" of 1892-05-24, online at -# https://journaldemonaco.gouv.mc/var/jdm/storage/original/application/b1c67c1... -# we read: ... -# [In virtue of a Sovereign Ordinance of the May 13 of the current [year], -# legal time in the Principality will be set to, from the date of June 1, -# 1892 onwards, to the meridian of Paris, as in France.] -# In the "Journal de Monaco" of 1911-03-28, online at -# https://journaldemonaco.gouv.mc/var/jdm/storage/original/application/de74ffb... -# we read an ordinance of 1911-03-16: ... -# [Legal time in the Principality will be set, from the date of promulgation -# of the present ordinance, to legal time in France.... Consequently, legal -# time will be retarded by 9 minutes and 21 seconds.] -# -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Monaco 0:29:32 - LMT 1892 Jun 1 - 0:09:21 - PMT 1911 Mar 29 # Paris Mean Time - 0:00 France WE%sT 1945 Sep 16 3:00 - 1:00 France CE%sT 1977 - 1:00 EU CE%sT +# See Europe/Paris.
# Montenegro # See Europe/Belgrade.
# Netherlands - -# Howse writes that the Netherlands' railways used GMT between 1892 and 1940, -# but for other purposes the Netherlands used Amsterdam mean time. - -# However, Robert H. van Gent writes (2001-04-01): -# Howse's statement is only correct up to 1909. From 1909-05-01 (00:00:00 -# Amsterdam mean time) onwards, the whole of the Netherlands (including -# the Dutch railways) was required by law to observe Amsterdam mean time -# (19 minutes 32.13 seconds ahead of GMT). This had already been the -# common practice (except for the railways) for many decades but it was -# not until 1909 when the Dutch government finally defined this by law. -# On 1937-07-01 this was changed to 20 minutes (exactly) ahead of GMT and -# was generally known as Dutch Time ("Nederlandse Tijd"). -# -# (2001-04-08): -# 1892-05-01 was the date when the Dutch railways were by law required to -# observe GMT while the remainder of the Netherlands adhered to the common -# practice of following Amsterdam mean time. -# -# (2001-04-09): -# In 1835 the authorities of the province of North Holland requested the -# municipal authorities of the towns and cities in the province to observe -# Amsterdam mean time but I do not know in how many cases this request was -# actually followed. -# -# From 1852 onwards the Dutch telegraph offices were by law required to -# observe Amsterdam mean time. As the time signals from the observatory of -# Leiden were also distributed by the telegraph system, I assume that most -# places linked up with the telegraph (and railway) system automatically -# adopted Amsterdam mean time. -# -# Although the early Dutch railway companies initially observed a variety -# of times, most of them had adopted Amsterdam mean time by 1858 but it -# was not until 1866 when they were all required by law to observe -# Amsterdam mean time. - -# The data entries before 1945 are taken from -# https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm - -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Neth 1916 only - May 1 0:00 1:00 NST # Netherlands Summer Time -Rule Neth 1916 only - Oct 1 0:00 0 AMT # Amsterdam Mean Time -Rule Neth 1917 only - Apr 16 2:00s 1:00 NST -Rule Neth 1917 only - Sep 17 2:00s 0 AMT -Rule Neth 1918 1921 - Apr Mon>=1 2:00s 1:00 NST -Rule Neth 1918 1921 - Sep lastMon 2:00s 0 AMT -Rule Neth 1922 only - Mar lastSun 2:00s 1:00 NST -Rule Neth 1922 1936 - Oct Sun>=2 2:00s 0 AMT -Rule Neth 1923 only - Jun Fri>=1 2:00s 1:00 NST -Rule Neth 1924 only - Mar lastSun 2:00s 1:00 NST -Rule Neth 1925 only - Jun Fri>=1 2:00s 1:00 NST -# From 1926 through 1939 DST began 05-15, except that it was delayed by a week -# in years when 05-15 fell in the Pentecost weekend. -Rule Neth 1926 1931 - May 15 2:00s 1:00 NST -Rule Neth 1932 only - May 22 2:00s 1:00 NST -Rule Neth 1933 1936 - May 15 2:00s 1:00 NST -Rule Neth 1937 only - May 22 2:00s 1:00 NST -Rule Neth 1937 only - Jul 1 0:00 1:00 S -Rule Neth 1937 1939 - Oct Sun>=2 2:00s 0 - -Rule Neth 1938 1939 - May 15 2:00s 1:00 S -Rule Neth 1945 only - Apr 2 2:00s 1:00 S -Rule Neth 1945 only - Sep 16 2:00s 0 - -# -# Amsterdam Mean Time was +00:19:32.13, but the .13 is omitted -# below because the current format requires STDOFF to be an integer. -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Amsterdam 0:19:32 - LMT 1835 - 0:19:32 Neth %s 1937 Jul 1 - 0:20 Neth +0020/+0120 1940 May 16 0:00 - 1:00 C-Eur CE%sT 1945 Apr 2 2:00 - 1:00 Neth CE%sT 1977 - 1:00 EU CE%sT +# See Europe/Brussels.
# Norway -# http://met.no/met/met_lex/q_u/sommertid.html (2004-01) agrees with Shanks & -# Pottenger. -# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Norway 1916 only - May 22 1:00 1:00 S -Rule Norway 1916 only - Sep 30 0:00 0 - -Rule Norway 1945 only - Apr 2 2:00s 1:00 S -Rule Norway 1945 only - Oct 1 2:00s 0 - -Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S -Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 - -Rule Norway 1965 only - Apr 25 2:00s 1:00 S -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 - 1:00 Norway CE%sT 1940 Aug 10 23:00 - 1:00 C-Eur CE%sT 1945 Apr 2 2:00 - 1:00 Norway CE%sT 1980 - 1:00 EU CE%sT +# See Europe/Berlin.
# Svalbard & Jan Mayen
@@ -2243,7 +1997,7 @@ Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 # the German armed forces at the Svalbard weather station code-named # Haudegen did not surrender to the Allies until September 1945. # -# All these events predate our cutoff date of 1970, so use Europe/Oslo +# All these events predate our cutoff date of 1970, so use Europe/Berlin # for these regions.
@@ -3627,58 +3381,7 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. # Ignore this for now, as the Canaries are part of the EU.
# Sweden - -# From Ivan Nilsson (2001-04-13), superseding Shanks & Pottenger: -# -# The law "Svensk författningssamling 1878, no 14" about standard time in 1879: -# From the beginning of 1879 (that is 01-01 00:00) the time for all -# places in the country is "the mean solar time for the meridian at -# three degrees, or twelve minutes of time, to the west of the -# meridian of the Observatory of Stockholm". The law is dated 1878-05-31. -# -# The observatory at that time had the meridian 18° 03' 30" -# eastern longitude = 01:12:14 in time. Less 12 minutes gives the -# national standard time as 01:00:14 ahead of GMT.... -# -# About the beginning of CET in Sweden. The lawtext ("Svensk -# författningssamling 1899, no 44") states, that "from the beginning -# of 1900... ... the same as the mean solar time for the meridian at -# the distance of one hour of time from the meridian of the English -# observatory at Greenwich, or at 12 minutes 14 seconds to the west -# from the meridian of the Observatory of Stockholm". The law is dated -# 1899-06-16. In short: At 1900-01-01 00:00:00 the new standard time -# in Sweden is 01:00:00 ahead of GMT. -# -# 1916: The lawtext ("Svensk författningssamling 1916, no 124") states -# that "1916-05-15 is considered to begin one hour earlier". It is -# pretty obvious that at 05-14 23:00 the clocks are set to 05-15 00:00.... -# Further the law says, that "1916-09-30 is considered to end one hour later". -# -# The laws regulating [DST] are available on the site of the Swedish -# Parliament beginning with 1985 - the laws regulating 1980/1984 are -# not available on the site (to my knowledge they are only available -# in Swedish): <http://www.riksdagen.se/english/work/sfst.asp> (type -# "sommartid" without the quotes in the field "Fritext" and then click -# the Sök-button). -# -# (2001-05-13): -# -# I have now found a newspaper stating that at 1916-10-01 01:00 -# summertime the church-clocks etc were set back one hour to show -# 1916-10-01 00:00 standard time. The article also reports that some -# people thought the switch to standard time would take place already -# at 1916-10-01 00:00 summer time, but they had to wait for another -# hour before the event took place. -# -# Source: The newspaper "Dagens Nyheter", 1916-10-01, page 7 upper left. - -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 - 1:00:14 - SET 1900 Jan 1 # Swedish Time - 1:00 - CET 1916 May 14 23:00 - 1:00 1:00 CEST 1916 Oct 1 1:00 - 1:00 - CET 1980 - 1:00 EU CE%sT +# See Europe/Berlin.
# Switzerland # From Howse: diff --git a/northamerica b/northamerica index b27311a..7edd8ef 100644 --- a/northamerica +++ b/northamerica @@ -1593,24 +1593,7 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # From Paul Eggert (2020-01-10): # See America/Toronto for most of Quebec, including Montreal. # See America/Halifax for the Îles de la Madeleine and the Listuguj reserve. -# -# Matthews and Vincent (1998) also write that Quebec east of the -63 -# meridian is supposed to observe AST, but residents as far east as -# Natashquan use EST/EDT, and residents east of Natashquan use AST. -# The Quebec department of justice writes in -# "The situation in Minganie and Basse-Côte-Nord" -# https://www.justice.gouv.qc.ca/en/department/ministre/functions-and-responsa... -# that the coastal strip from just east of Natashquan to Blanc-Sablon -# observes Atlantic standard time all year round. -# This common practice was codified into law as of 2007; see Legal Time Act, -# CQLR c T-5.1 <http://legisquebec.gouv.qc.ca/en/ShowDoc/cs/T-5.1>. -# For lack of better info, guess this practice began around 1970, contra to -# Shanks & Pottenger who have this region observing AST/ADT. - -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Blanc-Sablon -3:48:28 - LMT 1884 - -4:00 Canada A%sT 1970 - -4:00 - AST +# See America/Puerto_Rico for east of Natashquan.
# Ontario
@@ -1649,54 +1632,6 @@ Zone America/Blanc-Sablon -3:48:28 - LMT 1884 # time became a comic failure in Orillia. Toronto Star 2017-07-08. # https://www.thestar.com/news/insight/2017/07/08/bold-attempt-at-daylight-sav...
-# From Paul Eggert (1997-10-17): -# Mark Brader writes that an article in the 1997-10-14 Toronto Star -# says that Atikokan, Ontario currently does not observe DST, -# but will vote on 11-10 whether to use EST/EDT. -# He also writes that the Ontario Time Act (1990, Chapter T.9) -# http://www.gov.on.ca/MBS/english/publications/statregs/conttext.html -# says that Ontario east of 90W uses EST/EDT, and west of 90W uses CST/CDT. -# Officially Atikokan is therefore on CST/CDT, and most likely this report -# concerns a non-official time observed as a matter of local practice. -# -# From Paul Eggert (2000-10-02): -# Matthews and Vincent (1998) write that Atikokan, Pickle Lake, and -# New Osnaburgh observe CST all year, that Big Trout Lake observes -# CST/CDT, and that Upsala and Shebandowan observe EST/EDT, all in -# violation of the official Ontario rules. -# -# From Paul Eggert (2006-07-09): -# Chris Walton (2006-07-06) mentioned an article by Stephanie MacLellan in the -# 2005-07-21 Chronicle-Journal, which said: -# -# The clocks in Atikokan stay set on standard time year-round. -# This means they spend about half the time on central time and -# the other half on eastern time. -# -# For the most part, the system works, Mayor Dennis Brown said. -# -# "The majority of businesses in Atikokan deal more with Eastern -# Canada, but there are some that deal with Western Canada," he -# said. "I don't see any changes happening here." -# -# Walton also writes "Supposedly Pickle Lake and Mishkeegogamang -# [New Osnaburgh] follow the same practice." - -# From Garry McKinnon (2006-07-14) via Chris Walton: -# I chatted with a member of my board who has an outstanding memory -# and a long history in Atikokan (and in the telecom industry) and he -# can say for certain that Atikokan has been practicing the current -# time keeping since 1952, at least. - -# From Paul Eggert (2006-07-17): -# Shanks & Pottenger say that Atikokan has agreed with Rainy River -# ever since standard time was introduced, but the information from -# McKinnon sounds more authoritative. For now, assume that Atikokan -# switched to EST immediately after WWII era daylight saving time -# ended. This matches the old (less-populous) America/Coral_Harbour -# entry since our cutoff date of 1970, so we can move -# America/Coral_Harbour to the 'backward' file. - # From Mark Brader (2010-03-06): # # Currently the database has: @@ -1842,11 +1777,7 @@ Zone America/Rainy_River -6:18:16 - LMT 1895 -6:00 Canada C%sT 1940 Sep 29 -6:00 1:00 CDT 1942 Feb 9 2:00s -6:00 Canada C%sT -Zone America/Atikokan -6:06:28 - LMT 1895 - -6:00 Canada C%sT 1940 Sep 29 - -6:00 1:00 CDT 1942 Feb 9 2:00s - -6:00 Canada C%sT 1945 Sep 30 2:00 - -5:00 - EST +# For Atikokan see America/Panama.
# Manitoba @@ -2037,60 +1968,6 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep # Shanks & Pottenger write that since 1970 most of this region has # been like Vancouver. # Dawson Creek uses MST. Much of east BC is like Edmonton. -# Matthews and Vincent (1998) write that Creston is like Dawson Creek. - -# It seems though that (re: Creston) is not entirely correct: - -# From Chris Walton (2011-12-01): -# There are two areas within the Canadian province of British Columbia -# that do not currently observe daylight saving: -# a) The Creston Valley (includes the town of Creston and surrounding area) -# b) The eastern half of the Peace River Regional District -# (includes the cities of Dawson Creek and Fort St. John) - -# Earlier this year I stumbled across a detailed article about the time -# keeping history of Creston; it was written by Tammy Hardwick who is the -# manager of the Creston & District Museum. The article was written in May 2009. -# http://www.ilovecreston.com/?p=articles&t=spec&ar=260 -# According to the article, Creston has not changed its clocks since June 1918. -# i.e. Creston has been stuck on UT-7 for 93 years. -# Dawson Creek, on the other hand, changed its clocks as recently as April 1972. - -# Unfortunately the exact date for the time change in June 1918 remains -# unknown and will be difficult to ascertain. I e-mailed Tammy a few months -# ago to ask if Sunday June 2 was a reasonable guess. She said it was just -# as plausible as any other date (in June). She also said that after writing -# the article she had discovered another time change in 1916; this is the -# subject of another article which she wrote in October 2010. -# http://www.creston.museum.bc.ca/index.php?module=comments&uop=view_comment&c... - -# Here is a summary of the three clock change events in Creston's history: -# 1. 1884 or 1885: adoption of Mountain Standard Time (GMT-7) -# Exact date unknown -# 2. Oct 1916: switch to Pacific Standard Time (GMT-8) -# Exact date in October unknown; Sunday October 1 is a reasonable guess. -# 3. June 1918: switch to Pacific Daylight Time (GMT-7) -# Exact date in June unknown; Sunday June 2 is a reasonable guess. -# note 1: -# On Oct 27/1918 when daylight saving ended in the rest of Canada, -# Creston did not change its clocks. -# note 2: -# During WWII when the Federal Government legislated a mandatory clock change, -# Creston did not oblige. -# note 3: -# There is no guarantee that Creston will remain on Mountain Standard Time -# (UTC-7) forever. -# The subject was debated at least once this year by the town Council. -# http://www.bclocalnews.com/kootenay_rockies/crestonvalleyadvance/news/116760... - -# During a period WWII, summer time (Daylight saying) was mandatory in Canada. -# In Creston, that was handled by shifting the area to PST (-8:00) then applying -# summer time to cause the offset to be -7:00, the same as it had been before -# the change. It can be argued that the timezone abbreviation during this -# period should be PDT rather than MST, but that doesn't seem important enough -# (to anyone) to further complicate the rules. - -# The transition dates (and times) are guesses.
# From Matt Johnson (2015-09-21): # Fort Nelson, BC, Canada will cancel DST this year. So while previously they @@ -2144,10 +2021,7 @@ Zone America/Fort_Nelson -8:10:47 - LMT 1884 -8:00 Vanc P%sT 1987 -8:00 Canada P%sT 2015 Mar 8 2:00 -7:00 - MST -Zone America/Creston -7:46:04 - LMT 1884 - -7:00 - MST 1916 Oct 1 - -8:00 - PST 1918 Jun 2 - -7:00 - MST +# For Creston see America/Phoenix.
# Northwest Territories, Nunavut, Yukon
@@ -2929,50 +2803,11 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56
# Anguilla # Antigua and Barbuda -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# The Bahamas -# -# For 1899 Milne gives -5:09:29.5; round that. -# -# From P Chan (2020-11-27, corrected on 2020-12-02): -# There were two periods of DST observed in 1942-1945: 1942-05-01 -# midnight to 1944-12-31 midnight and 1945-02-01 to 1945-10-17 midnight. -# "midnight" should mean 24:00 from the context. -# -# War Time Order 1942 [1942-05-01] and War Time (No. 2) Order 1942 [1942-09-29] -# Appendix to the Statutes of 7 George VI. and the Year 1942. p 34, 43 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA34 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA43 -# -# War Time Order 1943 [1943-03-31] and War Time Order 1944 [1943-12-29] -# Appendix to the Statutes of 8 George VI. and the Year 1943. p 9-10, 28-29 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA9 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA28 -# -# War Time Order 1945 [1945-01-31] and the Order which revoke War Time Order -# 1945 [1945-10-16] Appendix to the Statutes of 9 George VI. and the Year -# 1945. p 160, 247-248 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA160 -# https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA247 -# -# From Sue Williams (2006-12-07): -# The Bahamas announced about a month ago that they plan to change their DST -# rules to sync with the U.S. starting in 2007.... -# http://www.jonesbahamas.com/?c=45&a=10412 +# See America/Montreal.
-# Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Bahamas 1942 only - May 1 24:00 1:00 W -Rule Bahamas 1944 only - Dec 31 24:00 0 S -Rule Bahamas 1945 only - Feb 1 0:00 1:00 W -Rule Bahamas 1945 only - Aug 14 23:00u 1:00 P # Peace -Rule Bahamas 1945 only - Oct 17 24:00 0 S -Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S -Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 - -5:00 Bahamas E%sT 1976 - -5:00 US E%sT
# Barbados
@@ -3185,7 +3020,7 @@ Zone Atlantic/Bermuda -4:19:18 - LMT 1890 # Hamilton -4:00 US A%sT
# Caribbean Netherlands -# See America/Curacao. +# See America/Puerto_Rico.
# Cayman Is # See America/Panama. @@ -3415,7 +3250,7 @@ Zone America/Havana -5:29:28 - LMT 1890 -5:00 Cuba C%sT
# Dominica -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# Dominican Republic
@@ -3467,7 +3302,7 @@ Zone America/El_Salvador -5:56:48 - LMT 1921 # San Salvador # Guadeloupe # St Barthélemy # St Martin (French part) -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# Guatemala # @@ -3654,7 +3489,7 @@ Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France -4:00 - AST
# Montserrat -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# Nicaragua # @@ -3737,7 +3572,7 @@ Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan
# St Kitts-Nevis # St Lucia -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# St Pierre and Miquelon # There are too many St Pierres elsewhere, so we'll use 'Miquelon'. @@ -3748,10 +3583,10 @@ Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -3:00 Canada -03/-02
# St Vincent and the Grenadines -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# Sint Maarten -# See America/Curacao. +# See America/Puerto_Rico.
# Turks and Caicos # @@ -3823,7 +3658,7 @@ Zone America/Grand_Turk -4:44:32 - LMT 1890
# British Virgin Is # US Virgin Is -# See America/Port_of_Spain. +# See America/Puerto_Rico.
# Local Variables: diff --git a/southamerica b/southamerica index eb987c5..7bc3e70 100644 --- a/southamerica +++ b/southamerica @@ -574,14 +574,11 @@ Zone America/Argentina/Ushuaia -4:33:12 - LMT 1894 Oct 31 -3:00 - -03
# Aruba -# See America/Curacao. +# See America/Puerto_Rico.
# Bolivia -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/La_Paz -4:32:36 - LMT 1890 - -4:32:36 - CMT 1931 Oct 15 # Calamarca MT - -4:32:36 1:00 BST 1932 Mar 21 # Bolivia ST - -4:00 - -04 +# See Etc/GMT+4. +
# Brazil
@@ -1369,33 +1366,12 @@ Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 # no information; probably like America/Bogota
# Curaçao - -# Milne gives 4:35:46.9 for Curaçao mean time; round to nearest. +# See America/Puerto_Rico. # -# From Paul Eggert (2006-03-22): -# Shanks & Pottenger say that The Bottom and Philipsburg have been at -# -4:00 since standard time was introduced on 1912-03-02; and that -# Kralendijk and Rincon used Kralendijk Mean Time (-4:33:08) from -# 1912-02-02 to 1965-01-01. The former is dubious, since S&P also say -# Saba Island has been like Curaçao. -# This all predates our 1970 cutoff, though. -# -# By July 2007 Curaçao and St Maarten are planned to become -# associated states within the Netherlands, much like Aruba; -# Bonaire, Saba and St Eustatius would become directly part of the -# Netherlands as Kingdom Islands. This won't affect their time zones -# though, as far as we know. -# -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad - -4:30 - -0430 1965 - -4:00 - AST - # From Arthur David Olson (2011-06-15): # use links for places with new iso3166 codes. # The name "Lower Prince's Quarter" is both longer than fourteen characters -# and contains an apostrophe; use "Lower_Princes" below. - +# and contains an apostrophe; use "Lower_Princes".... # From Paul Eggert (2021-05-06): # These backward-compatibility links now are in the 'backward' file.
@@ -1534,10 +1510,8 @@ Zone Atlantic/Stanley -3:51:24 - LMT 1890 -3:00 - -03
# French Guiana -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Cayenne -3:29:20 - LMT 1911 Jul - -4:00 - -04 1967 Oct - -3:00 - -03 +# See Etc/GMT+3. +
# Guyana
@@ -1698,9 +1672,7 @@ Zone America/Lima -5:08:12 - LMT 1890 -5:00 Peru -05/-04
# South Georgia -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Atlantic/South_Georgia -2:26:08 - LMT 1890 # Grytviken - -2:00 - -02 +# See Etc/GMT+2.
# South Sandwich Is # uninhabited; scientific personnel have wintered @@ -1714,9 +1686,7 @@ Zone America/Paramaribo -3:40:40 - LMT 1911 -3:00 - -03
# Trinidad and Tobago -# Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 - -4:00 - AST +# See America/Puerto_Rico.
# Uruguay # From Paul Eggert (1993-11-18): diff --git a/theory.html b/theory.html index 80942e6..47a7b2d 100644 --- a/theory.html +++ b/theory.html @@ -192,8 +192,8 @@ in decreasing order of importance: <code>TZ</code> strings</a>. A file name component must not exceed 14 characters or start with '<code>-</code>'. - E.g., prefer <code>Asia/Brunei</code> to - <code>Asia/Bandar_Seri_Begawan</code>. + E.g., prefer <code>America/Noronha</code> to + <code>America/Fernando_de_Noronha</code>. Exceptions: see the discussion of legacy names below. </li> <li> @@ -475,10 +475,10 @@ in decreasing order of importance:
<p> <small>These abbreviations are: - AMT Amsterdam, Asunción, Athens; - BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Bridgetown, + AMT Asunción, Athens; + BMT Baghdad, Batavia, Bermuda, Bern, Bogotá, Bridgetown, Brussels, Bucharest; - CMT Calamarca, Caracas, Chisinau, Colón, Copenhagen, Córdoba; + CMT Calamarca, Caracas, Chisinau, Colón, Córdoba; DMT Dublin/Dunsink; EMT Easter; FFMT Fort-de-France; @@ -493,7 +493,6 @@ in decreasing order of importance: Moratuwa, Moscow; PLMT Phù Liễn; PMT Paramaribo, Paris, Perm, Pontianak, Prague; - PMMT Port Moresby; QMT Quito; RMT Rangoon, Riga, Rome; SDMT Santo Domingo; @@ -516,9 +515,7 @@ in decreasing order of importance: 1880–1916, MMT/MST/MDST for Moscow 1880–1919, and RMT/LST for Riga Mean Time and Latvian Summer time 1880–1926. - An extra-special case is SET for Swedish Time (<em>svensk - normaltid</em>) 1879–1899, 3° west of the Stockholm - Observatory.</small> + </small> </p> </li> <li> @@ -705,11 +702,9 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes <li> Sometimes historical timekeeping was specified more precisely than what the <code><abbr>tz</abbr></code> code can handle. - For example, from 1909 to 1937 <a - href="https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm" - hreflang="nl">Netherlands clocks</a> were legally Amsterdam Mean + For example, from 1880 to 1916 clocks in Ireland observed Dublin Mean Time (estimated to be <abbr>UT</abbr> - +00:19:32.13), but the <code><abbr>tz</abbr></code> + −00:25:21.1), but the <code><abbr>tz</abbr></code> code cannot represent the fractional second. In practice these old specifications were rarely if ever implemented to subsecond precision. @@ -759,7 +754,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes such as that required by POSIX. If <abbr>DST</abbr> is not used a different time zone can often do the trick; for example, in Kenya a <code>TZ</code> setting - like <code><-03>3</code> or <code>America/Cayenne</code> starts + like <code><-03>3</code> starts the day six hours later than <code>Africa/Nairobi</code> does. </li> <li> @@ -1240,11 +1235,11 @@ based on guesswork and these guesses may be corrected or improved.
<p> Timezone boundaries are not part of the stable interface. -For example, even though the <samp>Asia/Bangkok</samp> timezone -currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part +For example, even though the <samp>Asia/Singapore</samp> timezone +currently includes peninsular Malaysia as well as Singapore, this is not part of the stable interface and the timezone can split at any time. If a calendar application records a future event in some location other -than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record, +than Singapore by putting "<samp>Asia/Singapore</samp>" in the event's record, the application should be robust in the presence of timezone splits between now and the future time. </p> diff --git a/zone.tab b/zone.tab index 291e4f3..4954ae3 100644 --- a/zone.tab +++ b/zone.tab @@ -27,23 +27,23 @@ #country- #code coordinates TZ comments AD +4230+00131 Europe/Andorra -AE +2518+05518 Asia/Dubai +AE +2518+05518 Etc/GMT-4 AF +3431+06912 Asia/Kabul -AG +1703-06148 America/Port_of_Spain -AI +1812-06304 America/Port_of_Spain +AG +1703-06148 America/Puerto_Rico +AI +1812-06304 America/Puerto_Rico AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan AO -0848+01314 Africa/Lagos AQ -7750+16636 Pacific/Auckland New Zealand time - McMurdo, South Pole AQ -6617+11031 Antarctica/Casey Casey AQ -6835+07758 Antarctica/Davis Davis -AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville +AQ -6640+14001 Etc/GMT-10 Dumont-d'Urville AQ -6736+06253 Antarctica/Mawson Mawson AQ -6448-06406 Antarctica/Palmer Palmer AQ -6734-06808 Antarctica/Rothera Rothera -AQ -690022+0393524 Antarctica/Syowa Syowa +AQ -690022+0393524 Etc/GMT-3 Syowa AQ -720041+0023206 Antarctica/Troll Troll -AQ -7824+10654 Antarctica/Vostok Vostok +AQ -7824+10654 Etc/GMT-6 Vostok AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) AR -3124-06411 America/Argentina/Cordoba Argentina (most areas: CB, CC, CN, ER, FM, MN, SE, SF) AR -2447-06525 America/Argentina/Salta Salta (SA, LP, NQ, RN) @@ -70,23 +70,23 @@ AU -3455+13835 Australia/Adelaide South Australia AU -1228+13050 Australia/Darwin Northern Territory AU -3157+11551 Australia/Perth Western Australia (most areas) AU -3143+12852 Australia/Eucla Western Australia (Eucla) -AW +1230-06958 America/Curacao +AW +1230-06958 America/Puerto_Rico AX +6006+01957 Europe/Helsinki AZ +4023+04951 Asia/Baku BA +4352+01825 Europe/Belgrade BB +1306-05937 America/Barbados BD +2343+09025 Asia/Dhaka BE +5050+00420 Europe/Brussels -BF +1222-00131 Africa/Abidjan +BF +1222-00131 Etc/GMT BG +4241+02319 Europe/Sofia BH +2623+05035 Asia/Qatar BI -0323+02922 Africa/Maputo BJ +0629+00237 Africa/Lagos -BL +1753-06251 America/Port_of_Spain +BL +1753-06251 America/Puerto_Rico BM +3217-06446 Atlantic/Bermuda -BN +0456+11455 Asia/Brunei -BO -1630-06809 America/La_Paz -BQ +120903-0681636 America/Curacao +BN +0456+11455 Etc/GMT-8 +BO -1630-06809 Etc/GMT+4 +BQ +120903-0681636 America/Puerto_Rico BR -0351-03225 America/Noronha Atlantic islands BR -0127-04829 America/Belem Para (east); Amapa BR -0343-03830 America/Fortaleza Brazil (northeast: MA, PI, CE, RN, PB) @@ -103,7 +103,7 @@ BR +0249-06040 America/Boa_Vista Roraima BR -0308-06001 America/Manaus Amazonas (east) BR -0640-06952 America/Eirunepe Amazonas (west) BR -0958-06748 America/Rio_Branco Acre -BS +2505-07721 America/Nassau +BS +2505-07721 America/Toronto BT +2728+08939 Asia/Thimphu BW -2439+02555 Africa/Maputo BY +5354+02734 Europe/Minsk @@ -113,13 +113,13 @@ CA +4439-06336 America/Halifax Atlantic - NS (most areas); PE CA +4612-05957 America/Glace_Bay Atlantic - NS (Cape Breton) CA +4606-06447 America/Moncton Atlantic - New Brunswick CA +5320-06025 America/Goose_Bay Atlantic - Labrador (most areas) -CA +5125-05707 America/Blanc-Sablon AST - QC (Lower North Shore) +CA +5125-05707 America/Puerto_Rico AST - QC (Lower North Shore) CA +4339-07923 America/Toronto Eastern - ON, QC (most areas) CA +4901-08816 America/Nipigon Eastern - ON, QC (no DST 1967-73) CA +4823-08915 America/Thunder_Bay Eastern - ON (Thunder Bay) CA +6344-06828 America/Iqaluit Eastern - NU (most east areas) CA +6608-06544 America/Pangnirtung Eastern - NU (Pangnirtung) -CA +484531-0913718 America/Atikokan EST - ON (Atikokan); NU (Coral H) +CA +484531-0913718 America/Panama EST - ON (Atikokan); NU (Coral H) CA +4953-09709 America/Winnipeg Central - ON (west); Manitoba CA +4843-09434 America/Rainy_River Central - ON (Rainy R, Ft Frances) CA +744144-0944945 America/Resolute Central - NU (Resolute) @@ -130,40 +130,40 @@ CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) -CA +4906-11631 America/Creston MST - BC (Creston) +CA +4906-11631 America/Phoenix MST - BC (Creston) CA +5946-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson) CA +6043-13503 America/Whitehorse MST - Yukon (east) CA +6404-13925 America/Dawson MST - Yukon (west) CA +4916-12307 America/Vancouver Pacific - BC (most areas) -CC -1210+09655 Indian/Cocos +CC -1210+09655 Asia/Yangon CD -0418+01518 Africa/Lagos Dem. Rep. of Congo (west) CD -1140+02728 Africa/Maputo Dem. Rep. of Congo (east) CF +0422+01835 Africa/Lagos CG -0416+01517 Africa/Lagos CH +4723+00832 Europe/Zurich -CI +0519-00402 Africa/Abidjan +CI +0519-00402 Etc/GMT CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago Chile (most areas) CL -5309-07055 America/Punta_Arenas Region of Magallanes CL -2709-10926 Pacific/Easter Easter Island CM +0403+00942 Africa/Lagos CN +3114+12128 Asia/Shanghai Beijing Time -CN +4348+08735 Asia/Urumqi Xinjiang Time +CN +4348+08735 Etc/GMT-6 Xinjiang Time CO +0436-07405 America/Bogota CR +0956-08405 America/Costa_Rica CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde -CW +1211-06900 America/Curacao -CX -1025+10543 Indian/Christmas +CW +1211-06900 America/Puerto_Rico +CX -1025+10543 Etc/GMT-7 CY +3510+03322 Asia/Nicosia Cyprus (most areas) CY +3507+03357 Asia/Famagusta Northern Cyprus CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) DE +4742+00841 Europe/Zurich Swiss time DJ +1136+04309 Africa/Nairobi -DK +5540+01235 Europe/Copenhagen -DM +1518-06124 America/Port_of_Spain +DK +5540+01235 Europe/Berlin +DM +1518-06124 America/Puerto_Rico DO +1828-06954 America/Santo_Domingo DZ +3647+00303 Africa/Algiers EC -0210-07950 America/Guayaquil Ecuador (mainland) @@ -179,29 +179,29 @@ ET +0902+03842 Africa/Nairobi FI +6010+02458 Europe/Helsinki FJ -1808+17825 Pacific/Fiji FK -5142-05751 Atlantic/Stanley -FM +0725+15147 Pacific/Chuuk Chuuk/Truk, Yap -FM +0658+15813 Pacific/Pohnpei Pohnpei/Ponape +FM +0725+15147 Etc/GMT-10 Chuuk/Truk, Yap +FM +0658+15813 Etc/GMT-11 Pohnpei/Ponape FM +0519+16259 Pacific/Kosrae Kosrae FO +6201-00646 Atlantic/Faroe FR +4852+00220 Europe/Paris GA +0023+00927 Africa/Lagos GB +513030-0000731 Europe/London -GD +1203-06145 America/Port_of_Spain +GD +1203-06145 America/Puerto_Rico GE +4143+04449 Asia/Tbilisi -GF +0456-05220 America/Cayenne +GF +0456-05220 Etc/GMT+3 GG +492717-0023210 Europe/London -GH +0533-00013 Africa/Accra +GH +0533-00013 Etc/GMT GI +3608-00521 Europe/Gibraltar GL +6411-05144 America/Nuuk Greenland (most areas) GL +7646-01840 America/Danmarkshavn National Park (east coast) GL +7029-02158 America/Scoresbysund Scoresbysund/Ittoqqortoormiit GL +7634-06847 America/Thule Thule/Pituffik -GM +1328-01639 Africa/Abidjan -GN +0931-01343 Africa/Abidjan -GP +1614-06132 America/Port_of_Spain +GM +1328-01639 Etc/GMT +GN +0931-01343 Etc/GMT +GP +1614-06132 America/Puerto_Rico GQ +0345+00847 Africa/Lagos GR +3758+02343 Europe/Athens -GS -5416-03632 Atlantic/South_Georgia +GS -5416-03632 Etc/GMT+2 GT +1438-09031 America/Guatemala GU +1328+14445 Pacific/Guam GW +1151-01535 Africa/Bissau @@ -222,7 +222,7 @@ IN +2232+08822 Asia/Kolkata IO -0720+07225 Indian/Chagos IQ +3321+04425 Asia/Baghdad IR +3540+05126 Asia/Tehran -IS +6409-02151 Atlantic/Reykjavik +IS +6409-02151 Etc/GMT IT +4154+01229 Europe/Rome JE +491101-0020624 Europe/London JM +175805-0764736 America/Jamaica @@ -230,15 +230,15 @@ JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek -KH +1133+10455 Asia/Bangkok -KI +0125+17300 Pacific/Tarawa Gilbert Islands +KH +1133+10455 Etc/GMT-7 +KI +0125+17300 Etc/GMT-12 Gilbert Islands KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KM -1141+04316 Africa/Nairobi -KN +1718-06243 America/Port_of_Spain +KN +1718-06243 America/Puerto_Rico KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul -KW +2920+04759 Asia/Riyadh +KW +2920+04759 Etc/GMT-3 KY +1918-08123 America/Panama KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) KZ +4448+06528 Asia/Qyzylorda Qyzylorda/Kyzylorda/Kzyl-Orda @@ -247,27 +247,27 @@ KZ +5017+05710 Asia/Aqtobe Aqtobe/Aktobe KZ +4431+05016 Asia/Aqtau Mangghystau/Mankistau KZ +4707+05156 Asia/Atyrau Atyrau/Atirau/Gur'yev KZ +5113+05121 Asia/Oral West Kazakhstan -LA +1758+10236 Asia/Bangkok +LA +1758+10236 Etc/GMT-7 LB +3353+03530 Asia/Beirut -LC +1401-06100 America/Port_of_Spain +LC +1401-06100 America/Puerto_Rico LI +4709+00931 Europe/Zurich LK +0656+07951 Asia/Colombo LR +0618-01047 Africa/Monrovia LS -2928+02730 Africa/Johannesburg LT +5441+02519 Europe/Vilnius -LU +4936+00609 Europe/Luxembourg +LU +4936+00609 Europe/Brussels LV +5657+02406 Europe/Riga LY +3254+01311 Africa/Tripoli MA +3339-00735 Africa/Casablanca -MC +4342+00723 Europe/Monaco +MC +4342+00723 Europe/Paris MD +4700+02850 Europe/Chisinau ME +4226+01916 Europe/Belgrade -MF +1804-06305 America/Port_of_Spain +MF +1804-06305 America/Puerto_Rico MG -1855+04731 Africa/Nairobi -MH +0709+17112 Pacific/Majuro Marshall Islands (most areas) +MH +0709+17112 Etc/GMT-12 Marshall Islands (most areas) MH +0905+16720 Pacific/Kwajalein Kwajalein MK +4159+02126 Europe/Belgrade -ML +1239-00800 Africa/Abidjan +ML +1239-00800 Etc/GMT MM +1647+09610 Asia/Yangon MN +4755+10653 Asia/Ulaanbaatar Mongolia (most areas) MN +4801+09139 Asia/Hovd Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan @@ -275,11 +275,11 @@ MN +4804+11430 Asia/Choibalsan Dornod, Sukhbaatar MO +221150+1133230 Asia/Macau MP +1512+14545 Pacific/Guam MQ +1436-06105 America/Martinique -MR +1806-01557 Africa/Abidjan -MS +1643-06213 America/Port_of_Spain +MR +1806-01557 Etc/GMT +MS +1643-06213 America/Puerto_Rico MT +3554+01431 Europe/Malta MU -2010+05730 Indian/Mauritius -MV +0410+07330 Indian/Maldives +MV +0410+07330 Etc/GMT-5 MW -1547+03500 Africa/Maputo MX +1924-09909 America/Mexico_City Central Time MX +2105-08646 America/Cancun Eastern Standard Time - Quintana Roo @@ -292,8 +292,8 @@ MX +2934-10425 America/Ojinaga Mountain Time US - Chihuahua (US border) MX +2904-11058 America/Hermosillo Mountain Standard Time - Sonora MX +3232-11701 America/Tijuana Pacific Time US - Baja California MX +2048-10515 America/Bahia_Banderas Central Time - Bahia de Banderas -MY +0310+10142 Asia/Kuala_Lumpur Malaysia (peninsula) -MY +0133+11020 Asia/Kuching Sabah, Sarawak +MY +0310+10142 Asia/Singapore Malaysia (peninsula) +MY +0133+11020 Etc/GMT-8 Sabah, Sarawak MZ -2558+03235 Africa/Maputo NA -2234+01706 Africa/Windhoek NC -2216+16627 Pacific/Noumea @@ -301,20 +301,20 @@ NE +1331+00207 Africa/Lagos NF -2903+16758 Pacific/Norfolk NG +0627+00324 Africa/Lagos NI +1209-08617 America/Managua -NL +5222+00454 Europe/Amsterdam -NO +5955+01045 Europe/Oslo +NL +5222+00454 Europe/Brussels +NO +5955+01045 Europe/Berlin NP +2743+08519 Asia/Kathmandu NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ -3652+17446 Pacific/Auckland New Zealand (most areas) NZ -4357-17633 Pacific/Chatham Chatham Islands -OM +2336+05835 Asia/Dubai +OM +2336+05835 Etc/GMT-4 PA +0858-07932 America/Panama PE -1203-07703 America/Lima -PF -1732-14934 Pacific/Tahiti Society Islands +PF -1732-14934 Etc/GMT+10 Society Islands PF -0900-13930 Pacific/Marquesas Marquesas Islands -PF -2308-13457 Pacific/Gambier Gambier Islands -PG -0930+14710 Pacific/Port_Moresby Papua New Guinea (most areas) +PF -2308-13457 Etc/GMT+9 Gambier Islands +PG -0930+14710 Etc/GMT-10 Papua New Guinea (most areas) PG -0613+15534 Pacific/Bougainville Bougainville PH +1435+12100 Asia/Manila PK +2452+06703 Asia/Karachi @@ -327,10 +327,10 @@ PS +313200+0350542 Asia/Hebron West Bank PT +3843-00908 Europe/Lisbon Portugal (mainland) PT +3238-01654 Atlantic/Madeira Madeira Islands PT +3744-02540 Atlantic/Azores Azores -PW +0720+13429 Pacific/Palau +PW +0720+13429 Etc/GMT-9 PY -2516-05740 America/Asuncion QA +2517+05132 Asia/Qatar -RE -2052+05528 Indian/Reunion +RE -2052+05528 Etc/GMT-4 RO +4426+02606 Europe/Bucharest RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad @@ -364,32 +364,32 @@ RU +6728+15343 Asia/Srednekolymsk MSK+08 - Sakha (E); North Kuril Is RU +5301+15839 Asia/Kamchatka MSK+09 - Kamchatka RU +6445+17729 Asia/Anadyr MSK+09 - Bering Sea RW -0157+03004 Africa/Maputo -SA +2438+04643 Asia/Riyadh -SB -0932+16012 Pacific/Guadalcanal -SC -0440+05528 Indian/Mahe +SA +2438+04643 Etc/GMT-3 +SB -0932+16012 Etc/GMT-11 +SC -0440+05528 Etc/GMT-4 SD +1536+03232 Africa/Khartoum -SE +5920+01803 Europe/Stockholm +SE +5920+01803 Europe/Berlin SG +0117+10351 Asia/Singapore -SH -1555-00542 Africa/Abidjan +SH -1555-00542 Etc/GMT SI +4603+01431 Europe/Belgrade -SJ +7800+01600 Europe/Oslo +SJ +7800+01600 Europe/Berlin SK +4809+01707 Europe/Prague -SL +0830-01315 Africa/Abidjan +SL +0830-01315 Etc/GMT SM +4355+01228 Europe/Rome -SN +1440-01726 Africa/Abidjan +SN +1440-01726 Etc/GMT SO +0204+04522 Africa/Nairobi SR +0550-05510 America/Paramaribo SS +0451+03137 Africa/Juba ST +0020+00644 Africa/Sao_Tome SV +1342-08912 America/El_Salvador -SX +180305-0630250 America/Curacao +SX +180305-0630250 America/Puerto_Rico SY +3330+03618 Asia/Damascus SZ -2618+03106 Africa/Johannesburg TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena -TF -492110+0701303 Indian/Kerguelen -TG +0608+00113 Africa/Abidjan -TH +1345+10031 Asia/Bangkok +TF -492110+0701303 Etc/GMT-5 +TG +0608+00113 Etc/GMT +TH +1345+10031 Etc/GMT-7 TJ +3835+06848 Asia/Dushanbe TK -0922-17114 Pacific/Fakaofo TL -0833+12535 Asia/Dili @@ -397,8 +397,8 @@ TM +3757+05823 Asia/Ashgabat TN +3648+01011 Africa/Tunis TO -210800-1751200 Pacific/Tongatapu TR +4101+02858 Europe/Istanbul -TT +1039-06131 America/Port_of_Spain -TV -0831+17913 Pacific/Funafuti +TT +1039-06131 America/Puerto_Rico +TV -0831+17913 Etc/GMT-12 TW +2503+12130 Asia/Taipei TZ -0648+03917 Africa/Nairobi UA +5026+03031 Europe/Kiev Ukraine (most areas) @@ -406,7 +406,7 @@ UA +4837+02218 Europe/Uzhgorod Transcarpathia UA +4750+03510 Europe/Zaporozhye Zaporozhye and east Lugansk UG +0019+03225 Africa/Nairobi UM +2813-17722 Pacific/Pago_Pago Midway Islands -UM +1917+16637 Pacific/Wake Wake Island +UM +1917+16637 Etc/GMT-12 Wake Island US +404251-0740023 America/New_York Eastern (most areas) US +421953-0830245 America/Detroit Eastern - MI (most areas) US +381515-0854534 America/Kentucky/Louisville Eastern - KY (Louisville area) @@ -440,16 +440,16 @@ UY -345433-0561245 America/Montevideo UZ +3940+06648 Asia/Samarkand Uzbekistan (west) UZ +4120+06918 Asia/Tashkent Uzbekistan (east) VA +415408+0122711 Europe/Rome -VC +1309-06114 America/Port_of_Spain +VC +1309-06114 America/Puerto_Rico VE +1030-06656 America/Caracas -VG +1827-06437 America/Port_of_Spain -VI +1821-06456 America/Port_of_Spain -VN +2102+10551 Asia/Bangkok Vietnam (north) +VG +1827-06437 America/Puerto_Rico +VI +1821-06456 America/Puerto_Rico +VN +2102+10551 Etc/GMT-7 Vietnam (north) VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) VU -1740+16825 Pacific/Efate -WF -1318-17610 Pacific/Wallis +WF -1318-17610 Etc/GMT-12 WS -1350-17144 Pacific/Apia -YE +1245+04512 Asia/Riyadh +YE +1245+04512 Etc/GMT-3 YT -1247+04514 Africa/Nairobi ZA -2615+02800 Africa/Johannesburg ZM -1525+02817 Africa/Maputo diff --git a/zone1970.tab b/zone1970.tab index ddb2321..8cadd48 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -34,19 +34,18 @@ #country- #codes coordinates TZ comments AD +4230+00131 Europe/Andorra -AE,OM +2518+05518 Asia/Dubai +AE,OM,RE,SC,TF +2518+05518 Etc/GMT-4 UAE, Oman, Réunion, Seychelles, Crozet, Scattered Is AF +3431+06912 Asia/Kabul AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan AQ -6617+11031 Antarctica/Casey Casey AQ -6835+07758 Antarctica/Davis Davis -AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville AQ -6736+06253 Antarctica/Mawson Mawson AQ -6448-06406 Antarctica/Palmer Palmer AQ -6734-06808 Antarctica/Rothera Rothera -AQ -690022+0393524 Antarctica/Syowa Syowa AQ -720041+0023206 Antarctica/Troll Troll -AQ -7824+10654 Antarctica/Vostok Vostok +AQ,KW,SA,YE +2438+04643 Etc/GMT-3 Arabia, Syowa +AQ,FM,PG -0930+14710 Etc/GMT-10 Papua New Guinea (most areas), Chuuk, Yap, Dumont d'Urville AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) AR -3124-06411 America/Argentina/Cordoba Argentina (most areas: CB, CC, CN, ER, FM, MN, SE, SF) AR -2447-06525 America/Argentina/Salta Salta (SA, LP, NQ, RN) @@ -76,11 +75,12 @@ AU -3143+12852 Australia/Eucla Western Australia (Eucla) AZ +4023+04951 Asia/Baku BB +1306-05937 America/Barbados BD +2343+09025 Asia/Dhaka -BE +5050+00420 Europe/Brussels +BE,LU,NL +5050+00420 Europe/Brussels +BF,CI,GH,GM,GN,IS,ML,MR,SH,SL,SN,TG +0519-00402 Etc/GMT BG +4241+02319 Europe/Sofia BM +3217-06446 Atlantic/Bermuda -BN +0456+11455 Asia/Brunei -BO -1630-06809 America/La_Paz +BN,MY +0133+11020 Etc/GMT-8 Sabah, Sarawak, Brunei +BO -1630-06809 Etc/GMT+4 BR -0351-03225 America/Noronha Atlantic islands BR -0127-04829 America/Belem Pará (east); Amapá BR -0343-03830 America/Fortaleza Brazil (northeast: MA, PI, CE, RN, PB) @@ -97,7 +97,6 @@ BR +0249-06040 America/Boa_Vista Roraima BR -0308-06001 America/Manaus Amazonas (east) BR -0640-06952 America/Eirunepe Amazonas (west) BR -0958-06748 America/Rio_Branco Acre -BS +2505-07721 America/Nassau BT +2728+08939 Asia/Thimphu BY +5354+02734 Europe/Minsk BZ +1730-08812 America/Belize @@ -106,13 +105,11 @@ CA +4439-06336 America/Halifax Atlantic - NS (most areas); PE CA +4612-05957 America/Glace_Bay Atlantic - NS (Cape Breton) CA +4606-06447 America/Moncton Atlantic - New Brunswick CA +5320-06025 America/Goose_Bay Atlantic - Labrador (most areas) -CA +5125-05707 America/Blanc-Sablon AST - QC (Lower North Shore) -CA +4339-07923 America/Toronto Eastern - ON, QC (most areas) +CA,BS +4339-07923 America/Toronto Eastern - ON, QC (most areas), Bahamas CA +4901-08816 America/Nipigon Eastern - ON, QC (no DST 1967-73) CA +4823-08915 America/Thunder_Bay Eastern - ON (Thunder Bay) CA +6344-06828 America/Iqaluit Eastern - NU (most east areas) CA +6608-06544 America/Pangnirtung Eastern - NU (Pangnirtung) -CA +484531-0913718 America/Atikokan EST - ON (Atikokan); NU (Coral H) CA +4953-09709 America/Winnipeg Central - ON (west); Manitoba CA +4843-09434 America/Rainy_River Central - ON (Rainy R, Ft Frances) CA +744144-0944945 America/Resolute Central - NU (Resolute) @@ -123,32 +120,27 @@ CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) -CA +4906-11631 America/Creston MST - BC (Creston) CA +5946-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson) CA +6043-13503 America/Whitehorse MST - Yukon (east) CA +6404-13925 America/Dawson MST - Yukon (west) CA +4916-12307 America/Vancouver Pacific - BC (most areas) -CC -1210+09655 Indian/Cocos CH,DE,LI +4723+00832 Europe/Zurich Swiss time -CI,BF,GM,GN,ML,MR,SH,SL,SN,TG +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago Chile (most areas) CL -5309-07055 America/Punta_Arenas Region of Magallanes CL -2709-10926 Pacific/Easter Easter Island CN +3114+12128 Asia/Shanghai Beijing Time -CN +4348+08735 Asia/Urumqi Xinjiang Time +CN,AQ +4348+08735 Etc/GMT-6 Xinjiang Time, Vostok CO +0436-07405 America/Bogota CR +0956-08405 America/Costa_Rica CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde -CW,AW,BQ,SX +1211-06900 America/Curacao -CX -1025+10543 Indian/Christmas +CX,KH,LA,TH,VN +1345+10031 Etc/GMT-7 Indochina (most areas) CY +3510+03322 Asia/Nicosia Cyprus (most areas) CY +3507+03357 Asia/Famagusta Northern Cyprus CZ,SK +5005+01426 Europe/Prague -DE +5230+01322 Europe/Berlin Germany (most areas) -DK +5540+01235 Europe/Copenhagen +DE,DK,NO,SE,SJ +5230+01322 Europe/Berlin Germany (most areas), Scandinavia DO +1828-06954 America/Santo_Domingo DZ +3647+00303 Africa/Algiers EC -0210-07950 America/Guayaquil Ecuador (mainland) @@ -162,22 +154,19 @@ ES +2806-01524 Atlantic/Canary Canary Islands FI,AX +6010+02458 Europe/Helsinki FJ -1808+17825 Pacific/Fiji FK -5142-05751 Atlantic/Stanley -FM +0725+15147 Pacific/Chuuk Chuuk/Truk, Yap -FM +0658+15813 Pacific/Pohnpei Pohnpei/Ponape FM +0519+16259 Pacific/Kosrae Kosrae FO +6201-00646 Atlantic/Faroe -FR +4852+00220 Europe/Paris +FR,MC +4852+00220 Europe/Paris GB,GG,IM,JE +513030-0000731 Europe/London GE +4143+04449 Asia/Tbilisi -GF +0456-05220 America/Cayenne -GH +0533-00013 Africa/Accra +GF +0456-05220 Etc/GMT+3 GI +3608-00521 Europe/Gibraltar GL +6411-05144 America/Nuuk Greenland (most areas) GL +7646-01840 America/Danmarkshavn National Park (east coast) GL +7029-02158 America/Scoresbysund Scoresbysund/Ittoqqortoormiit GL +7634-06847 America/Thule Thule/Pituffik GR +3758+02343 Europe/Athens -GS -5416-03632 Atlantic/South_Georgia +GS -5416-03632 Etc/GMT+2 GT +1438-09031 America/Guatemala GU,MP +1328+14445 Pacific/Guam GW +1151-01535 Africa/Bissau @@ -196,16 +185,15 @@ IN +2232+08822 Asia/Kolkata IO -0720+07225 Indian/Chagos IQ +3321+04425 Asia/Baghdad IR +3540+05126 Asia/Tehran -IS +6409-02151 Atlantic/Reykjavik IT,SM,VA +4154+01229 Europe/Rome JM +175805-0764736 America/Jamaica JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE,DJ,ER,ET,KM,MG,SO,TZ,UG,YT -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek -KI +0125+17300 Pacific/Tarawa Gilbert Islands KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands +KI,MH,TV,UM,WF +0125+17300 Etc/GMT-12 Gilberts, Marshalls, Tuvalu, Wallis & Futuna, Wake KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) @@ -219,15 +207,12 @@ LB +3353+03530 Asia/Beirut LK +0656+07951 Asia/Colombo LR +0618-01047 Africa/Monrovia LT +5441+02519 Europe/Vilnius -LU +4936+00609 Europe/Luxembourg LV +5657+02406 Europe/Riga LY +3254+01311 Africa/Tripoli MA +3339-00735 Africa/Casablanca -MC +4342+00723 Europe/Monaco MD +4700+02850 Europe/Chisinau -MH +0709+17112 Pacific/Majuro Marshall Islands (most areas) MH +0905+16720 Pacific/Kwajalein Kwajalein -MM +1647+09610 Asia/Yangon +MM,CC +1647+09610 Asia/Yangon MN +4755+10653 Asia/Ulaanbaatar Mongolia (most areas) MN +4801+09139 Asia/Hovd Bayan-Ölgii, Govi-Altai, Hovd, Uvs, Zavkhan MN +4804+11430 Asia/Choibalsan Dornod, Sükhbaatar @@ -235,7 +220,7 @@ MO +221150+1133230 Asia/Macau MQ +1436-06105 America/Martinique MT +3554+01431 Europe/Malta MU -2010+05730 Indian/Mauritius -MV +0410+07330 Indian/Maldives +MV,TF +0410+07330 Etc/GMT-5 Maldives, Kerguelen, St Paul I, Amsterdam I MX +1924-09909 America/Mexico_City Central Time MX +2105-08646 America/Cancun Eastern Standard Time - Quintana Roo MX +2058-08937 America/Merida Central Time - Campeche, Yucatán @@ -247,43 +232,37 @@ MX +2934-10425 America/Ojinaga Mountain Time US - Chihuahua (US border) MX +2904-11058 America/Hermosillo Mountain Standard Time - Sonora MX +3232-11701 America/Tijuana Pacific Time US - Baja California MX +2048-10515 America/Bahia_Banderas Central Time - Bahía de Banderas -MY +0310+10142 Asia/Kuala_Lumpur Malaysia (peninsula) -MY +0133+11020 Asia/Kuching Sabah, Sarawak MZ,BI,BW,CD,MW,RW,ZM,ZW -2558+03235 Africa/Maputo Central Africa Time NA -2234+01706 Africa/Windhoek NC -2216+16627 Pacific/Noumea NF -2903+16758 Pacific/Norfolk NG,AO,BJ,CD,CF,CG,CM,GA,GQ,NE +0627+00324 Africa/Lagos West Africa Time NI +1209-08617 America/Managua -NL +5222+00454 Europe/Amsterdam -NO,SJ +5955+01045 Europe/Oslo NP +2743+08519 Asia/Kathmandu NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ,AQ -3652+17446 Pacific/Auckland New Zealand time NZ -4357-17633 Pacific/Chatham Chatham Islands -PA,KY +0858-07932 America/Panama +PA,CA,KY +0858-07932 America/Panama EST - Panama, Cayman, ON (Atikokan), NU (Coral H) PE -1203-07703 America/Lima -PF -1732-14934 Pacific/Tahiti Society Islands +PF -1732-14934 Etc/GMT+10 Society Islands PF -0900-13930 Pacific/Marquesas Marquesas Islands -PF -2308-13457 Pacific/Gambier Gambier Islands -PG -0930+14710 Pacific/Port_Moresby Papua New Guinea (most areas) +PF -2308-13457 Etc/GMT+9 Gambier Islands PG -0613+15534 Pacific/Bougainville Bougainville PH +1435+12100 Asia/Manila PK +2452+06703 Asia/Karachi PL +5215+02100 Europe/Warsaw PM +4703-05620 America/Miquelon PN -2504-13005 Pacific/Pitcairn -PR +182806-0660622 America/Puerto_Rico +PR,AG,CA,AI,AW,BL,BQ,CW,DM,GD,GP,KN,LC,MF,MS,SX,TT,VC,VG,VI +182806-0660622 America/Puerto_Rico AST PS +3130+03428 Asia/Gaza Gaza Strip PS +313200+0350542 Asia/Hebron West Bank PT +3843-00908 Europe/Lisbon Portugal (mainland) PT +3238-01654 Atlantic/Madeira Madeira Islands PT +3744-02540 Atlantic/Azores Azores -PW +0720+13429 Pacific/Palau +PW +0720+13429 Etc/GMT-9 PY -2516-05740 America/Asuncion QA,BH +2517+05132 Asia/Qatar -RE,TF -2052+05528 Indian/Reunion Réunion, Crozet, Scattered Islands RO +4426+02606 Europe/Bucharest RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad @@ -314,12 +293,9 @@ RU +4658+14242 Asia/Sakhalin MSK+08 - Sakhalin Island RU +6728+15343 Asia/Srednekolymsk MSK+08 - Sakha (E); North Kuril Is RU +5301+15839 Asia/Kamchatka MSK+09 - Kamchatka RU +6445+17729 Asia/Anadyr MSK+09 - Bering Sea -SA,KW,YE +2438+04643 Asia/Riyadh -SB -0932+16012 Pacific/Guadalcanal -SC -0440+05528 Indian/Mahe +SB,FM -0932+16012 Etc/GMT-11 Solomons, Pohnpei SD +1536+03232 Africa/Khartoum -SE +5920+01803 Europe/Stockholm -SG +0117+10351 Asia/Singapore +SG,MY +0117+10351 Asia/Singapore Singapore, peninsular Malaysia SR +0550-05510 America/Paramaribo SS +0451+03137 Africa/Juba ST +0020+00644 Africa/Sao_Tome @@ -327,8 +303,6 @@ SV +1342-08912 America/El_Salvador SY +3330+03618 Asia/Damascus TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena -TF -492110+0701303 Indian/Kerguelen Kerguelen, St Paul Island, Amsterdam Island -TH,KH,LA,VN +1345+10031 Asia/Bangkok Indochina (most areas) TJ +3835+06848 Asia/Dushanbe TK -0922-17114 Pacific/Fakaofo TL -0833+12535 Asia/Dili @@ -336,13 +310,10 @@ TM +3757+05823 Asia/Ashgabat TN +3648+01011 Africa/Tunis TO -210800-1751200 Pacific/Tongatapu TR +4101+02858 Europe/Istanbul -TT,AG,AI,BL,DM,GD,GP,KN,LC,MF,MS,VC,VG,VI +1039-06131 America/Port_of_Spain -TV -0831+17913 Pacific/Funafuti TW +2503+12130 Asia/Taipei UA +5026+03031 Europe/Kiev Ukraine (most areas) UA +4837+02218 Europe/Uzhgorod Transcarpathia UA +4750+03510 Europe/Zaporozhye Zaporozhye and east Lugansk -UM +1917+16637 Pacific/Wake Wake Island US +404251-0740023 America/New_York Eastern (most areas) US +421953-0830245 America/Detroit Eastern - MI (most areas) US +381515-0854534 America/Kentucky/Louisville Eastern - KY (Louisville area) @@ -362,7 +333,7 @@ US +465042-1012439 America/North_Dakota/New_Salem Central - ND (Morton rural) US +471551-1014640 America/North_Dakota/Beulah Central - ND (Mercer) US +394421-1045903 America/Denver Mountain (most areas) US +433649-1161209 America/Boise Mountain - ID (south); OR (east) -US +332654-1120424 America/Phoenix MST - Arizona (except Navajo) +US,CA +332654-1120424 America/Phoenix MST - Arizona (except Navajo), Creston BC US +340308-1181434 America/Los_Angeles Pacific US +611305-1495401 America/Anchorage Alaska (most areas) US +581807-1342511 America/Juneau Alaska - Juneau area @@ -378,6 +349,5 @@ UZ +4120+06918 Asia/Tashkent Uzbekistan (east) VE +1030-06656 America/Caracas VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) VU -1740+16825 Pacific/Efate -WF -1318-17610 Pacific/Wallis WS -1350-17144 Pacific/Apia ZA,LS,SZ -2615+02800 Africa/Johannesburg -- 2.27.0
diff --git a/Makefile b/Makefile index 8714c16..ce018ec 100644 --- a/Makefile +++ b/Makefile @@ -529,7 +529,7 @@ TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs TZS_NEW= to$(TZS_YEAR)new.tzs -TZS_DEPS= $(PRIMARY_YDATA) asctime.c localtime.c \ +TZS_DEPS= $(YDATA) asctime.c localtime.c \ private.h tzfile.h zdump.c zic.c # EIGHT_YARDS is just a yard short of the whole ENCHILADA. EIGHT_YARDS = $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) tzdata.zi diff --git a/NEWS b/NEWS index 6d1cd09..435a40f 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,23 @@ Unreleased, experimental changes (Thanks to P Chan, Michael Deckers, Alexander Krivenyshev and Alois Treindl.)
+ Merge timezones whose timestamps agree since 1970, since pre-1970 + timestamps are out of scope. This change does not affect + post-1970 timestamps, and timezone historians who build with 'make + PACKRATDATA=backzone' should see no changes to pre-1970 timestamps. + When merging, keep the most-populous location's data, and move + data for other locations to 'backzone' with a backward + compatibility link in 'backward'. Also, merge timezones with + neither post-1970 clock changes nor alphabetic abbreviations into + their Etc counterparts. For example, move the Europe/Oslo data to + 'backzone' with a link in 'backward' from Europe/Berlin because + the two timezones' timestamps agree since 1970; this change + affects some pre-1966 timestamps in Europe/Oslo because Berlin and + Oslo disagreed before 1966. For another example, move the + Asia/Aden data to 'backzone' with a link in 'backward' from + Etc/GMT-3. Affected entries range from Africa/Abidjan to + Pacific/Yap. + Changes to maintenance procedure
The new file SECURITY covers how to report security-related bugs. diff --git a/backzone b/backzone index 6c77378..b58f4d8 100644 --- a/backzone +++ b/backzone @@ -619,6 +619,8 @@ Zone America/Creston -7:46:04 - LMT 1884 Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad -4:30 - -0430 1965 -4:00 - AST +Link America/Curacao America/Kralendijk +Link America/Curacao America/Lower_Princes
# Dominica Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau @@ -763,6 +765,9 @@ Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 # Trinidad and Tobago Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 -4:00 - AST +Link America/Port_of_Spain America/Marigot +Link America/Port_of_Spain America/St_Barthelemy +Link America/Port_of_Spain America/Virgin
# Argentina # This entry was intended for the following areas, but has been superseded by @@ -1228,6 +1233,7 @@ Rule Iceland 1967 only - Oct 29 1:00s 0 - Zone Atlantic/Reykjavik -1:28 - LMT 1908 -1:00 Iceland -01/+00 1968 Apr 7 1:00s 0:00 - GMT +Link Atlantic/Reykjavik Iceland
# South Georgia Zone Atlantic/South_Georgia -2:26:08 - LMT 1890 # Grytviken @@ -1520,6 +1526,7 @@ Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Norway CE%sT 1980 1:00 EU CE%sT +Link Europe/Oslo Arctic/Longyearbyen
# Bosnia and Herzegovina Zone Europe/Sarajevo 1:13:40 - LMT 1884 @@ -1708,6 +1715,8 @@ Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 10:00 - +10 1941 Apr 1 9:00 - +09 1945 Aug 10:00 - +10 +Link Pacific/Chuuk Pacific/Truk +Link Pacific/Chuuk Pacific/Yap
# Tuvalu Zone Pacific/Funafuti 11:56:52 - LMT 1901 @@ -1767,6 +1776,7 @@ Zone Pacific/Pohnpei -13:27:08 - LMT 1844 Dec 31 # Kolonia 10:00 - +10 1941 Apr 1 9:00 - +09 1945 Aug 11:00 - +11 +Link Pacific/Pohnpei Pacific/Ponape
# Papua New Guinea Zone Pacific/Port_Moresby 9:48:40 - LMT 1880 diff --git a/etcetera b/etcetera index 1dc7411..dc21c4d 100644 --- a/etcetera +++ b/etcetera @@ -12,6 +12,8 @@ # Starting with POSIX 1003.1-2001, the entries below are all # unnecessary as settings for the TZ environment variable. E.g., # instead of TZ='Etc/GMT+4' one can use the POSIX setting TZ='<-04>+4'. +# However, some entries are needed if 'backward' is used: +# for example, the 'backward' file links Etc/GMT to Africa/Abidjan. # # Do not use a POSIX TZ setting like TZ='GMT+4', which is four hours # behind GMT but uses the completely misleading abbreviation "GMT". diff --git a/theory.html b/theory.html index 5251c96..47a7b2d 100644 --- a/theory.html +++ b/theory.html @@ -42,12 +42,13 @@ href="https://en.wikipedia.org/wiki/Unix_time">POSIX Epoch</a> (1970-01-01 00:00:00 <a href="https://en.wikipedia.org/wiki/Coordinated_Universal_Time"><abbr title="Coordinated Universal Time">UTC</abbr></a>). -The database labels each timezone with a notable location and -records all known clock transitions for that 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. +Most timezones correspond to a notable location and the database +records all known clock transitions for that location; +some timezones correspond instead to a fixed <abbr>UTC</abbr> offset. </p>
<p> @@ -68,7 +70,7 @@ time but differs from other timezones for some timestamps after 1970. </p>
<p> -Clock transitions before 1970 are recorded for each timezone, +Clock transitions before 1970 are recorded for location-based timezones, because most systems support timestamps before 1970 and could misbehave if data entries were omitted for pre-1970 transitions. However, the database is not designed for and does not suffice for
-- Magnus Fromreide +46-13 17 68 48 Tornhagsv�gen 24, 2tr magfr@lysator.liu.se SE-582 37 LINK�PING
participants (21)
-
Alois Treindl
-
Arthur David Olson
-
Brian Inglis
-
Clive D.W. Feather
-
David Braverman
-
David Patte
-
Derick Rethans
-
Derick Rethans
-
Guy Harris
-
John Hawkinson
-
Magnus Fromreide
-
Mark Davis ☕️
-
Michael H Deckers
-
Paul Eggert
-
Paul Ganssle
-
Philip Paeps
-
Sanjeev Gupta
-
Steffen Nurpmeso
-
Stephen Colebourne
-
Tim Parenti
-
Tom Lane