Missing metazone data for Europe/Kaliningrad timezone

Description

http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml

Europe/Kaliningrad has no currently defined metazone.

xpath

None

locale

None

Activity

Show:
TracBot
May 10, 2019, 1:36 AM
Trac Comment 5 by —2014-05-02T21:50:47.109Z

I realize that the primary purpose of metazones is formatting, but they have grown to more than that, and I think we should fix the following two problems.

1. ICU still shows Montreal as one of the choices. TimeZone.getAvailableIDs() returns it, and the following says that it is canonical.

String timezone = TimeZone.getCanonicalID(timezoneRaw);
boolean isCanonical = timezoneRaw.equals(timezone);

Yet the following returns null:

final Set<MetaZoneRange> ranges = SUPPLEMENTAL.getMetaZoneRanges(timezone);

Its region is 001, which is normally only given to goofy zones like Etc/GMT+-..., or SystemV/... or WET,....

If it doesn't differ after 1970 from Toronto, then it should be canonicalized to Toronto.

2. In retrospect, I don't think the decision to remove the metazone for Kalingrad was correct.

I think if a zone is in availableIDs, is canonical, and has a non-World region, it is a reasonable expectation that it have a metazone. (our code broke when this invariant failed.)

I wrote a quick test, and there are only two zones that fail:

Error: File TestSupplementalInfo.java, Line 1371 Europe/Kaliningrad has metazone until way in the future? : ‹Thu Jan 02 00:00:00 PST 2200› NOT ≤ ‹Sat Mar 26 17:00:00 PDT 2011›; expected true

Error: File TestSupplementalInfo.java, Line 1371 Europe/Minsk has metazone until way in the future? : ‹Thu Jan 02 00:00:00 PST 2200› NOT ≤ ‹Sat Mar 26 17:00:00 PDT 2011›; expected true


Here is my test code:

TracBot
May 10, 2019, 1:36 AM
Trac Comment 5.6 by —2014-05-07T06:44:58.375Z

Replying to (Comment 5 mark):

I realize that the primary purpose of metazones is formatting, but they have grown to more than that, and I think we should fix the following two problems.

 

1. ICU still shows Montreal as one of the choices. TimeZone.getAvailableIDs() returns it, and the following says that it is canonical.

 

String timezone = TimeZone.getCanonicalID(timezoneRaw);

boolean isCanonical = timezoneRaw.equals(timezone);

 

getAvailabldIDs() with no param should still include America/Montreal. The overload taking SystemTimeZoneType with value CANONICAL may or may not.

After looking at this ticket, I thought marking America/Montreal as 'deprecated' in CLDR was not consistent with others ("001" zones), but might be still valid for ICU. The intent of marking 'deprecate' was - it does not make much sense to collect new localized data, because it's practically a dead zone.

ICU still handles it as canonical - because America/Montreal is not equivalent to America/Toronto. This is similar to what tz database did - America/Montreal is not necessary for modern time zone selection (removed from zone.tab), but preserved for historic reasons (was not moved to backward as LINK).

Yet the following returns null:

 

final Set<MetaZoneRange> ranges = SUPPLEMENTAL.getMetaZoneRanges(timezone);

 

Its region is 001, which is normally only given to goofy zones like Etc/GMT+-..., or SystemV/... or WET,....

 

If it doesn't differ after 1970 from Toronto, then it should be canonicalized to Toronto.

Well, I think we need a different classification. It's still different from Montreal, but Montreal is no longer available as a selection in normal circumstance.

My preference is to make this distinction in ICU - by introducing new SystemTimeZoneType enum - semantically, SystemTimeZoneType.Modern or something, equivalent to the goal of zone.tab (a set of zone used for common time zone selection code - which exclude 'what you call' goofy zones and America/Montreal).

 

2. In retrospect, I don't think the decision to remove the metazone for Kalingrad was correct.

 

I don't think we removed the metazone. Kalingrad shifted one hour a few years ago. It was previously recognized as EET (Eastern European Time).

I think if a zone is in availableIDs, is canonical, and has a non-World region, it is a reasonable expectation that it have a metazone. (our code broke when this invariant failed.)

This could happen at any time - in the middle of CLDR release cycle. We might be able to add a name to English, but need to wait for next ST release cycle for translations.

However, I understand your point. As you pointed out, your expectation for metazones (excluding purely historic metazones) actually define a smaller set of available time zone selection.

Note that, from ICU maintenance aspect, we cannot add English names for a new metazone in already released ICU versions practically. Also, if the goal is for getting smaller set of unique zones, you can set an assumption - active zone without metazone mapping - represents its own unique zone. For the Kaliningrad case - it does not belong to "001", and has no metazone mapping currently -> include it in available list for selection - and display name comes from location name.

 

I wrote a quick test, and there are only two zones that fail:

 

Error: File TestSupplementalInfo.java, Line 1371 Europe/Kaliningrad has metazone until way in the future? : ‹Thu Jan 02 00:00:00 PST 2200› NOT ≤ ‹Sat Mar 26 17:00:00 PDT 2011›; expected true

 

Error: File TestSupplementalInfo.java, Line 1371 Europe/Minsk has metazone until way in the future? : ‹Thu Jan 02 00:00:00 PST 2200› NOT ≤ ‹Sat Mar 26 17:00:00 PDT 2011›; expected true

 

Yes. Minsk is also same. It moved 1 hour east from EET.

Anyway, I think adding a new metazone for EET+1 is reasonable at this point. But, mandating metazone for all active zones as the policy - needs more discussion. I personally think it is not necessary.

TracBot
May 10, 2019, 1:36 AM
Trac Comment 7 by —2014-05-14T20:18:18.548Z

Moving all 26dsub to 26dvet. Please assess the need to complete tickets by 26dvet, which is 2014-06-19

TracBot
May 10, 2019, 1:36 AM
Trac Comment 8 by —2014-06-11T21:10:23.863Z

Added a new metazone "Europe_Further_Eastern" with English standard time name "Further-eastern Europe Time".

TracBot
May 10, 2019, 1:36 AM
Trac Comment 10 by tomzhang—2014-07-10T17:37:00.321Z

It is fixed now, so I think the known issue in TestSupplementalInfo.java can be moved now.

Priority

major

Assignee

Yoshito Umaoka

Reporter

TracBot

Reviewer

John Emmons

Labels

None

Components

Fix versions

phase

dvet
Configure