Montreal timezone
Dear Sir, Madam, I discovered that you are at the origin of the removal of the Montreal/America timezone and it's integration within Toronto. The problem is that this move to a secondary timezone leads to tons of problems and hours of corrections and explanation (mainly due to quick and dirty implementations of TZ but I cannot blame half of the developers of the planet). The fact that PHP uses this list expose this timezone list to the public. I got many angry comments on this change from French speaking people and Europeans because Toronto is less recognized and known (not to mention loved) than Montreal. We have 8 millions of Quebec people which will drag their feet to adopt (in fact most of them put NY) and probably half of 220 millions francophone who have no idea where Toronto is (like many people know where Geneva is but have no idea where Zurich is). It looks that you do not get that end users use this. I understand the willing of normalization but Toronto will never be significant as TZ name for all Eastern Time in Canada. I think this change has to be reversed, -- Vincent Tourneyrie Vinceti 514 907 9124 Visitez www.vinceti.ca[1] -------- [1] http://www.vinceti.ca
On Wed, Apr 13, 2016, at 22:47, Vincent Tourneyrie wrote:
The problem is that this move to a secondary timezone leads to tons of problems and hours of corrections and explanation (mainly due to quick and dirty implementations of TZ but I cannot blame half of the developers of the planet). The fact that PHP uses this list expose this timezone list to the public.
PHP is a back-end programming language, and doesn't expose anything to the public. I assume you are referring to an application written in PHP. Why does your program expose the timezone names instead of the descriptions from zone.tab - in this case, the current description of America/Toronto is "Eastern - ON, QC (most areas)"? Also, even for a program that does expose timezone names, it's not clear why you can't still display America/Montreal, which appears as a symbolic link created by the backward compatibility file.
On Mon, 18 Apr 2016, Random832 wrote:
On Wed, Apr 13, 2016, at 22:47, Vincent Tourneyrie wrote:
The problem is that this move to a secondary timezone leads to tons of problems and hours of corrections and explanation (mainly due to quick and dirty implementations of TZ but I cannot blame half of the developers of the planet). The fact that PHP uses this list expose this timezone list to the public.
PHP is a back-end programming language, and doesn't expose anything to the public. I assume you are referring to an application written in PHP.
PHP has an internal version of the library, and provides a file for listing all timezone identifiers: http://php.net/manual/en/datetimezone.listidentifiers.php
Why does your program expose the timezone names instead of the descriptions from zone.tab - in this case, the current description of America/Toronto is "Eastern - ON, QC (most areas)"?
And PHP exposes that through: derick@whisky:/tmp $ php -n -r '$tz = new DateTimeZone( "America/Toronto" ); var_dump( $tz->getLocation() );'
Also, even for a program that does expose timezone names, it's not clear why you can't still display America/Montreal, which appears as a symbolic link created by the backward compatibility file.
PHP does not use the on-system zic compiled versions of the database, but as my previous email says, it supports both America/Montreal and America/Toronto just fine. cheers, Derick
On Mon, Apr 18, 2016, at 11:34, Derick Rethans wrote:
PHP has an internal version of the library, and provides a file for listing all timezone identifiers: http://php.net/manual/en/datetimezone.listidentifiers.php
Yes, but it's the application's decision, not PHP's, to expose the output of that function to the public, rather than the output of the getLocation function you mentioned below..
Why does your program expose the timezone names instead of the descriptions from zone.tab - in this case, the current description of America/Toronto is "Eastern - ON, QC (most areas)"?
And PHP exposes that through:
derick@whisky:/tmp $ php -n -r '$tz = new DateTimeZone( "America/Toronto" ); var_dump( $tz->getLocation() );'
From the recent thread on Montreal:
Why does your program expose the timezone names instead of the descriptions from zone.tab - in this case, the current description of America/Toronto is "Eastern - ON, QC (most areas)"?
I find it frustrating that we continue to give this as general advice. The problem is, using zone.tab alone (or zone1970.tab) is an incomplete solution. We tell folks to use not show IDs to their end users, but most platforms and libraries only have methods for iterating the IDs, and those that do show zone.tab comments only show them in English - because that's all that we provide. To my knowledge, there is no project that maintains localized translations for comments in zone.tab. Not even CLDR. So when we tell folks not to show the time zone names - we aren't really giving them a viable alternative. Have anyone else actually tried to build a multilingual time zone selection control? I have, and it was extremely difficult. I'd appreciate feedback, if anyone wants to try it out: http://timezonepickerdemo.azurewebsites.net/ This uses CLDR data for localization, using their generic-long form form. This is a problem in isolation because, for example, one cannot easily distinguish between America/Phoenix and America/Denver because both have the same generic-long form of "Mountain Time". Significant other ambiguities exist. The only solution I've been able to derive is to show "Mountain Time (Phoenix)" and "Mountain Time (Denver)", which is nonstandard by the CLDR spec. Additionally, one has to consider the context of the scenario. If I'm only picking a time zone for scheduling future events, it's a bit ridiculous to show the list of Indiana time zones and other historical differences. Just because we have zone splits going back to 1970 doesn't mean that every application is concerned with data going back that far. So to handle this concern, I've computed a "threshold date" for each zone, where the zones are identical from the threshold date forward. That date can be set by the developer of the application to limit the subset of zones to choose from without imposing too much opinion. I'm curious if anyone else has explored this space before, or used similar techniques? Thanks, Matt
On 04/18/2016 09:04 AM, Matt Johnson wrote:
To my knowledge, there is no project that maintains localized translations for comments in zone.tab. Not even CLDR.
I don't know of any either. Perhaps CLDR could take this on too?
I've computed a "threshold date" for each zone, where the zones are identical from the threshold date forward. That date can be set by the developer of the application to limit the subset of zones to choose from without imposing too much opinion. I'm curious if anyone else has explored this space before, or used similar techniques?
I did something along those lines, but gave up on it as being too hard to automate well. For example, if the threshold is 2001-01-01 00:00:00 UTC, then we should merge America/Boise, America/Denver, America/Edmonton, and America/Yellowknife. How does the automated procedure choose the ID of the merged region? It should be America/Denver, as that has the greatest population, but how is the population recorded and what happens as population changes? Furthermore, how does the automated procedure derive the comment for the merged region? And how would CLDR translate this automatically-derived comment? For this reason I'm somewhat inclined to add one more hand-maintained table, zone-now.tab, which is like zone-1970.tab except using a cutoff of "now" (a deliberatly moving target) instead of a cutoff of 1970. That should be good enough for applications that don't need historical time stamps, and will be easier to automate and CLDRize.
On 18/04/16 18:52, Paul Eggert wrote:
For this reason I'm somewhat inclined to add one more hand-maintained table, zone-now.tab, which is like zone-1970.tab except using a cutoff of "now" (a deliberatly moving target) instead of a cutoff of 1970. That should be good enough for applications that don't need historical time stamps, and will be easier to automate and CLDRize.
I don't think such dynamic target would be appropiate. It wouldn't even be correct for storing the meeting you had last week. I agree a file like zone-2000.tab or zone-2010.tab would be useful because the actual set of applicable zones will actually be smaller. However, I am wary of hand-maintaining it. It seems automatable with "a bit of help" for breaking ties.
How does the automated procedure choose the ID of the merged region? It should be America/Denver, as that has the greatest population, but how is the population recorded and what happens as population changes? Why not use the oldest ID for the merged region? (oldest as in earlier to have been introduced in the Olson db). The other names should be aliases, anyway.
Furthermore, how does the automated procedure derive the comment for the merged region? Not ideal, but with a few linguistic rules, it could combine the comments into something acceptable.
And how would CLDR translate this automatically-derived comment? Periodically syncronize the translations? It's not that it would be different with a manually-maintained file.
Best
I'm somewhat inclined to add one more hand-maintained table, zone-now.tab, which is like zone-1970.tab except using a cutoff of "now"...
Since time zone version 2 files end with POSIX-style strings, it may be possible to automate the generation of zone-now.tab from zone-1970.tab: slurp the lines of zone-1970.tab for each line describes a zone, get the associated POSIX-style string output each zone-1970.tab line, except for the second and subsequent lines associated with a particular POSIX-style string. This would undoubtedly lead to some unwanted mergers, so an exception mechanism (presumably in the form of magic zone-1970.tab comments) would be needed. As a start, here's a script that runs through a time zone binary directory and tells which files are associated with which POSIX-style strings: #!/bin/perl if ($#ARGV != 0) { die("$0: usage is $0 dir"); } $dir = $ARGV[0]; chdir ($dir) || die("cannot chdir $dir"); for (`find * -type f`) { s@[\r\n]@@; $zone = $_; open(S, "<$_") || next; if (<S> =~ /^TZif2/) { $last = ""; while (<S>) { $posix = $_; } $posix =~ s@[\r\n]@@; if ($zones{$posix} ne "") { $zones{$posix} .= " "; } $zones{$posix} .= $zone; ++$counts{$posix}; } close(S); } for $posix (sort keys %zones) { print "\"$posix\"\t$counts{$posix}\t$zones{$posix}\r\n"; } Below find the resullts of the above applied to a recent time zone binary directory. @dashdashado "<+04>-4" 2 Europe/Astrakhan Europe/Ulyanovsk "<+07>-7" 1 Asia/Barnaul "<GMT+10>10" 1 Etc/GMT+10 "<GMT+11>11" 1 Etc/GMT+11 "<GMT+12>12" 1 Etc/GMT+12 "<GMT+1>1" 1 Etc/GMT+1 "<GMT+2>2" 1 Etc/GMT+2 "<GMT+3>3" 1 Etc/GMT+3 "<GMT+4>4" 1 Etc/GMT+4 "<GMT+5>5" 1 Etc/GMT+5 "<GMT+6>6" 1 Etc/GMT+6 "<GMT+7>7" 1 Etc/GMT+7 "<GMT+8>8" 1 Etc/GMT+8 "<GMT+9>9" 1 Etc/GMT+9 "<GMT-10>-10" 1 Etc/GMT-10 "<GMT-11>-11" 1 Etc/GMT-11 "<GMT-12>-12" 1 Etc/GMT-12 "<GMT-13>-13" 1 Etc/GMT-13 "<GMT-14>-14" 1 Etc/GMT-14 "<GMT-1>-1" 1 Etc/GMT-1 "<GMT-2>-2" 1 Etc/GMT-2 "<GMT-3>-3" 1 Etc/GMT-3 "<GMT-4>-4" 1 Etc/GMT-4 "<GMT-5>-5" 1 Etc/GMT-5 "<GMT-6>-6" 1 Etc/GMT-6 "<GMT-7>-7" 1 Etc/GMT-7 "<GMT-8>-8" 1 Etc/GMT-8 "<GMT-9>-9" 1 Etc/GMT-9 "<Local time zone must be set--see zic manual page>0" 1 Factory "ACST-9:30" 2 Australia/Darwin Australia/North "ACST-9:30ACDT,M10.1.0,M4.1.0/3" 4 Australia/Adelaide Australia/Broken_Hill Australia/South Australia/Yancowinna "ACT5" 4 America/Eirunepe America/Porto_Acre America/Rio_Branco Brazil/Acre "ACWST-8:45" 1 Australia/Eucla "AEST-10" 3 Australia/Brisbane Australia/Lindeman Australia/Queensland "AEST-10AEDT,M10.1.0,M4.1.0/3" 9 Australia/ACT Australia/Canberra Australia/Currie Australia/Hobart Australia/Melbourne Australia/NSW Australia/Sydney Australia/Tasmania Australia/Victoria "AFT-4:30" 1 Asia/Kabul "AKST9AKDT,M3.2.0,M11.1.0" 7 America/Anchorage America/Juneau America/Metlakatla America/Nome America/Sitka America/Yakutat US/Alaska "ALMT-6" 1 Asia/Almaty "AMT-4" 1 Asia/Yerevan "AMT4" 4 America/Boa_Vista America/Manaus America/Porto_Velho Brazil/West "AMT4AMST,M10.3.0/0,M2.3.0/0" 2 America/Campo_Grande America/Cuiaba "ANAT-12" 1 Asia/Anadyr "AQTT-5" 2 Asia/Aqtau Asia/Aqtobe "ART3" 19 America/Argentina/Buenos_Aires America/Argentina/Catamarca America/Argentina/ComodRivadavia America/Argentina/Cordoba America/Argentina/Jujuy America/Argentina/La_Rioja America/Argentina/Mendoza America/Argentina/Rio_Gallegos America/Argentina/Salta America/Argentina/San_Juan America/Argentina/San_Luis America/Argentina/Tucuman America/Argentina/Ushuaia America/Buenos_Aires America/Catamarca America/Cordoba America/Jujuy America/Mendoza America/Rosario "AST-3" 6 Asia/Aden Asia/Baghdad Asia/Bahrain Asia/Kuwait Asia/Qatar Asia/Riyadh "AST4" 25 America/Anguilla America/Antigua America/Aruba America/Barbados America/Blanc-Sablon America/Curacao America/Dominica America/Grand_Turk America/Grenada America/Guadeloupe America/Kralendijk America/Lower_Princes America/Marigot America/Martinique America/Montserrat America/Port_of_Spain America/Puerto_Rico America/Santo_Domingo America/St_Barthelemy America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tortola America/Virgin "AST4ADT,M3.2.0,M11.1.0" 7 America/Glace_Bay America/Goose_Bay America/Halifax America/Moncton America/Thule Atlantic/Bermuda Canada/Atlantic "AWST-8" 3 Antarctica/Casey Australia/Perth Australia/West "AZOT1AZOST,M3.5.0/0,M10.5.0/1" 1 Atlantic/Azores "AZT-4AZST,M3.5.0/4,M10.5.0/5" 1 Asia/Baku "BDT-6" 2 Asia/Dacca Asia/Dhaka "BNT-8" 1 Asia/Brunei "BOT4" 1 America/La_Paz "BRT3" 7 America/Araguaina America/Bahia America/Belem America/Fortaleza America/Maceio America/Recife America/Santarem "BRT3BRST,M10.3.0/0,M2.3.0/0" 2 America/Sao_Paulo Brazil/East "BST-11" 1 Pacific/Bougainville "BTT-6" 2 Asia/Thimbu Asia/Thimphu "CAT-2" 8 Africa/Blantyre Africa/Bujumbura Africa/Gaborone Africa/Harare Africa/Kigali Africa/Lubumbashi Africa/Lusaka Africa/Maputo "CCT-6:30" 1 Indian/Cocos "CET-1" 2 Africa/Algiers Africa/Tunis "CET-1CEST,M3.5.0,M10.5.0/3" 36 Africa/Ceuta Arctic/Longyearbyen Atlantic/Jan_Mayen CET Europe/Amsterdam Europe/Andorra Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Budapest Europe/Busingen Europe/Copenhagen Europe/Gibraltar Europe/Ljubljana Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Monaco Europe/Oslo Europe/Paris Europe/Podgorica Europe/Prague Europe/Rome Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Stockholm Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Warsaw Europe/Zagreb Europe/Zurich Poland "CHAST-12:45CHADT,M9.5.0/2:45,M4.1.0/3:45" 2 NZ-CHAT Pacific/Chatham "CHOT-8CHOST,M3.5.6,M9.5.6/0" 1 Asia/Choibalsan "CHUT-10" 3 Pacific/Chuuk Pacific/Truk Pacific/Yap "CKT10" 1 Pacific/Rarotonga "CLT3" 3 America/Santiago Antarctica/Palmer Chile/Continental "COT5" 1 America/Bogota "CST-8" 9 Asia/Chongqing Asia/Chungking Asia/Harbin Asia/Macao Asia/Macau Asia/Shanghai Asia/Taipei PRC ROC "CST5CDT,M3.2.0/0,M11.1.0/1" 2 America/Havana Cuba "CST6" 10 America/Belize America/Costa_Rica America/El_Salvador America/Guatemala America/Managua America/Regina America/Swift_Current America/Tegucigalpa Canada/East-Saskatchewan Canada/Saskatchewan "CST6CDT,M3.2.0,M11.1.0" 17 America/Chicago America/Indiana/Knox America/Indiana/Tell_City America/Knox_IN America/Matamoros America/Menominee America/North_Dakota/Beulah America/North_Dakota/Center America/North_Dakota/New_Salem America/Rainy_River America/Rankin_Inlet America/Resolute America/Winnipeg Canada/Central CST6CDT US/Central US/Indiana-Starke "CST6CDT,M4.1.0,M10.5.0" 5 America/Bahia_Banderas America/Merida America/Mexico_City America/Monterrey Mexico/General "CVT1" 1 Atlantic/Cape_Verde "CXT-7" 1 Indian/Christmas "ChST-10" 2 Pacific/Guam Pacific/Saipan "DAVT-7" 1 Antarctica/Davis "DDUT-10" 1 Antarctica/DumontDUrville "EAST5" 2 Chile/EasterIsland Pacific/Easter "EAT-3" 13 Africa/Addis_Ababa Africa/Asmara Africa/Asmera Africa/Dar_es_Salaam Africa/Djibouti Africa/Juba Africa/Kampala Africa/Khartoum Africa/Mogadishu Africa/Nairobi Indian/Antananarivo Indian/Comoro Indian/Mayotte "ECT5" 1 America/Guayaquil "EET-2" 5 Africa/Cairo Africa/Tripoli Egypt Europe/Kaliningrad Libya "EET-2EEST,M3.5.0,M10.5.0/3" 2 Europe/Chisinau Europe/Tiraspol "EET-2EEST,M3.5.0/0,M10.5.0/0" 1 Asia/Beirut "EET-2EEST,M3.5.0/3,M10.5.0/4" 17 Asia/Istanbul Asia/Nicosia EET Europe/Athens Europe/Bucharest Europe/Helsinki Europe/Istanbul Europe/Kiev Europe/Mariehamn Europe/Nicosia Europe/Riga Europe/Sofia Europe/Tallinn Europe/Uzhgorod Europe/Vilnius Europe/Zaporozhye Turkey "EET-2EEST,M3.5.4/24,M10.5.5/1" 1 Asia/Amman "EET-2EEST,M3.5.5/0,M10.5.5/0" 1 Asia/Damascus "EGT1EGST,M3.5.0/0,M10.5.0/1" 1 America/Scoresbysund "EST5" 8 America/Atikokan America/Cancun America/Cayman America/Coral_Harbour America/Jamaica America/Panama EST Jamaica "EST5EDT,M3.2.0,M11.1.0" 27 America/Detroit America/Fort_Wayne America/Indiana/Indianapolis America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Indiana/Vincennes America/Indiana/Winamac America/Indianapolis America/Iqaluit America/Kentucky/Louisville America/Kentucky/Monticello America/Louisville America/Montreal America/Nassau America/New_York America/Nipigon America/Pangnirtung America/Port-au-Prince America/Thunder_Bay America/Toronto Canada/Eastern EST5EDT posixrules US/East-Indiana US/Eastern US/Michigan "FJT-12FJST,M11.1.0,M1.3.0/3" 1 Pacific/Fiji "FKST3" 1 Atlantic/Stanley "FNT2" 2 America/Noronha Brazil/DeNoronha "GALT6" 1 Pacific/Galapagos "GAMT9" 1 Pacific/Gambier "GET-4" 1 Asia/Tbilisi "GFT3" 1 America/Cayenne "GILT-12" 1 Pacific/Tarawa "GMT0" 29 Africa/Abidjan Africa/Accra Africa/Bamako Africa/Banjul Africa/Bissau Africa/Conakry Africa/Dakar Africa/Freetown Africa/Lome Africa/Monrovia Africa/Nouakchott Africa/Ouagadougou Africa/Sao_Tome Africa/Timbuktu America/Danmarkshavn Atlantic/Reykjavik Atlantic/St_Helena Etc/GMT Etc/GMT+0 Etc/GMT-0 Etc/GMT0 Etc/Greenwich GMT GMT+0 GMT0 GMT-0 Greenwich Iceland localtime "GMT0BST,M3.5.0/1,M10.5.0" 7 Europe/Belfast Europe/Guernsey Europe/Isle_of_Man Europe/Jersey Europe/London GB GB-Eire "GMT0IST,M3.5.0/1,M10.5.0" 2 Eire Europe/Dublin "GST-4" 2 Asia/Dubai Asia/Muscat "GST2" 1 Atlantic/South_Georgia "GYT4" 1 America/Guyana "HKT-8" 2 Asia/Hong_Kong Hongkong "HOVT-7HOVST,M3.5.6,M9.5.6/0" 1 Asia/Hovd "HST10" 4 HST Pacific/Honolulu Pacific/Johnston US/Hawaii "HST10HDT,M3.2.0,M11.1.0" 3 America/Adak America/Atka US/Aleutian "ICT-7" 5 Asia/Bangkok Asia/Ho_Chi_Minh Asia/Phnom_Penh Asia/Saigon Asia/Vientiane "IOT-6" 1 Indian/Chagos "IRKT-8" 1 Asia/Irkutsk "IRST-3:30IRDT,J80/0,J264/0" 2 Asia/Tehran Iran "IST-5:30" 3 Asia/Calcutta Asia/Colombo Asia/Kolkata "JST-9" 2 Asia/Tokyo Japan "KGT-6" 1 Asia/Bishkek "KOST-11" 1 Pacific/Kosrae "KRAT-7" 2 Asia/Krasnoyarsk Asia/Novokuznetsk "KST-8:30" 1 Asia/Pyongyang "KST-9" 2 Asia/Seoul ROK "LHST-10:30LHDT-11,M10.1.0,M4.1.0" 2 Australia/LHI Australia/Lord_Howe "LINT-14" 1 Pacific/Kiritimati "MAGT-10" 1 Asia/Magadan "MART9:30" 1 Pacific/Marquesas "MAWT-5" 1 Antarctica/Mawson "MET-1MEST,M3.5.0,M10.5.0/3" 1 MET "MHT-12" 3 Kwajalein Pacific/Kwajalein Pacific/Majuro "MIST-11" 1 Antarctica/Macquarie "MMT-6:30" 1 Asia/Rangoon "MSK-3" 5 Europe/Minsk Europe/Moscow Europe/Simferopol Europe/Volgograd W-SU "MST7" 7 America/Creston America/Dawson_Creek America/Fort_Nelson America/Hermosillo America/Phoenix MST US/Arizona "MST7MDT,M3.2.0,M11.1.0" 12 America/Boise America/Cambridge_Bay America/Denver America/Edmonton America/Inuvik America/Ojinaga America/Shiprock America/Yellowknife Canada/Mountain MST7MDT Navajo US/Mountain "MST7MDT,M4.1.0,M10.5.0" 3 America/Chihuahua America/Mazatlan Mexico/BajaSur "MUT-4" 1 Indian/Mauritius "MVT-5" 1 Indian/Maldives "MYT-8" 2 Asia/Kuala_Lumpur Asia/Kuching "NCT-11" 1 Pacific/Noumea "NFT-11" 1 Pacific/Norfolk "NOVT-6" 1 Asia/Novosibirsk "NPT-5:45" 2 Asia/Kathmandu Asia/Katmandu "NRT-12" 1 Pacific/Nauru "NST3:30NDT,M3.2.0,M11.1.0" 2 America/St_Johns Canada/Newfoundland "NUT11" 1 Pacific/Niue "NZST-12NZDT,M9.5.0,M4.1.0/3" 4 Antarctica/McMurdo Antarctica/South_Pole NZ Pacific/Auckland "OMST-6" 1 Asia/Omsk "ORAT-5" 1 Asia/Oral "PET5" 1 America/Lima "PETT-12" 1 Asia/Kamchatka "PGT-10" 1 Pacific/Port_Moresby "PHOT-13" 1 Pacific/Enderbury "PHT-8" 1 Asia/Manila "PKT-5" 1 Asia/Karachi "PMST3PMDT,M3.2.0,M11.1.0" 1 America/Miquelon "PONT-11" 2 Pacific/Pohnpei Pacific/Ponape "PST8" 1 Pacific/Pitcairn "PST8PDT,M3.2.0,M11.1.0" 13 America/Dawson America/Ensenada America/Los_Angeles America/Santa_Isabel America/Tijuana America/Vancouver America/Whitehorse Canada/Pacific Canada/Yukon Mexico/BajaNorte PST8PDT US/Pacific US/Pacific-New "PWT-9" 1 Pacific/Palau "PYT4PYST,M10.1.0/0,M3.4.0/0" 1 America/Asuncion "QYZT-6" 1 Asia/Qyzylorda "RET-4" 1 Indian/Reunion "ROTT3" 1 Antarctica/Rothera "SAKT-11" 1 Asia/Sakhalin "SAMT-4" 1 Europe/Samara "SAST-2" 3 Africa/Johannesburg Africa/Maseru Africa/Mbabane "SBT-11" 1 Pacific/Guadalcanal "SCT-4" 1 Indian/Mahe "SGT-8" 2 Asia/Singapore Singapore "SRET-11" 1 Asia/Srednekolymsk "SRT3" 1 America/Paramaribo "SST11" 4 Pacific/Midway Pacific/Pago_Pago Pacific/Samoa US/Samoa "SYOT-3" 1 Antarctica/Syowa "TAHT10" 1 Pacific/Tahiti "TFT-5" 1 Indian/Kerguelen "TJT-5" 1 Asia/Dushanbe "TKT-13" 1 Pacific/Fakaofo "TLT-9" 1 Asia/Dili "TMT-5" 2 Asia/Ashgabat Asia/Ashkhabad "TOT-13" 1 Pacific/Tongatapu "TVT-12" 1 Pacific/Funafuti "UCT0" 2 Etc/UCT UCT "ULAT-8ULAST,M3.5.6,M9.5.6/0" 2 Asia/Ulaanbaatar Asia/Ulan_Bator "UTC0" 6 Etc/Universal Etc/UTC Etc/Zulu Universal UTC Zulu "UTC0CEST-2,M3.5.0/1,M10.5.0/3" 1 Antarctica/Troll "UYT3" 1 America/Montevideo "UZT-5" 2 Asia/Samarkand Asia/Tashkent "VET4:30" 1 America/Caracas "VLAT-10" 2 Asia/Ust-Nera Asia/Vladivostok "VOST-6" 1 Antarctica/Vostok "VUT-11" 1 Pacific/Efate "WAKT-12" 1 Pacific/Wake "WAT-1" 11 Africa/Bangui Africa/Brazzaville Africa/Douala Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Luanda Africa/Malabo Africa/Ndjamena Africa/Niamey Africa/Porto-Novo "WAT-1WAST,M9.1.0,M4.1.0" 1 Africa/Windhoek "WET0WEST,M3.5.0,M10.5.0/3" 2 Africa/Casablanca Africa/El_Aaiun "WET0WEST,M3.5.0/1,M10.5.0" 7 Atlantic/Canary Atlantic/Faeroe Atlantic/Faroe Atlantic/Madeira Europe/Lisbon Portugal WET "WFT-12" 1 Pacific/Wallis "WIB-7" 2 Asia/Jakarta Asia/Pontianak "WIT-9" 1 Asia/Jayapura "WITA-8" 2 Asia/Makassar Asia/Ujung_Pandang "WSST-13WSDT,M9.5.0/3,M4.1.0/4" 1 Pacific/Apia "XJT-6" 2 Asia/Kashgar Asia/Urumqi "YAKT-9" 3 Asia/Chita Asia/Khandyga Asia/Yakutsk "YEKT-5" 1 Asia/Yekaterinburg On Mon, Apr 18, 2016 at 12:52 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 04/18/2016 09:04 AM, Matt Johnson wrote:
To my knowledge, there is no project that maintains localized translations for comments in zone.tab. Not even CLDR.
I don't know of any either. Perhaps CLDR could take this on too?
I've computed a "threshold date" for each zone, where the zones are
identical from the threshold date forward. That date can be set by the developer of the application to limit the subset of zones to choose from without imposing too much opinion. I'm curious if anyone else has explored this space before, or used similar techniques?
I did something along those lines, but gave up on it as being too hard to automate well. For example, if the threshold is 2001-01-01 00:00:00 UTC, then we should merge America/Boise, America/Denver, America/Edmonton, and America/Yellowknife. How does the automated procedure choose the ID of the merged region? It should be America/Denver, as that has the greatest population, but how is the population recorded and what happens as population changes? Furthermore, how does the automated procedure derive the comment for the merged region? And how would CLDR translate this automatically-derived comment?
For this reason I'm somewhat inclined to add one more hand-maintained table, zone-now.tab, which is like zone-1970.tab except using a cutoff of "now" (a deliberatly moving target) instead of a cutoff of 1970. That should be good enough for applications that don't need historical time stamps, and will be easier to automate and CLDRize.
I don't really like the zone-now.tab idea, because it would just reflect things as of the date of the tzdata release, which is somewhat arbitrary with respect to the scenario. What would really be useful, at least for me, would be if the tzdata had a separate file that recorded the zone splits. It would include the original time zone, the new time zone, and the timestamp of when the split occurred. So using the last few Russian splits as examples: # ZONE SPLIT_FROM TIMESTAMP Asia/Tomsk Asia/Novosibirsk 2016-05-29T02:00+06:00 Europe/Astrakhan Europe/Volgograd 2016-03-27T02:00+02:00 Europe/Ulyanovsk Europe/Moscow 2016-03-27T02:00+02:00 Asia/Barnaul Asia/Omsk 2016-03-27T02:00+06:00 This wouldn't be too difficult to derive, as most of the information is already in the news announcements -Matt ________________________________________ From: Paul Eggert <eggert@cs.ucla.edu> Sent: Monday, April 18, 2016 9:52 AM To: Matt Johnson; Time Zone Mailing List Subject: Re: [tz] Time zone selection On 04/18/2016 09:04 AM, Matt Johnson wrote:
To my knowledge, there is no project that maintains localized translations for comments in zone.tab. Not even CLDR.
I don't know of any either. Perhaps CLDR could take this on too?
I've computed a "threshold date" for each zone, where the zones are identical from the threshold date forward. That date can be set by the developer of the application to limit the subset of zones to choose from without imposing too much opinion. I'm curious if anyone else has explored this space before, or used similar techniques?
I did something along those lines, but gave up on it as being too hard to automate well. For example, if the threshold is 2001-01-01 00:00:00 UTC, then we should merge America/Boise, America/Denver, America/Edmonton, and America/Yellowknife. How does the automated procedure choose the ID of the merged region? It should be America/Denver, as that has the greatest population, but how is the population recorded and what happens as population changes? Furthermore, how does the automated procedure derive the comment for the merged region? And how would CLDR translate this automatically-derived comment? For this reason I'm somewhat inclined to add one more hand-maintained table, zone-now.tab, which is like zone-1970.tab except using a cutoff of "now" (a deliberatly moving target) instead of a cutoff of 1970. That should be good enough for applications that don't need historical time stamps, and will be easier to automate and CLDRize.
On Fri, Apr 22, 2016, at 12:04, Matt Johnson wrote:
I don't really like the zone-now.tab idea, because it would just reflect things as of the date of the tzdata release, which is somewhat arbitrary with respect to the scenario.
How is that different from the fact that literally everything else in the release reflects things as of the date of the release? The point is that the zones that are "merged" are _obsolete_, and therefore no-one who newly selects their timezone after that date "should" be using them anymore if they don't need historical timestamps.
Well, "historical" as of when? Let's assume we had zone-now.tab already and follow Asia/Tomsk as an example. It would show up in the list in 2016d as it was added. Let's say 2016e doesn't come out until June, at that point it would be removed from the list because it's only historical since there's another Russian zone with the same fixed offset. So how useful is this really? Let me amend my previous suggestion, as I had it backwards. For purposes of time zone selection, it's not the split date that is important, but rather the "merge date". That is, "from X date forward, zone A is identical to zone B". Then each individual developer can decided what the earliest date is that they care about, and omit zones that are identical since that date. So for example: # ZONE SAME_AS FROM_TIMESTAMP Asia/Tomsk Asia/Krasnoyarsk 2016-05-29T03:00+07:00 Europe/Astrakhan Europe/Samara 2016-03-27T03:00+03:00 Europe/Ulyanovsk Europe/Samara 2016-03-27T03:00+03:00 Asia/Barnaul Asia/Novosibirsk 2016-03-27T03:00+07:00 We could still consider tracking the split date as well, but that would be more useful for working with historical data (dates before the split date). ________________________________________ From: tz-bounces@iana.org <tz-bounces@iana.org> on behalf of Random832 <random832@fastmail.com> Sent: Friday, April 22, 2016 9:13 AM To: tz@iana.org Subject: Re: [tz] Time zone selection On Fri, Apr 22, 2016, at 12:04, Matt Johnson wrote:
I don't really like the zone-now.tab idea, because it would just reflect things as of the date of the tzdata release, which is somewhat arbitrary with respect to the scenario.
How is that different from the fact that literally everything else in the release reflects things as of the date of the release? The point is that the zones that are "merged" are _obsolete_, and therefore no-one who newly selects their timezone after that date "should" be using them anymore if they don't need historical timestamps.
On Fri, Apr 22, 2016, at 13:42, Matt Johnson wrote:
Well, "historical" as of when? Let's assume we had zone-now.tab already and follow Asia/Tomsk as an example. It would show up in the list in 2016d as it was added. Let's say 2016e doesn't come out until June, at that point it would be removed from the list because it's only historical since there's another Russian zone with the same fixed offset. So how useful is this really?
I don't think Asia/Tomsk should be added to zone-now.tab, in this situation. It is *born* as a "historical purposes" zone, and should never be presented as an option for someone configuring a new system and not caring about historical timestamps. Basically (to put it on grounds I am more familiar with), if some county in northwest Indiana switches from Eastern to Central time, as they are wont to do, the new zones are created for people who care about historical timestamps, but for people who don't they should simply switch from America/New_York to America/Chicago without ever glancing at the America/Indiana/* directory.
On 04/22/2016 11:36 AM, Random832 wrote:
Basically (to put it on grounds I am more familiar with), if some county in northwest Indiana switches from Eastern to Central time, as they are wont to do, the new zones are created for people who care about historical timestamps, but for people who don't they should simply switch from America/New_York to America/Chicago without ever glancing at the America/Indiana/* directory.
Yes, that was the intent of zone-now.tab. It should be immune to minor changes like these. Admittedly this differs a bit from my original description of zone-now.tab. Perhaps it should be given a less-loaded name, to indicate that it's intended for easy settings rather than strictly all future settings. 'zoneeasy.tab', say. (I can't resist the temptation of also suggesting the name 'zonetheless.tab'...)
On 22/04/16 17:13, Random832 wrote:
On Fri, Apr 22, 2016, at 12:04, Matt Johnson wrote:
I don't really like the zone-now.tab idea, because it would just reflect things as of the date of the tzdata release, which is somewhat arbitrary with respect to the scenario. How is that different from the fact that literally everything else in the release reflects things as of the date of the release?
The point is that the zones that are "merged" are _obsolete_, and therefore no-one who newly selects their timezone after that date "should" be using them anymore if they don't need historical timestamps.
One of the complaints has been that there are too many sets of timezone rules, but combining several zones that NOW have the same set of rules misses the point that there IS a lot of historic material and looking back at even just as far as the 2nd world war requires subtle differences. It would seem that the historic changes in Russian locations are also now getting accurate amendments to the rules, and simply hiding that information in 'backzone' needs to be clearly displayed when people using calendars that have 'simplified things' by stripping anything prior to 1970. Something substantial to prevent users from being given any offsets when the data is not available. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On 2016-04-22 11:44, Lester Caine wrote:
One of the complaints has been that there are too many sets of timezone rules, but combining several zones that NOW have the same set of rules misses the point that there IS a lot of historic material and looking back at even just as far as the 2nd world war requires subtle differences. It would seem that the historic changes in Russian locations are also now getting accurate amendments to the rules, and simply hiding that information in 'backzone' needs to be clearly displayed when people using calendars that have 'simplified things' by stripping anything prior to 1970. Something substantial to prevent users from being given any offsets when the data is not available.
Return -1 for all dates prior to the epoch if zone1970.tab was used to build? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 22/04/16 19:52, Brian Inglis wrote:
On 2016-04-22 11:44, Lester Caine wrote:
One of the complaints has been that there are too many sets of timezone rules, but combining several zones that NOW have the same set of rules misses the point that there IS a lot of historic material and looking back at even just as far as the 2nd world war requires subtle differences. It would seem that the historic changes in Russian locations are also now getting accurate amendments to the rules, and simply hiding that information in 'backzone' needs to be clearly displayed when people using calendars that have 'simplified things' by stripping anything prior to 1970. Something substantial to prevent users from being given any offsets when the data is not available.
Return -1 for all dates prior to the epoch if zone1970.tab was used to build?
That would at least warn that a time zone offset is not reliably available. The one thing that we were trying to get people to understand on the tzdist list is that a key element of this is not just the offset, but that you know just which set of rules was used to create an historic normalized calendar. A lot of historic material has had to be completely reworked simply because we do not KNOW which tz data used at the time. The example of a US location changing timezone currently means that any normalized data on the computers in the 'affected' area needs to retain the rule set for the previous period and recalculate the diary for the coming period. So you need a rule set which contains ALL the correct data. Otherwise you have to have a diary that knows which rule set was used for which part of the data ... Yesterday is history just as much as pre-1970 ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Apr 18, 2016, at 9:04 AM, Matt Johnson <mj1856@hotmail.com> wrote:
From the recent thread on Montreal:
Why does your program expose the timezone names instead of the descriptions from zone.tab - in this case, the current description of America/Toronto is "Eastern - ON, QC (most areas)"?
I find it frustrating that we continue to give this as general advice. The problem is, using zone.tab alone (or zone1970.tab) is an incomplete solution. We tell folks to use not show IDs to their end users, but most platforms and libraries only have methods for iterating the IDs, and those that do show zone.tab comments only show them in English - because that's all that we provide. To my knowledge, there is no project that maintains localized translations for comments in zone.tab. Not even CLDR. So when we tell folks not to show the time zone names - we aren't really giving them a viable alternative.
Have anyone else actually tried to build a multilingual time zone selection control?
Apple's built multilingual time zone selectors; one is part of System Preferences on OS X, and one is part of Settings on iOS. (There are probably others in watchOS and in Apple TV Software/tvOS.)
I have, and it was extremely difficult. I'd appreciate feedback, if anyone wants to try it out: http://timezonepickerdemo.azurewebsites.net/ This uses CLDR data for localization, using their generic-long form form. This is a problem in isolation because, for example, one cannot easily distinguish between America/Phoenix and America/Denver because both have the same generic-long form of "Mountain Time". Significant other ambiguities exist. The only solution I've been able to derive is to show "Mountain Time (Phoenix)" and "Mountain Time (Denver)", which is nonstandard by the CLDR spec.
The OS X selector lets you select either by 1) dragging a blue dot to the appropriate location - it shows a world map, with some region containing the dot highlighted (it's not a tzdb zone, as it includes more than one tzdb zone - Deborah, any idea what those regions are?); 2) selecting a nearby city from a combo box (you can either select an item or type a name; it appears to do a fuzzy search of some sort when you type a name - "Cowabunga" found Cwmbran in the UK - but it has a limited number of cities, so "Weed" found Weert in the Netherlands rather than Weed in California). It displays the *current* localized time zone name (so it distinguishes between standard and daylight savings/summer time), but doesn't distinguish between different tzdb regions that use "Mountain Time" - if daylight savings time isn't in effect, selecting Phoenix or Denver will both report the localized version of "Mountain Standard Time". The iOS selector lacks the fancy GUI part; it just lets you enter a city name and search (and fails to find anything for "Weed"). Both OSes also offer the option of letting the machine select the zone automatically based on its location.
Additionally, one has to consider the context of the scenario. If I'm only picking a time zone for scheduling future events, it's a bit ridiculous to show the list of Indiana time zones and other historical differences.
The Apple selectors don't work on zones, they work on cities.
On 19 Apr 2016, at 4:58 am, Guy Harris <guy@alum.mit.edu> wrote:
The OS X selector lets you select either by
1) dragging a blue dot to the appropriate location - it shows a world map, with some region containing the dot highlighted (it's not a tzdb zone, as it includes more than one tzdb zone - Deborah, any idea what those regions are?);
I’m happy for Deborah to correct me, but as far as I can tell the highlighted regions are simply zones grouped by UTC offset, ignoring DST. For example, Sydney, Brisbane and Vladivostok all get grouped in a single UTC+10 band.
2) selecting a nearby city from a combo box (you can either select an item or type a name; it appears to do a fuzzy search of some sort when you type a name - "Cowabunga" found Cwmbran in the UK - but it has a limited number of cities, so "Weed" found Weert in the Netherlands rather than Weed in California).
An interesting difference is in the icloud.com web version of the picker. It’s a much smaller map, so presumably to account for mis-clicks, any selection of a city in a highlighted region also displays a dropdown menu to choose between the different major cities in that same UTC offset. Selecting the UTC-7 band (using English language) gives options of “Calgary - Canada (Mountain Time)”, “Denver - U.S. (Mountain Time)”, “Phoenix - U.S. (Mountain Time)” and “Salt Lake City - U.S. (Mountain Time)”.
On Apr 19, 2016, at 12:18 AM, Gilmore Davidson <gilmoreorless@gmail.com> wrote:
An interesting difference is in the icloud.com web version of the picker. It’s a much smaller map, so presumably to account for mis-clicks, any selection of a city in a highlighted region also displays a dropdown menu to choose between the different major cities in that same UTC offset.
The OS X picker also shows a dropdown menu with a list of cities, although its list may be bigger than the icloud.com list.
Hi On Wed, 13 Apr 2016, Vincent Tourneyrie wrote:
I discovered that you are at the origin of the removal of the Montreal/America timezone and it's integration within Toronto.
The problem is that this move to a secondary timezone leads to tons of problems and hours of corrections and explanation (mainly due to quick and dirty implementations of TZ but I cannot blame half of the developers of the planet). The fact that PHP uses this list expose this timezone list to the public.
Yes, and that lists, if you want, includes "outdated" timezones as well: derick@whisky:/tmp $ php -n -r 'var_dump( timezone_identifiers_list( DateTimeZone::ALL_WITH_BC ) );' | egrep '(Montreal)|(Toronto)' string(16) "America/Montreal" string(15) "America/Toronto"
I got many angry comments on this change from French speaking people and Europeans because Toronto is less recognized and known (not to mention loved) than Montreal.
We have 8 millions of Quebec people which will drag their feet to adopt (in fact most of them put NY) and probably half of 220 millions francophone who have no idea where Toronto is (like many people know where Geneva is but have no idea where Zurich is). It looks that you do not get that end users use this.
I understand the willing of normalization but Toronto will never be significant as TZ name for all Eastern Time in Canada.
I think this change has to be reversed,
PHP keeps the old "deprecated" entries as well, so I'm not sure what you're asking. America/Montreal works just as well as America/Toronto: derick@whisky:/tmp $ php -ddate.timezone=America/Montreal -r 'echo date("Y-m-d H:i:s e O");' 2016-04-18 11:23:03 America/Montreal -0400 derick@whisky:/tmp $ php -ddate.timezone=America/Toronto -r 'echo date("Y-m-d H:i:s e O");' 2016-04-18 11:23:11 America/Toronto -0400 cheers, Derick PHP Date/Time support maintainer -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
On 04/13/2016 07:47 PM, Vincent Tourneyrie wrote:
The fact that PHP uses this list expose this timezone list to the public.
America/Montreal is still in tzdata and there are good backward-compatibility arguments for keeping it there. The symptoms you describe correspond to PHP bug 70816 <https://bugs.php.net/bug.php?id=70816>. This bug affects not only America/Montreal, but many other tzdata identifiers, e.g., America/Buenos_Aires, Asia/Calcutta, Asia/Chongqing, and (my favorite!) Antarctica/South_Pole. I briefly looked at the PHP source code but could not determine how it decides which identifiers to publish. Apparently it's done by some procedure outside of the source code itself, a procedure that generates part of the source code. I'll CC: this to Derick Rethans, who is expert on PHP time zones and may be able to explain what's going on and how to fix it. Derick, the thread starts here: http://mm.icann.org/pipermail/tz/2016-April/023551.html
participants (11)
-
Arthur David Olson -
Brian Inglis -
Derick Rethans -
Gilmore Davidson -
Guy Harris -
Lester Caine -
Matt Johnson -
Paul Eggert -
Random832 -
Vincent Tourneyrie -
Ángel González