Recent conversions of zones to aliases
Just to note my continued unhappiness with the conversions of zones to aliases. The recent change to map Harare to Maputo broke a test in Joda-Time (the most widely used 3rd party library in Java for date/time, probably used by millions of developers). This means that the many users of Joda-Time will get errors when they try to recompile the latest jar file, a process that has worked fine for years. In order to make the test pass I now have to special case to say that either Harare or Maputo is a valid value. This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data. Thus a request for DateTimeZone zone = DateTimeZone.forID("Africa/Harare"); which use to return a zone with the ID "Africa/Harare" now returns "Africa/Maputo". This means that users can no longer get a zone that represents their country for half of Africa and the Carribean. I cannot stress enough that these utterly unecessary changes have and will continue to cause observable differences in end-user applications. I remain firmly of the opinion that there should be at least one actual Zone entry for each ISO defined territory/country, and that these recent changes should not be described as minor tidying. Stephen
Thanks for the info, but I'm afraid there's not much new here. Stephen Colebourne wrote:
The recent change to map Harare to Maputo broke a test in Joda-Time
Did Joda-Time's regression tests also fail for 2014h's changes to Jamaica time in early 1974? Those changes are for more-recent time stamps, time stamps that are in scope for the tz database.
there should be at least one actual Zone entry for each ISO defined territory/country,
That has never been true of the tz database. Adding such a requirement now would result in more political churn and maintenance overhead, something we already have too much of. There is a real benefit to keeping our distance from politics, even if this means some regression tests need to be updated.
On Oct 2, 2014, at 5:27 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
there should be at least one actual Zone entry for each ISO defined territory/country,
That has never been true of the tz database. Adding such a requirement now would result in more political churn and maintenance overhead, something we already have too much of. There is a real benefit to keeping our distance from politics, even if this means some regression tests need to be updated.
Seconded.
That has never been true of the tz database.
While that has not been true of the tzdb, it has IMO always been a flaw. Until recently, every normal* Unicode region code except the following have had at least one unique TZID. - AC Ascension Island - BV Bouvet Island - CP Clipperton Island - DG Diego Garcia - EA Ceuta and Melilla - HM Heard & McDonald Islands - IC Canary Islands - TA Tristan da Cunha - XK Kosovo It is extremely useful to be able to map all of them to at least one unique TZID, if nothing else than for testing. It does not hurt to have extra links in order to make that true. But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case). * excluding: Unknown Region (ZZ), deprecated codes (like SU), macro regions (like North America) Mark <https://google.com/+MarkDavis> *— Il meglio è l’inimico del bene —* On Fri, Oct 3, 2014 at 2:27 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks for the info, but I'm afraid there's not much new here.
Stephen Colebourne wrote:
The recent change to map Harare to Maputo broke a test in Joda-Time
Did Joda-Time's regression tests also fail for 2014h's changes to Jamaica time in early 1974? Those changes are for more-recent time stamps, time stamps that are in scope for the tz database.
there should be at
least one actual Zone entry for each ISO defined territory/country,
That has never been true of the tz database. Adding such a requirement now would result in more political churn and maintenance overhead, something we already have too much of. There is a real benefit to keeping our distance from politics, even if this means some regression tests need to be updated.
On Oct 3, 2014, at 5:43 AM, Mark Davis ☕️ <mark@macchiato.com> wrote:
But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case).
Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts). (That might also force systems to have better mechanisms for selecting time zones than "put up a bunch of tzids and let the user pick one".)
On 03/10/14 19:49, Guy Harris wrote:
But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case). Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts). (That might also force systems to have better mechanisms for selecting time zones than "put up a bunch of tzids and let the user pick one".)
The data is not directly location based, so perhaps the proper tidy here is a switch to abstract ID's to get away from any 'political bias'. This then allows a location to TZID mapping system perhaps geonames based to include the start date, and then augment the TZ data with local offsets prior to the relevant data set becoming active. -- 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 Oct 3, 2014, at 12:10 PM, Lester Caine <lester@lsces.co.uk> wrote:
On 03/10/14 19:49, Guy Harris wrote:
But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case). Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts). (That might also force systems to have better mechanisms for selecting time zones than "put up a bunch of tzids and let the user pick one".)
The data is not directly location based, so perhaps the proper tidy here is a switch to abstract ID's to get away from any 'political bias'.
Yes, that's what I meant by "Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics..." That would also mean we wouldn't have to worry about what happens when city A no longer has a bigger population than city B, as per "...(and of population shifts)."
This then allows a location to TZID mapping system perhaps geonames based to include the start date, and then augment the TZ data with local offsets prior to the relevant data set becoming active.
Is the local offset calculable from the location? If so, then: the tz database should provide the data it provides currently, using tzids; whatever code uses *locations* to convert between local time and (proleptic) GMT should 1) have a database to map locations to tzids; 2) be able to determine from the tz database whether there was a form of standard time in effect at the time it's trying to convert; 3) if standard time is in effect, use the tzdb information to convert the time; 4) if standard time is not in effect, use the local offset to convert; so that all the tz data needs to have is an indication of when standard time began. The local offset of some specific location in the timezone isn't needed for the above; as I understand it, it's necessary only because the tz code needs to have *something* there for the benefit of code that isn't using the location and that, presumably, doesn't care about getting a *meaningful* value for pre-standard-time timestamps.
On 03/10/14 20:38, Guy Harris wrote:
1) have a database to map locations to tzids; This is what geonames currently provides, but using the 'full' TSID list from TZ currently. That requires manual management of every locations setting, but there is no getting away from that. The coordinates for every location is also provided, which can be used as required. What is missing is the gap between what is valid data on TZ and the actual location based history.
For example when Oxford switched from Oxford time to Europe/London and in parallel when railway time was used at the station. Basically how to add this historic data to the time offset system. There is a substantial amount of data on top of 'Europe/London' in addition to the small amount contained in backzone in relation to the other aliases which are currently truncated to match Europe/London. -- 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 Oct 3, 2014, at 12:58 PM, Lester Caine <lester@lsces.co.uk> wrote:
On 03/10/14 20:38, Guy Harris wrote:
1) have a database to map locations to tzids;
This is what geonames currently provides, but using the 'full' TSID list from TZ currently.
So presumably by "location" you mean "something with an entry in the GeoNames database": http://www.geonames.org rather than "a longitude+latitude". In either case, for any given location, the tzid and longitude+latitude can be determined, with the help of the appropriate databases.
What is missing is the gap between what is valid data on TZ and the actual location based history.
For example when Oxford switched from Oxford time to Europe/London and in parallel when railway time was used at the station. Basically how to add this historic data to the time offset system.
So how was "Oxford time" defined? Was there a specified offset, or was it just, for example, mean solar time at some location in Oxford, or mean time wherever you happened to be in Oxford? Note that the GeoNames site says, "The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge.", so if every location in the GeoNames database has a separate offset, that's unlikely ever to be in the tz database. The tz database is not, and should not ever be, the place to go for information about solar-time-based local time. A case *might* be made for local times that aren't solar-time-based but that weren't standardized in the "standard time" sense, if any such local times existed.
On 03/10/14 21:37, Guy Harris wrote:
On Oct 3, 2014, at 12:58 PM, Lester Caine <lester@lsces.co.uk> wrote:
On 03/10/14 20:38, Guy Harris wrote:
1) have a database to map locations to tzids;
This is what geonames currently provides, but using the 'full' TSID list from TZ currently.
So presumably by "location" you mean "something with an entry in the GeoNames database":
rather than "a longitude+latitude".
In either case, for any given location, the tzid and longitude+latitude can be determined, with the help of the appropriate databases.
Of cause one needs to add in changes in names over time ... us to complete the picture.
What is missing is the gap between what is valid data on TZ and the actual location based history.
For example when Oxford switched from Oxford time to Europe/London and in parallel when railway time was used at the station. Basically how to add this historic data to the time offset system.
So how was "Oxford time" defined? Was there a specified offset, or was it just, for example, mean solar time at some location in Oxford, or mean time wherever you happened to be in Oxford? Many towns set their main clocks to local mean solar time. Initial confusion was against railway time and then against 'GMT'. Some clocks gained an extra minute hand and the Tom Tower in Oxford was one of those clocks.
Note that the GeoNames site says, "The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge.", so if every location in the GeoNames database has a separate offset, that's unlikely ever to be in the tz database. The tz database is not, and should not ever be, the place to go for information about solar-time-based local time. A case *might* be made for local times that aren't solar-time-based but that weren't standardized in the "standard time" sense, if any such local times existed. Totally agree And that timezones have a starting date and time is sort of recorded in the TZ database, and it is one of those elements where the accuracy of dates may be suspect but where we have that information it should be respected. That this requires additional ID's is the problem here, and where a clear distinction between tz data rule set designations and location rule sets needs to be drawn. My objection still and one that comes even more important in the context of tzdist is that truncated data sets should be truncated at the point that a common rule is identified, not pretending that the earlier data of one set applies to all of them.
I do now feel that TZ is NOT an appropriate home for all of this intermediate data that is now starting to emerge from the increasing scanning of historic documents. We do need somewhere where this material can be recorded and used as a publisher of tzdist data that can be used reliably prior to 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 Fri, Oct 3, 2014, at 15:38, Guy Harris wrote:
On Oct 3, 2014, at 12:10 PM, Lester Caine <lester@lsces.co.uk> wrote:
The data is not directly location based, so perhaps the proper tidy here is a switch to abstract ID's to get away from any 'political bias'.
Yes, that's what I meant by "Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics..."
In case anyone is inspired to actually come up with a naming scheme for such a thing, I made the following. A list of all the timezones (except for certain zones that are named after their abbreviation, and Factory) sorted by: Military letter, standard offset (as of now or the next standard transition), standard abbreviation, and also showing the inode# of the posix version on my system, and the names. A +01:00 CET 12977632 Europe/Warsaw Poland A +01:00 CET 12977656 CET A +01:00 CET 14551413 Arctic/Longyearbyen Atlantic/Jan_Mayen Europe/Oslo A +01:00 CET 14551432 Africa/Tunis A +01:00 CET 14551435 Africa/Algiers A +01:00 CET 14551462 Africa/Ceuta A +01:00 CET 14551729 Europe/Brussels A +01:00 CET 14551730 Europe/Malta A +01:00 CET 14551733 Europe/Berlin A +01:00 CET 14551735 Europe/Amsterdam A +01:00 CET 14551736 Europe/Belgrade Europe/Ljubljana Europe/Podgorica Europe/Sarajevo Europe/Skopje Europe/Zagreb A +01:00 CET 14551742 Europe/Luxembourg A +01:00 CET 14551744 Europe/Rome Europe/San_Marino Europe/Vatican A +01:00 CET 14551747 Europe/Monaco A +01:00 CET 14551752 Europe/Paris A +01:00 CET 14551754 Europe/Stockholm A +01:00 CET 14551755 Europe/Vienna A +01:00 CET 14551756 Europe/Copenhagen A +01:00 CET 14551757 Europe/Busingen Europe/Vaduz Europe/Zurich A +01:00 CET 14551759 Europe/Budapest A +01:00 CET 14551762 Europe/Madrid A +01:00 CET 14551763 Europe/Tirane A +01:00 CET 14551764 Europe/Gibraltar A +01:00 CET 14551765 Europe/Andorra A +01:00 CET 14551771 Europe/Bratislava Europe/Prague A +01:00 GMT-1 14551724 Etc/GMT-1 A +01:00 MET 12977293 MET A +01:00 WAT 14551437 Africa/Windhoek A +01:00 WAT 14551441 Africa/Kinshasa A +01:00 WAT 14551446 Africa/Malabo A +01:00 WAT 14551447 Africa/Brazzaville A +01:00 WAT 14551455 Africa/Luanda A +01:00 WAT 14551456 Africa/Porto-Novo A +01:00 WAT 14551463 Africa/Libreville A +01:00 WAT 14551471 Africa/Bangui A +01:00 WAT 14551472 Africa/Ndjamena A +01:00 WAT 14551474 Africa/Lagos A +01:00 WAT 14551475 Africa/Douala A +01:00 WAT 14551477 Africa/Niamey B +02:00 CAT 14551436 Africa/Maputo B +02:00 CAT 14551444 Africa/Blantyre B +02:00 CAT 14551457 Africa/Lubumbashi B +02:00 CAT 14551460 Africa/Lusaka B +02:00 CAT 14551476 Africa/Bujumbura B +02:00 CAT 14551478 Africa/Harare B +02:00 CAT 14551481 Africa/Gaborone B +02:00 CAT 14551482 Africa/Kigali B +02:00 EET 12977299 EET B +02:00 EET 12977623 Africa/Cairo Egypt B +02:00 EET 12977648 Africa/Tripoli Libya B +02:00 EET 12977649 Asia/Istanbul Europe/Istanbul Turkey B +02:00 EET 14551635 Asia/Hebron B +02:00 EET 14551639 Asia/Damascus B +02:00 EET 14551650 Asia/Beirut B +02:00 EET 14551660 Asia/Nicosia Europe/Nicosia B +02:00 EET 14551668 Asia/Amman B +02:00 EET 14551695 Asia/Gaza B +02:00 EET 14551731 Europe/Helsinki Europe/Mariehamn B +02:00 EET 14551734 Europe/Uzhgorod B +02:00 EET 14551739 Europe/Athens B +02:00 EET 14551748 Europe/Kiev B +02:00 EET 14551750 Europe/Chisinau Europe/Tiraspol B +02:00 EET 14551760 Europe/Zaporozhye B +02:00 EET 14551761 Europe/Sofia B +02:00 EET 14551768 Europe/Bucharest B +02:00 EET 14551769 Europe/Vilnius B +02:00 EET 14551773 Europe/Tallinn B +02:00 EET 14551774 Europe/Riga B +02:00 GMT-2 14551713 Etc/GMT-2 B +02:00 IST 12977634 Asia/Jerusalem Asia/Tel_Aviv Israel B +02:00 SAST 14551448 Africa/Mbabane B +02:00 SAST 14551453 Africa/Maseru B +02:00 SAST 14551461 Africa/Johannesburg C +03:00 AST 14551626 Asia/Kuwait C +03:00 AST 14551648 Asia/Baghdad C +03:00 AST 14551656 Asia/Riyadh C +03:00 AST 14551672 Asia/Qatar C +03:00 AST 14551686 Asia/Aden C +03:00 AST 14551693 Asia/Bahrain C +03:00 EAT 14551363 Indian/Comoro C +03:00 EAT 14551365 Indian/Mayotte C +03:00 EAT 14551366 Indian/Antananarivo C +03:00 EAT 14551433 Africa/Juba Africa/Khartoum C +03:00 EAT 14551439 Africa/Kampala C +03:00 EAT 14551443 Africa/Addis_Ababa C +03:00 EAT 14551445 Africa/Mogadishu C +03:00 EAT 14551449 Africa/Djibouti C +03:00 EAT 14551459 Africa/Dar_es_Salaam C +03:00 EAT 14551468 Africa/Asmara Africa/Asmera C +03:00 EAT 14551479 Africa/Nairobi C +03:00 FET 14551740 Europe/Minsk C +03:00 FET 14551743 Europe/Kaliningrad C +03:00 GMT-3 14551716 Etc/GMT-3 C +03:00 SYOT 14551379 Antarctica/Syowa C +03:30 IRST 12977295 Asia/Tehran Iran D +04:00 AMT 14551622 Asia/Yerevan D +04:00 AZT 14551675 Asia/Baku D +04:00 GET 14551636 Asia/Tbilisi D +04:00 GMT-4 14551710 Etc/GMT-4 D +04:00 GST 14551617 Asia/Muscat D +04:00 GST 14551642 Asia/Dubai D +04:00 MSK 12977653 Europe/Moscow W-SU D +04:00 MSK 14551746 Europe/Simferopol D +04:00 MUT 14551370 Indian/Mauritius D +04:00 RET 14551373 Indian/Reunion D +04:00 SAMT 14551767 Europe/Samara D +04:00 SCT 14551372 Indian/Mahe D +04:00 VOLT 14551775 Europe/Volgograd D +04:30 AFT 14551684 Asia/Kabul E +05:00 AQTT 14551615 Asia/Aqtobe E +05:00 AQTT 14551698 Asia/Aqtau E +05:00 GMT-5 14551720 Etc/GMT-5 E +05:00 MAWT 14551380 Antarctica/Mawson E +05:00 MVT 14551364 Indian/Maldives E +05:00 ORAT 14551696 Asia/Oral E +05:00 PKT 14551689 Asia/Karachi E +05:00 TFT 14551371 Indian/Kerguelen E +05:00 TJT 14551683 Asia/Dushanbe E +05:00 TMT 14551632 Asia/Ashgabat Asia/Ashkhabad E +05:00 UZT 14551623 Asia/Samarkand E +05:00 UZT 14551643 Asia/Tashkent E +05:30 IST 14551649 Asia/Colombo E +05:30 IST 14551662 Asia/Calcutta Asia/Kolkata E +05:45 NPT 14551620 Asia/Kathmandu Asia/Katmandu F +06:00 ALMT 14551680 Asia/Almaty F +06:00 BDT 14551624 Asia/Dacca Asia/Dhaka F +06:00 BTT 14551608 Asia/Thimbu Asia/Thimphu F +06:00 GMT-6 14551722 Etc/GMT-6 F +06:00 IOT 14551368 Indian/Chagos F +06:00 KGT 14551610 Asia/Bishkek F +06:00 QYZT 14551682 Asia/Qyzylorda F +06:00 VOST 14551376 Antarctica/Vostok F +06:00 YEKT 14551652 Asia/Yekaterinburg F +06:30 CCT 14551369 Indian/Cocos F +06:30 MMT 14551641 Asia/Rangoon G +07:00 CXT 14551367 Indian/Christmas G +07:00 DAVT 14551382 Antarctica/Davis G +07:00 GMT-7 14551726 Etc/GMT-7 G +07:00 HOVT 14551671 Asia/Hovd G +07:00 ICT 14551634 Asia/Vientiane G +07:00 ICT 14551647 Asia/Phnom_Penh G +07:00 ICT 14551658 Asia/Ho_Chi_Minh Asia/Saigon G +07:00 ICT 14551685 Asia/Bangkok G +07:00 NOVT 14551645 Asia/Novokuznetsk G +07:00 NOVT 14551670 Asia/Novosibirsk G +07:00 OMST 14551646 Asia/Omsk G +07:00 WIB 14551629 Asia/Jakarta G +07:00 WIB 14551697 Asia/Pontianak H +08:00 BNT 14551654 Asia/Brunei H +08:00 CHOT 14551692 Asia/Choibalsan H +08:00 CST 12977629 Asia/Taipei ROC H +08:00 CST 12977651 Asia/Shanghai PRC H +08:00 CST 14551616 Asia/Macao Asia/Macau H +08:00 CST 14551619 Asia/Harbin H +08:00 CST 14551621 Asia/Kashgar H +08:00 CST 14551637 Asia/Chongqing Asia/Chungking H +08:00 CST 14551640 Asia/Urumqi H +08:00 GMT-8 14551712 Etc/GMT-8 H +08:00 HKT 12977631 Asia/Hong_Kong Hongkong H +08:00 KRAT 14551630 Asia/Krasnoyarsk H +08:00 MYT 14551644 Asia/Kuala_Lumpur H +08:00 MYT 14551679 Asia/Kuching H +08:00 PHT 14551674 Asia/Manila H +08:00 SGT 12977655 Asia/Singapore Singapore H +08:00 ULAT 14551611 Asia/Ulaanbaatar Asia/Ulan_Bator H +08:00 WITA 14551664 Asia/Makassar Asia/Ujung_Pandang H +08:00 WST 14551375 Antarctica/Casey H +08:00 WST 14551386 Australia/Perth Australia/West H +08:45 CWST 14551396 Australia/Eucla I +09:00 GMT-9 14551728 Etc/GMT-9 I +09:00 IRKT 14551612 Asia/Irkutsk I +09:00 JST 12977628 Asia/Tokyo Japan I +09:00 KST 12977643 Asia/Seoul ROK I +09:00 KST 14551667 Asia/Pyongyang I +09:00 PWT 14551331 Pacific/Palau I +09:00 TLT 14551628 Asia/Dili I +09:00 WIT 14551687 Asia/Jayapura I +09:30 CST 14551390 Australia/Adelaide Australia/South I +09:30 CST 14551392 Australia/Broken_Hill Australia/Yancowinna I +09:30 CST 14551399 Australia/Darwin Australia/North K +10:00 CHUT 14551311 Pacific/Chuuk Pacific/Truk Pacific/Yap K +10:00 ChST 14551328 Pacific/Saipan K +10:00 ChST 14551346 Pacific/Guam K +10:00 DDUT 14551377 Antarctica/DumontDUrville K +10:00 EST 14551388 Australia/Brisbane Australia/Queensland K +10:00 EST 14551394 Australia/ACT Australia/Canberra Australia/NSW Australia/Sydney K +10:00 EST 14551397 Australia/Melbourne Australia/Victoria K +10:00 EST 14551400 Australia/Lindeman K +10:00 EST 14551401 Australia/Hobart Australia/Tasmania K +10:00 EST 14551403 Australia/Currie K +10:00 GMT-10 14551727 Etc/GMT-10 K +10:00 PGT 14551351 Pacific/Port_Moresby K +10:00 YAKT 14551678 Asia/Yakutsk K +10:00 YAKT 14551688 Asia/Khandyga K +10:30 LHST 14551384 Australia/LHI Australia/Lord_Howe L +11:00 GMT-11 14551714 Etc/GMT-11 L +11:00 KOST 14551342 Pacific/Kosrae L +11:00 MIST 14551381 Antarctica/Macquarie L +11:00 NCT 14551339 Pacific/Noumea L +11:00 PONT 14551316 Pacific/Pohnpei Pacific/Ponape L +11:00 SAKT 14551691 Asia/Sakhalin L +11:00 SBT 14551343 Pacific/Guadalcanal L +11:00 VLAT 14551651 Asia/Vladivostok L +11:00 VLAT 14551655 Asia/Ust-Nera L +11:00 VUT 14551332 Pacific/Efate L +11:30 NFT 14551315 Pacific/Norfolk M +12:00 ANAT 14551676 Asia/Anadyr M +12:00 FJT 14551334 Pacific/Fiji M +12:00 GILT 14551330 Pacific/Tarawa M +12:00 GMT-12 14551715 Etc/GMT-12 M +12:00 MAGT 14551613 Asia/Magadan M +12:00 MHT 12977301 Kwajalein Pacific/Kwajalein M +12:00 MHT 14551337 Pacific/Majuro M +12:00 NRT 14551325 Pacific/Nauru M +12:00 NZST 12977654 Antarctica/McMurdo Antarctica/South_Pole NZ Pacific/Auckland M +12:00 PETT 14551673 Asia/Kamchatka M +12:00 TVT 14551353 Pacific/Funafuti M +12:00 WAKT 14551333 Pacific/Wake M +12:00 WFT 14551352 Pacific/Wallis M +12:45 CHAST 12977652 NZ-CHAT Pacific/Chatham M +13:00 GMT-13 14551725 Etc/GMT-13 M +13:00 PHOT 14551335 Pacific/Enderbury M +13:00 TKT 14551344 Pacific/Fakaofo M +13:00 TOT 14551313 Pacific/Tongatapu M +13:00 WST 14551354 Pacific/Apia M +14:00 GMT-14 14551700 Etc/GMT-14 M +14:00 LINT 14551341 Pacific/Kiritimati N -01:00 AZOT 14551405 Atlantic/Azores N -01:00 CVT 14551408 Atlantic/Cape_Verde N -01:00 EGT 14551604 America/Scoresbysund N -01:00 GMT+1 14551717 Etc/GMT+1 O -02:00 FNT 14551361 America/Noronha Brazil/DeNoronha O -02:00 GMT+2 14551708 Etc/GMT+2 O -02:00 GST 14551412 Atlantic/South_Georgia P -03:00 ART 14551488 America/Argentina/San_Luis P -03:00 ART 14551489 America/Argentina/Ushuaia P -03:00 ART 14551490 America/Argentina/La_Rioja P -03:00 ART 14551491 America/Argentina/Salta P -03:00 ART 14551492 America/Argentina/San_Juan P -03:00 ART 14551493 America/Argentina/Tucuman P -03:00 ART 14551494 America/Argentina/Rio_Gallegos P -03:00 ART 14551546 America/Argentina/Catamarca America/Argentina/ComodRivadavia America/Catamarca P -03:00 ART 14551557 America/Argentina/Buenos_Aires America/Buenos_Aires P -03:00 ART 14551565 America/Argentina/Mendoza America/Mendoza P -03:00 ART 14551576 America/Argentina/Cordoba America/Cordoba America/Rosario P -03:00 ART 14551603 America/Argentina/Jujuy America/Jujuy P -03:00 BRT 14551359 America/Sao_Paulo Brazil/East P -03:00 BRT 14551484 America/Araguaina P -03:00 BRT 14551496 America/Belem P -03:00 BRT 14551520 America/Recife P -03:00 BRT 14551522 America/Maceio P -03:00 BRT 14551534 America/Santarem P -03:00 BRT 14551537 America/Bahia P -03:00 BRT 14551575 America/Fortaleza P -03:00 FKST 14551411 Atlantic/Stanley P -03:00 GFT 14551606 America/Cayenne P -03:00 GMT+3 14551706 Etc/GMT+3 P -03:00 PMST 14551507 America/Miquelon P -03:00 ROTT 14551378 Antarctica/Rothera P -03:00 SRT 14551511 America/Paramaribo P -03:00 UYT 14551523 America/Montevideo P -03:00 WGT 14551562 America/Godthab P -03:30 NST 14551601 America/St_Johns Canada/Newfoundland Q -04:00 AMT 14551355 America/Manaus Brazil/West Q -04:00 AMT 14551508 America/Porto_Velho Q -04:00 AMT 14551510 America/Boa_Vista Q -04:00 AMT 14551536 America/Cuiaba Q -04:00 AMT 14551598 America/Campo_Grande Q -04:00 AST 14551409 Atlantic/Bermuda Q -04:00 AST 14551486 America/Anguilla America/Dominica America/Grenada America/Guadeloupe America/Marigot America/Montserrat America/Port_of_Spain America/St_Barthelemy America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tortola America/Virgin Q -04:00 AST 14551495 America/Glace_Bay Q -04:00 AST 14551501 America/Martinique Q -04:00 AST 14551506 America/Halifax Canada/Atlantic SystemV/AST4ADT Q -04:00 AST 14551517 America/Blanc-Sablon Q -04:00 AST 14551545 America/Puerto_Rico SystemV/AST4 Q -04:00 AST 14551547 America/Aruba America/Curacao America/Kralendijk America/Lower_Princes Q -04:00 AST 14551549 America/Barbados Q -04:00 AST 14551558 America/Santo_Domingo Q -04:00 AST 14551559 America/Moncton Q -04:00 AST 14551588 America/Thule Q -04:00 AST 14551589 America/Goose_Bay Q -04:00 AST 14551592 America/Antigua Q -04:00 BOT 14551593 America/La_Paz Q -04:00 CLT 14551374 Antarctica/Palmer Q -04:00 CLT 14551584 America/Santiago Chile/Continental Q -04:00 GMT+4 14551718 Etc/GMT+4 Q -04:00 GYT 14551538 America/Guyana Q -04:00 PYT 14551572 America/Asuncion Q -04:30 VET 14551602 America/Caracas R -05:00 ACT 14551357 America/Porto_Acre America/Rio_Branco Brazil/Acre R -05:00 ACT 14551497 America/Eirunepe R -05:00 COT 14551531 America/Bogota R -05:00 CST 12977641 America/Havana Cuba R -05:00 ECT 14551574 America/Guayaquil R -05:00 EST 12977621 EST R -05:00 EST 12977636 EST5EDT R -05:00 EST 12977639 America/New_York SystemV/EST5EDT US/Eastern R -05:00 EST 12977642 America/Jamaica Jamaica R -05:00 EST 14551424 America/Detroit US/Michigan R -05:00 EST 14551428 America/Fort_Wayne America/Indiana/Indianapolis America/Indianapolis US/East-Indiana R -05:00 EST 14551485 America/Grand_Turk R -05:00 EST 14551498 America/Kentucky/Monticello R -05:00 EST 14551499 America/Atikokan America/Coral_Harbour R -05:00 EST 14551504 America/Toronto Canada/Eastern R -05:00 EST 14551524 America/Indiana/Petersburg R -05:00 EST 14551525 America/Indiana/Vincennes R -05:00 EST 14551526 America/Indiana/Marengo R -05:00 EST 14551527 America/Indiana/Vevay R -05:00 EST 14551528 America/Indiana/Winamac R -05:00 EST 14551530 America/Nassau R -05:00 EST 14551535 America/Kentucky/Louisville America/Louisville R -05:00 EST 14551544 America/Iqaluit R -05:00 EST 14551552 America/Thunder_Bay R -05:00 EST 14551563 America/Cayman R -05:00 EST 14551567 America/Pangnirtung R -05:00 EST 14551579 America/Port-au-Prince R -05:00 EST 14551590 America/Montreal R -05:00 EST 14551594 America/Nipigon R -05:00 EST 14551599 America/Panama SystemV/EST5 R -05:00 GMT+5 14551707 Etc/GMT+5 R -05:00 PET 14551519 America/Lima S -06:00 CST 12977635 CST6CDT S -06:00 CST 14551420 America/Chicago SystemV/CST6CDT US/Central S -06:00 CST 14551426 America/Indiana/Knox America/Knox_IN US/Indiana-Starke S -06:00 CST 14551503 America/Swift_Current S -06:00 CST 14551509 America/Winnipeg Canada/Central S -06:00 CST 14551512 America/North_Dakota/New_Salem S -06:00 CST 14551513 America/North_Dakota/Beulah S -06:00 CST 14551514 America/North_Dakota/Center S -06:00 CST 14551515 America/Belize S -06:00 CST 14551521 America/Managua S -06:00 CST 14551529 America/Indiana/Tell_City S -06:00 CST 14551532 America/Resolute S -06:00 CST 14551551 America/Mexico_City Mexico/General S -06:00 CST 14551555 America/Costa_Rica S -06:00 CST 14551566 America/Bahia_Banderas S -06:00 CST 14551568 America/Guatemala S -06:00 CST 14551570 America/Merida S -06:00 CST 14551571 America/Regina Canada/East-Saskatchewan Canada/Saskatchewan SystemV/CST6 S -06:00 CST 14551573 America/Matamoros S -06:00 CST 14551580 America/Cancun S -06:00 CST 14551582 America/Menominee S -06:00 CST 14551595 America/El_Salvador S -06:00 CST 14551596 America/Rainy_River S -06:00 CST 14551600 America/Rankin_Inlet S -06:00 CST 14551605 America/Monterrey S -06:00 CST 14551607 America/Tegucigalpa S -06:00 EAST 14551323 Chile/EasterIsland Pacific/Easter S -06:00 GALT 14551349 Pacific/Galapagos S -06:00 GMT+6 14551701 Etc/GMT+6 T -07:00 GMT+7 14551721 Etc/GMT+7 T -07:00 MST 12977633 America/Denver America/Shiprock Navajo SystemV/MST7MDT US/Mountain T -07:00 MST 12977637 MST T -07:00 MST 12977650 MST7MDT T -07:00 MST 14551422 America/Phoenix SystemV/MST7 US/Arizona T -07:00 MST 14551502 America/Ojinaga T -07:00 MST 14551505 America/Hermosillo T -07:00 MST 14551516 America/Cambridge_Bay T -07:00 MST 14551540 America/Creston T -07:00 MST 14551542 America/Edmonton Canada/Mountain T -07:00 MST 14551550 America/Chihuahua T -07:00 MST 14551556 America/Boise T -07:00 MST 14551578 America/Mazatlan Mexico/BajaSur T -07:00 MST 14551583 America/Inuvik T -07:00 MST 14551586 America/Dawson_Creek T -07:00 MST 14551597 America/Yellowknife U -08:00 GMT+8 14551711 Etc/GMT+8 U -08:00 MeST 14551581 America/Metlakatla U -08:00 PST 12977630 PST8PDT U -08:00 PST 14551336 Pacific/Pitcairn SystemV/PST8 U -08:00 PST 14551416 America/Los_Angeles SystemV/PST8PDT US/Pacific US/Pacific-New U -08:00 PST 14551518 America/Whitehorse Canada/Yukon U -08:00 PST 14551543 America/Santa_Isabel U -08:00 PST 14551553 America/Ensenada America/Tijuana Mexico/BajaNorte U -08:00 PST 14551577 America/Vancouver Canada/Pacific U -08:00 PST 14551587 America/Dawson V -09:00 AKST 14551430 America/Anchorage SystemV/YST9YDT US/Alaska V -09:00 AKST 14551533 America/Nome V -09:00 AKST 14551539 America/Juneau V -09:00 AKST 14551561 America/Yakutat V -09:00 AKST 14551591 America/Sitka V -09:00 GAMT 14551340 Pacific/Gambier SystemV/YST9 V -09:00 GMT+9 14551703 Etc/GMT+9 V -09:30 MART 14551314 Pacific/Marquesas W -10:00 CKT 14551350 Pacific/Rarotonga W -10:00 GMT+10 14551699 Etc/GMT+10 W -10:00 HAST 14551418 America/Adak America/Atka US/Aleutian W -10:00 HST 12977640 HST W -10:00 HST 14551347 Pacific/Honolulu Pacific/Johnston SystemV/HST10 US/Hawaii W -10:00 TAHT 14551329 Pacific/Tahiti X -11:00 GMT+11 14551702 Etc/GMT+11 X -11:00 NUT 14551338 Pacific/Niue X -11:00 SST 14551326 Pacific/Pago_Pago Pacific/Samoa US/Samoa X -11:00 SST 14551345 Pacific/Midway Y -12:00 GMT+12 14551704 Etc/GMT+12 Z +00:00 GMT 12977291 Europe/Belfast Europe/Guernsey Europe/Isle_of_Man Europe/Jersey Europe/London GB GB-Eire Z +00:00 GMT 12977619 Etc/GMT Etc/GMT+0 Etc/GMT-0 Etc/GMT0 Etc/Greenwich GMT GMT+0 GMT-0 GMT0 Greenwich Z +00:00 GMT 12977627 Eire Europe/Dublin Z +00:00 GMT 12977647 Atlantic/Reykjavik Iceland Z +00:00 GMT 14551410 Atlantic/St_Helena Z +00:00 GMT 14551438 Africa/Banjul Z +00:00 GMT 14551442 Africa/Sao_Tome Z +00:00 GMT 14551451 Africa/Bamako Africa/Timbuktu Z +00:00 GMT 14551454 Africa/Abidjan Z +00:00 GMT 14551458 Africa/Accra Z +00:00 GMT 14551464 Africa/Lome Z +00:00 GMT 14551465 Africa/Conakry Z +00:00 GMT 14551466 Africa/Monrovia Z +00:00 GMT 14551467 Africa/Nouakchott Z +00:00 GMT 14551470 Africa/Dakar Z +00:00 GMT 14551473 Africa/Bissau Z +00:00 GMT 14551480 Africa/Freetown Z +00:00 GMT 14551483 Africa/Ouagadougou Z +00:00 GMT 14551560 America/Danmarkshavn Z +00:00 UCT 12977645 Etc/UCT UCT Z +00:00 UTC 12977297 Etc/UTC Etc/Universal Etc/Zulu UTC Universal Zulu Z +00:00 UTC 14551383 Antarctica/Troll Z +00:00 WET 12977638 Europe/Lisbon Portugal Z +00:00 WET 12977644 WET Z +00:00 WET 14551404 Atlantic/Madeira Z +00:00 WET 14551406 Atlantic/Faeroe Atlantic/Faroe Z +00:00 WET 14551415 Atlantic/Canary Z +00:00 WET 14551440 Africa/El_Aaiun Z +00:00 WET 14551450 Africa/Casablanca
Some alias relations are vastly different than others. The distinction between Asia/Calcutta and Asia/Kolkata does not matter for the purposes of localized names; they really identify the same place. So we need to map them together for the purpose of getting localized names. http://www.unicode.org/cldr/charts/26/by_type/timezones.southern_asia.html#1... However, the difference between Asia/Tokyo and Asia/Seoul (even if they had the same rules) is very important to end users, and must be maintained. For localization, we are lucky in a way that the rules are sufficiently different that for the most part cities in one country are not aliased to those in another. That is of course not an accident; timezone rules are determined by territory governments, so it is quite likely that at some point in time they'll disagree. In CLDR we have to have stable canonical IDs for the purposes of localization, ones that distinguish by country; we originally based them on zone.tab, but had to deviate from that because it is unstable. So what we use to canonicalize is in the following: http://unicode.org/cldr/trac/browser/trunk/common/bcp47/timezone.xml That continues to distinguish by country, even where items are aliased in the TZDB. <type name="zwhre" description="Harare, Zimbabwe" alias="Africa/Harare"/> <type name="mzmpm" description="Maputo, Mozambique" alias="Africa/Maputo"/> Where there are multiple aliases, the first is the canonical one: <type name="inccu" description="Kolkata, India" alias="Asia/Calcutta Asia/Kolkata"/> So you'll see translations for those canonical IDs like: <zone type="Asia/Calcutta"> <exemplarCity>Калькутта</exemplarCity> </zone> So if some system needs stable identifiers, it may be possible for it to use the CLDR identifiers. The use of those is, however, predicated on using an underlying TZDB for the calculation of times associated with those identifiers. I agree if we had had just arbitrary IDs, there would have been less of a reason to have zone.tab be unstable, because people wouldn't have felt the need to have destabilizing changes simply for spelling changes, etc. On the other hand, items like Asia/Calcutta really should have always been treated simply as internal IDs, never shown directly to end users. So there should have been no need to have destabilizing changes just for spelling, etc. And there is advantage for programmers debugging code to be able to see something like Asia/Calcutta instead of some incomprehensible ID like TZ597. On the other hand, in CLDR we did actually need to have short alphanumeric IDs for use in restricted environments like BCP47, so you see the name=... values above. Those are based on the UN/LOCODE ids, which are vaguely mnemonic: but we had to add extensions for cases where those codes are deficient, and impose a stability rule on our usage, because UN/LOCODE ids are also not guaranteed to be stable—and are far less well maintained than the TZDB. (I don't at all want to seem like I'm slamming the TZDB: the work done for so many years by the TZ maintainers has has been a true service to the world as a whole!) Mark <https://google.com/+MarkDavis> *— Il meglio è l’inimico del bene —* On Fri, Oct 3, 2014 at 8:49 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Oct 3, 2014, at 5:43 AM, Mark Davis ☕️ <mark@macchiato.com> wrote:
But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case).
Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts). (That might also force systems to have better mechanisms for selecting time zones than "put up a bunch of tzids and let the user pick one".)
On Fri, Oct 17, 2014, at 05:41, Mark Davis ☕️ wrote:
Some alias relations are vastly different than others. The distinction between Asia/Calcutta and Asia/Kolkata does not matter for the purposes of localized names; they really identify the same place. So we need to map them together for the purpose of getting localized names.
What is a "localized name"? The timezone identifiers aren't meant to be human-readable; you should be localizing the descriptions in zone{1970,}.tab. And even disregarding this... no, you don't, you can just localize them both to the same thing. There aren't _that_ many timezones. Or maintain your own unification table independent of aliases.
Mark <https://google.com/+MarkDavis> *— Il meglio è l’inimico del bene —* On Fri, Oct 17, 2014 at 3:11 PM, <random832@fastmail.us> wrote:
On Fri, Oct 17, 2014, at 05:41, Mark Davis ☕️ wrote:
Some alias relations are vastly different than others. The distinction between Asia/Calcutta and Asia/Kolkata does not matter for the purposes of localized names; they really identify the same place. So we need to map them together for the purpose of getting localized names.
What is a "localized name"?
A name that is localized to a given language. I gave the example of the Russian Калькутта . The timezone identifiers aren't meant to be
human-readable;
Yes, that's what I said, if you read it.
you should be localizing the descriptions in zone{1970,}.tab.
No, for the reasons I gave. Again, it doesn't look like you read completely through what I wrote.
And even disregarding this... no, you don't, you can just localize them both to the same thing.
Too many missing referents in your sentence to make sense of it.
There aren't _that_ many timezones. Or maintain your own unification table independent of aliases.
Again, that's what we do do.
On 3 October 2014 01:27, Paul Eggert <eggert@cs.ucla.edu> wrote:
The recent change to map Harare to Maputo broke a test in Joda-Time Did Joda-Time's regression tests also fail for 2014h's changes to Jamaica time in early 1974? Those changes are for more-recent time stamps, time stamps that are in scope for the tz database.
The test broke because it is no longer possible to obtain a zone in Joda-Time with the ID "Africa/Harare", however we map the CAT short ID to Harare.
there should be at least one actual Zone entry for each ISO defined territory/country, That has never been true of the tz database. Adding such a requirement now would result in more political churn and maintenance overhead, something we already have too much of. There is a real benefit to keeping our distance from politics, even if this means some regression tests need to be updated.
Far far more churn has been created through these unecessary and artificial actions. This notion of "distance from politics" is absurd IMO, Marks reply gives more detail about how things have changed, and how the value of the data has been well and truly degraded. I use it now because I have no alternative, not because I approve of the way the data is maintained, Personally I'd love to see CLDR take over the project and apply some decent engineering rigour to one of the most important data sets in the world. Stephen
Stephen Colebourne wrote:
Did Joda-Time's regression tests also fail for 2014h's changes to Jamaica time in early 1974? Those changes are for more-recent time stamps, time stamps that are in scope for the tz database. The test broke because it is no longer possible to obtain a zone in Joda-Time with the ID "Africa/Harare", however we map the CAT short ID to Harare.
I wasn't asking about Harare, where the issue was the name. I was asking about Jamaica, where the issue was the data. Did Joda-Time's regression tests fail for 2014h's changes to Jamaica time in early 1974? To some extent I'm asking whether these regression tests focus on the data or on the metadata. As others have said, it's always been the intent in the tz database that users are unaffected by whether a name is defined via a Zone or a Link, which means a regression test sensitive to this issue could well be a false alarm.
This notion of "distance from politics" is absurd
It may be absurd to you, but it's not absurd to me. I get political pushes all the time, some on this list, some not. Politics not only consume far more of my time than I'd like: they have the potential to escalate enough to destroy the project. I attempt to insulate this group as much as possible from politics, and understand that those being sheltered may not appreciate the need for the insulation. But the need is there.
On 4 October 2014 18:08, Paul Eggert <eggert@cs.ucla.edu> wrote:
I wasn't asking about Harare, where the issue was the name. I was asking about Jamaica, where the issue was the data. Did Joda-Time's regression tests fail for 2014h's changes to Jamaica time in early 1974? To some extent I'm asking whether these regression tests focus on the data or on the metadata.
As others have said, it's always been the intent in the tz database that users are unaffected by whether a name is defined via a Zone or a Link, which means a regression test sensitive to this issue could well be a false alarm.
In general, Joda-Time does not test the tzdb data, it just expects it to be right and exist. The test failed because something that used to exist (Harare) ceased to exist (because aliases are normalised). Jamaica made no difference, and in fact most tzdb changes would not. The problem is around the assumption that IDs would continue to exist and not be converted to aliases. As Mark noted, in effect there has been a policy change, from the occasional use of aliases for very minor ISO territories, to a use of aliases whenever and wherever it suits, with the other knock on effects we've discussed before. Stephen
Stephen Colebourne wrote:
the assumption that IDs would continue to exist and not be converted to aliases.
I'm afraid that assumption has been incorrect for the tz database for many years, and there's no end-user reason to impose it as a requirement now.
Jamaica made no difference, and in fact most tzdb changes would not.
I don't expect anybody (other than us time zone nerds) will care about the upcoming changes in Indochina either. The most recent time stamps affected will be circa 1975.
Seconded On 2014-10-02 19:34, Stephen Colebourne wrote:
Just to note my continued unhappiness with the conversions of zones to aliases.
The recent change to map Harare to Maputo broke a test in Joda-Time (the most widely used 3rd party library in Java for date/time, probably used by millions of developers). This means that the many users of Joda-Time will get errors when they try to recompile the latest jar file, a process that has worked fine for years. In order to make the test pass I now have to special case to say that either Harare or Maputo is a valid value.
This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data. Thus a request for
DateTimeZone zone = DateTimeZone.forID("Africa/Harare");
which use to return a zone with the ID "Africa/Harare" now returns "Africa/Maputo". This means that users can no longer get a zone that represents their country for half of Africa and the Carribean.
I cannot stress enough that these utterly unecessary changes have and will continue to cause observable differences in end-user applications. I remain firmly of the opinion that there should be at least one actual Zone entry for each ISO defined territory/country, and that these recent changes should not be described as minor tidying.
Stephen
--
<<On Fri, 3 Oct 2014 00:34:06 +0100, Stephen Colebourne <scolebourne@joda.org> said:
This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data.
This is probably the mistake. There are no "aliases", just multiple names for the same data. -GAWollman
On Thu, Oct 2, 2014, at 19:34, Stephen Colebourne wrote:
This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data.
Why? Tzcode doesn't, and for a long time zic hardlinked them. The distinction between an alias and the "actual zone" is therefore clearly not designed to be significant or user-visible.
On 4 October 2014 01:04, <random832@fastmail.us> wrote:
On Thu, Oct 2, 2014, at 19:34, Stephen Colebourne wrote:
This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data.
Why? Tzcode doesn't, and for a long time zic hardlinked them. The distinction between an alias and the "actual zone" is therefore clearly not designed to be significant or user-visible.
The key point to remember is that Joda-Time has been running for many years and has striven very hard to retain backwards compatibility. Converting aliases to their underlying zone has worked well over many years, and is far from an unreasonable approach, as it reduces the effect of older zones such as US-Pacific. Unfortunately, the extent of the use of aliases has been massively expanded by the current tzdb maintainer. As such, there are now effectively two kinds of alias, ones in the main files and ones in the backward file. Despite the fact that they look the same in the file format, they have been changed to have different meanings.
From Joda-Time's perspective it is a no-win. If I leave it as is users will complain that they can no longer get an ID for their country (a backwards incompatible change). If I stop mapping aliases to underlying for files other than backward its also an incompatible change. (Perhaps you can tell, I have high standards of compatibility...).
Once again, I remind everyone that the tzdb data is now used far far beyond the C programs supplied by this project. It is wrong to assume that everyone uses the data in the same way. Stephen
And 2014j causes yet another bug downstream https://bugs.openjdk.java.net/browse/JDK-8064914 But hey, its only minor tinkering of no consequence... Stephen On 3 October 2014 00:34, Stephen Colebourne <scolebourne@joda.org> wrote:
Just to note my continued unhappiness with the conversions of zones to aliases.
The recent change to map Harare to Maputo broke a test in Joda-Time (the most widely used 3rd party library in Java for date/time, probably used by millions of developers). This means that the many users of Joda-Time will get errors when they try to recompile the latest jar file, a process that has worked fine for years. In order to make the test pass I now have to special case to say that either Harare or Maputo is a valid value.
This issue occurs because Joda-Time normalises all aliases to the actual zone as per TZDB data. Thus a request for
DateTimeZone zone = DateTimeZone.forID("Africa/Harare");
which use to return a zone with the ID "Africa/Harare" now returns "Africa/Maputo". This means that users can no longer get a zone that represents their country for half of Africa and the Carribean.
I cannot stress enough that these utterly unecessary changes have and will continue to cause observable differences in end-user applications. I remain firmly of the opinion that there should be at least one actual Zone entry for each ISO defined territory/country, and that these recent changes should not be described as minor tidying.
Stephen
On Mon, 17 Nov 2014, Stephen Colebourne wrote:
And 2014j causes yet another bug downstream https://bugs.openjdk.java.net/browse/JDK-8064914
The zic(8) man page, which serves as documentation for the format of the input files, says: The LINK-FROM field should appear as the NAME field in some zone line. To me, this means that a Link should not point to another Link, but should point to a Zone. This combination of links would appear to violate that requirement: Zone Africa/Nairobi ... Link Africa/Nairobi Africa/Asmara Link Africa/Asmara Africa/Asmera --apb (Alan Barrett)
On 17 November 2014 09:22, Alan Barrett <apb@cequrux.com> wrote:
On Mon, 17 Nov 2014, Stephen Colebourne wrote:
And 2014j causes yet another bug downstream https://bugs.openjdk.java.net/browse/JDK-8064914
The zic(8) man page, which serves as documentation for the format of the input files, says:
The LINK-FROM field should appear as the NAME field in some zone line.
To me, this means that a Link should not point to another Link, but should point to a Zone. This combination of links would appear to violate that requirement:
Zone Africa/Nairobi ... Link Africa/Nairobi Africa/Asmara Link Africa/Asmara Africa/Asmera
And yet logically, what should be expressed is that Asmera is an alias for Asmara. Making backzone point at Nairobi would be very confusing. Stephen
Thanks for pointing out the problem. If memory serves this kind of error has come up before and that it's not limited to conversions of zones to aliases. The errors are annoying enough that we should check for them more systematically. Proposed patches attached.
participants (9)
-
Alan Barrett -
David Patte ₯ -
Garrett Wollman -
Guy Harris -
Lester Caine -
Mark Davis ☕️ -
Paul Eggert -
random832＠fastmail.us -
Stephen Colebourne