CLDR-14428 ZoneParser fails for Australia/Currie #970

btangmu · 2021-01-26T19:22:39Z

-Hard-code data for Australia/Currie in ZoneParser.java

-Also work around a possible compiler bug affecting TestSupplementalInfo.LOCALES_FIXED

Checklist

Issue filed: https://unicode-org.atlassian.net/browse/CLDR-14428
Updated PR title and link in previous line to include Issue number

-Hard-code data for Australia/Currie in ZoneParser.java -Also work around a possible compiler bug affecting TestSupplementalInfo.LOCALES_FIXED

btangmu · 2021-01-26T19:30:41Z

When I run CLDRModify -fp the only changes are for copyright year, no changes for Australia/Currie; that's the intention

srl295 · 2021-01-27T01:41:00Z

@macchiati @btangmu when i merge this change into the JSON generator for #972 (using cldr-staging 38.1. data) it causes Currie to be deleted in a lot of locales, is this expected?

diff --git a/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json b/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json
index db907f21..0712b346 100644
--- a/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json
+++ b/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json
@@ -1137,9 +1137,6 @@
               "Broken_Hill": {
                 "exemplarCity": "Broken Hill"
               },
-              "Currie": {
-                "exemplarCity": "Currie"
-              },
               "Darwin": {
                 "exemplarCity": "Darwin"
               },

CLDR tool source: unicode-org/cldr#972 Note, 'Currie' was dropped somehow with this generation, so I excluded that: unicode-org/cldr#970 (comment)

btangmu · 2021-01-27T02:05:50Z

@macchiati @btangmu when i merge this change into the JSON generator for #972 (using cldr-staging 38.1. data) it causes Currie to be deleted in a lot of locales, is this expected?

No, I would only expect it to affect the collation of Currie, not its presence/absence

macchiati · 2021-01-27T02:06:22Z

Sounds like something is broken.

…

On Tue, Jan 26, 2021, 17:41 Steven R. Loomis ***@***.***> wrote: @macchiati <https://github.com/macchiati> @btangmu <https://github.com/btangmu> when i merge this change into the JSON generator (using cldr-staging 38.1. data) it causes Currie to be deleted in a lot of locales, is this expected? diff --git a/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json b/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json index db907f21..0712b346 100644--- a/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json+++ b/cldr-json/cldr-dates-full/main/az-Cyrl/timeZoneNames.json@@ -1137,9 +1137,6 @@ "Broken_Hill": { "exemplarCity": "Broken Hill" },- "Currie": {- "exemplarCity": "Currie"- }, "Darwin": { "exemplarCity": "Darwin" }, — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#970 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMDLRHU7WGUGE2BPB3DS35VLVANCNFSM4WT7IZOQ> .

srl295 · 2021-01-27T02:18:48Z

OK. I can dig into it some more. There's no reason to hold the CLDR JSON build for it, as it is easy enough to just revert all timeZoneNames.json files (which otherwise didn't change).

btangmu · 2021-01-27T14:49:08Z

az-Cyrl.xml doesn't contain Currie or any zone elements. It presumably inherits them from az.xml, which does have zone elements including Currie. The json files, unlike the xml, explicitly include inherited values? Is there a spec/outline for how the json and xml are related and how/why they differ?

* cldr 38.1 beta update v38.1.0-BETA (tagged "beta" in npm) generated from cldr-staging 1acbe10c8af48794cbe9966cb9a6cea92cee6004 generated from cldr tools f7d6d55ca3073b209d3bf2dd9fcf15d28c259e16 * improve build script cldr-generate-json.sh * create zipfiles * generate cldr-segments-full and also annotations * build scripts WIP (-V temporarily dropped) * Update reflecting CLDR-14313 fixes Reflecting commit c0060510ce98a43f1c8c8541afe48f3cbf442632 on CLDR (see unicode-org/cldr#888 for its destination) Summary of changes: - These items are now arrays instead of strings: - supplemental/calendarPreferenceData - supplemental/weekData (now grouped by territory) - Previously MISSING data now added - cldr-core/dayPeriods.json: dayPeriodRuleSet-type-selection" - cldr-core/units.json: unitConstants, unitQuantities - cldr-core/unitsMetadata.json: unit deprecations * segments packaging missed * script improvements: MATCH * warn if you have a local-config.sh * getting ready to build 38.1.0-BETA4 * update packaging 38.1.0-BETA4 * update license and versioning per CLDR-11059 CLDR tool source: unicode-org/cldr#972 Note, 'Currie' was dropped somehow with this generation, so I excluded that: unicode-org/cldr#970 (comment) * bump proposed tag to 38.1.0 * version regen to 38.1.0

srl295 · 2021-01-27T15:42:27Z

@btangmu that is complex…

What i'm going to do is to split out the changes, and work on the Currie-in-JSON thing as a separate PR

srl295 · 2021-01-28T17:47:36Z

@macchiati @btangmu @yumaoka
I ran a bisect to find out where Currie was disappearing. I found that d909e3d#diff-76dbe60a9eb9c51233a3174cd4b43ef9a0fe25887970f1460e3206e3412a9423R52 (tz 2020f) shows that Australia/Currie actually is removed, since it's now a link to Hobart.

So my question is: is this a bug? Perhaps we shouldn't "Hard-code data for Australia/Currie in ZoneParser.java" if the zone is no longer in modern use on its own? Or at least, we should be using the linked data and not hard coding data?

btangmu · 2021-01-28T18:04:26Z

@macchiati @btangmu @yumaoka
I ran a bisect to find out where Currie was disappearing. I found that d909e3d#diff-76dbe60a9eb9c51233a3174cd4b43ef9a0fe25887970f1460e3206e3412a9423R52 (tz 2020f) shows that Australia/Currie actually is removed, since it's now a link to Hobart.

So my question is: is this a bug? Perhaps we shouldn't "Hard-code data for Australia/Currie in ZoneParser.java" if the zone is no longer in modern use on its own? Or at least, we should be using the linked data and not hard coding data?

@srl295 We just merged this last night: #988 -- I think that answers part of your question (yes: shouldn't hard-code...)

As for "is this a bug [or a feature]", that's sort of a policy question? Mark has suggested in the follow-up ticket that CLDR translations shouldn't be allowed for deprecated zones -- so removal of Currie seems appropriate but I don't know if there are any negative consequences

macchiati · 2021-01-28T18:18:38Z

I think our goal for this release should be to make the minimal changes to data so that we can hit the freeze. I found more issues than just Currie, so I wouldn't just single that particular item out right now (eg don't remove the current translations until we have a full design, and do it under the other ticket). Mark

…

On Thu, Jan 28, 2021 at 10:05 AM Tom Bishop ***@***.***> wrote: @macchiati <https://github.com/macchiati> @btangmu <https://github.com/btangmu> @yumaoka <https://github.com/yumaoka> I ran a bisect to find out where Currie was disappearing. I found that d909e3d#diff-76dbe60a9eb9c51233a3174cd4b43ef9a0fe25887970f1460e3206e3412a9423R52 <d909e3d#diff-76dbe60a9eb9c51233a3174cd4b43ef9a0fe25887970f1460e3206e3412a9423R52> (tz 2020f) shows that Australia/Currie actually *is* removed, since it's now a link to Hobart. So my question is: is this a bug? Perhaps we shouldn't "Hard-code data for Australia/Currie in ZoneParser.java" if the zone is no longer in modern use on its own? Or at least, we should be using the linked data and not hard coding data? @srl295 <https://github.com/srl295> We just merged this last night: #988 <#988> -- I think that answers part of your question (yes: shouldn't hard-code...) As for "is this a bug [or a feature]", that's sort of a policy question? Mark has suggested in the follow-up ticket that CLDR translations shouldn't be allowed for deprecated zones -- so removal of Currie seems appropriate but I don't know if there are any negative consequences — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#970 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMDKJZDUGBWZECWJE2DS4GRLXANCNFSM4WT7IZOQ> .

srl295 · 2021-01-28T18:30:12Z

So here's where things stand…

I wrote a test, and found that there are no time zones that don't have a country.

Do you want a test that verifies that Currie is present in the list of tz names? I'm guessing it's missing in ST also but didn't check yet.

macchiati · 2021-01-28T19:14:23Z

Great. By "no timezones" I assume you mean "no valid zones", according to bcp47/timezone.xml, which is what we use for validity (though it needs some work, as per https://unicode-org.atlassian.net/browse/CLDR-14453 You shouldn't need to write a test that the timezone names used in the following (for example) are valid, since that is done by TestAttributeValues.java. <zone type=*"Australia/Currie"*> <exemplarCity>Currie</exemplarCity> </zone> It uses the data in ldml.dtd, which then uses MatchValue <!ATTLIST zone type CDATA #REQUIRED >  Specifically Bcp47MatchValue, which tests for either the name or the aliases. I introduced a bug in a name and got the expected failure: Status DtdType Element Attribute Match expression #Failures Failing values invalid ldml zone type bcp47/tz 2 Australia/Curry, Pacific/Honolululu What it doesn't yet test for is the deprecated flag or for non-standard aliases. I added that to the items to do in https://unicode-org.atlassian.net/browse/CLDR-14453?focusedCommentId=159945 Mark

…

On Thu, Jan 28, 2021 at 10:30 AM Steven R. Loomis ***@***.***> wrote: So here's where things stand… I wrote a test, and found that there are no time zones that don't have a country. Do you want a test that verifies that Currie is present in the list of tz names? I'm guessing it's missing in ST also but didn't check yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#970 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMHSKWFWVEEOIIU4UR3S4GUMJANCNFSM4WT7IZOQ> .

CLDR-14428 ZoneParser fails for Australia/Currie

402f51a

-Hard-code data for Australia/Currie in ZoneParser.java -Also work around a possible compiler bug affecting TestSupplementalInfo.LOCALES_FIXED

btangmu self-assigned this Jan 26, 2021

btangmu requested review from macchiati, srl295 and yumaoka January 26, 2021 19:23

macchiati approved these changes Jan 26, 2021

View reviewed changes

btangmu merged commit 9223e5b into unicode-org:master Jan 26, 2021

btangmu mentioned this pull request Jan 26, 2021

CLDR-13485 Fix inconsistent use of MU by always using Greek character. #968

Merged

2 tasks

srl295 added a commit to unicode-org/cldr-json that referenced this pull request Jan 27, 2021

update license and versioning per CLDR-11059

bf2e293

CLDR tool source: unicode-org/cldr#972 Note, 'Currie' was dropped somehow with this generation, so I excluded that: unicode-org/cldr#970 (comment)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CLDR-14428 ZoneParser fails for Australia/Currie #970

CLDR-14428 ZoneParser fails for Australia/Currie #970

btangmu commented Jan 26, 2021

btangmu commented Jan 26, 2021

srl295 commented Jan 27, 2021 •

edited

btangmu commented Jan 27, 2021

macchiati commented Jan 27, 2021 via email

srl295 commented Jan 27, 2021

btangmu commented Jan 27, 2021

srl295 commented Jan 27, 2021

srl295 commented Jan 28, 2021

btangmu commented Jan 28, 2021

macchiati commented Jan 28, 2021 via email

srl295 commented Jan 28, 2021

macchiati commented Jan 28, 2021 via email

CLDR-14428 ZoneParser fails for Australia/Currie #970

CLDR-14428 ZoneParser fails for Australia/Currie #970

Conversation

btangmu commented Jan 26, 2021

Checklist

btangmu commented Jan 26, 2021

srl295 commented Jan 27, 2021 • edited

btangmu commented Jan 27, 2021

macchiati commented Jan 27, 2021 via email

srl295 commented Jan 27, 2021

btangmu commented Jan 27, 2021

srl295 commented Jan 27, 2021

srl295 commented Jan 28, 2021

btangmu commented Jan 28, 2021

macchiati commented Jan 28, 2021 via email

srl295 commented Jan 28, 2021

macchiati commented Jan 28, 2021 via email

srl295 commented Jan 27, 2021 •

edited