[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #7317(closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Missing metazone data for Europe/Kaliningrad timezone

Reported by: lararennie@… Owned by: yoshito
Component: supplemental Data Locale:
Phase: dvet Review: emmons
Weeks: Data Xpath:
Xref:

ticket:5195

Description

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

Europe/Kaliningrad has no currently defined metazone.

Attachments

Change History

comment:1 follow-up: ↓ 4 Changed 3 years ago by lararennie@…

America/Montreal seems also to be missing from the file entirely, but is in the latest Olson timezone data...

comment:2 Changed 3 years ago by mark

  • Owner changed from anybody to yoshito
  • Priority changed from assess to major
  • Status changed from new to assigned
  • Milestone changed from UNSCH to 26dsub

comment:3 Changed 3 years ago by yoshito

  • Xref set to 5195

There was a discussion when Europe/Kaliningrad changed the zone offset to UTC+3. This is found in #5195. At that time, we concluded that we did not want to add a new metazone for this and closed it as won't fix.

comment:4 in reply to: ↑ 1 Changed 3 years ago by yoshito

Replying to lararennie@…:

America/Montreal seems also to be missing from the file entirely, but is in the latest Olson timezone data...

America/Montreal was removed from zone.tab in the tz database - i.e. it implies that the zone is not normally included in available choices. However, it is not completely deprecated (not moved to backward file), because America/Montreal in the tz database has different rules before 1970 comparing to America/Toronto.

In CLDR, we assume the zone is no longer in canonical set, and marked as deprecated (bcp47/timezone.xml), therefore, it is no longer included in metaZones.xml.

This was also discussed in the CLDR TC, but I'm not 100% sure if the decision was best. I'll bring this topic to CLDR TC and see if we need any changes.

comment:5 follow-up: ↓ 6 Changed 3 years ago by 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);

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.

  1. 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:

    public void TestMetazones() {
        Date goalMin = new Date(70,0,2);
        Date goalMax = new Date(300,0,2);
        for (String timezoneRaw : TimeZone.getAvailableIDs()) {
            String timezone = TimeZone.getCanonicalID(timezoneRaw);
            String region = TimeZone.getRegion(timezone);
            if (!timezone.equals(timezoneRaw) || "001".equals(region)) {
                continue;
            }
            final Set<MetaZoneRange> ranges = SUPPLEMENTAL.getMetaZoneRanges(timezone);
            
            if (assertNotNull("metazones for " + timezone, ranges)) {
                long min = Long.MAX_VALUE;
                long max = Long.MIN_VALUE;
                for (MetaZoneRange range : ranges) {
                    min = Math.min(min, range.dateRange.from);
                    max = Math.max(max, range.dateRange.to);
                }
                assertRelation(timezone + " has metazone from 1970?", true, goalMin, GEQ, new Date(min));
                assertRelation(timezone + " has metazone until way in the future?", true, goalMax, LEQ, new Date(max));
            }
        }
    }

comment:6 in reply to: ↑ 5 Changed 3 years ago by yoshito

Replying to 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).

  1. 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.

comment:7 Changed 3 years ago by emmons

  • Milestone changed from 26dsub to 26dvet

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

comment:8 Changed 3 years ago by yoshito

  • Status changed from assigned to reviewing
  • Review set to emmons

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

comment:9 Changed 3 years ago by emmons

  • Status changed from reviewing to closed
  • Resolution set to fixed

comment:10 Changed 3 years ago by tomzhang

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

comment:11 Changed 3 years ago by markus

  • Phase set to dvet
  • Milestone changed from 26dvet to 26
View

Add a comment

Modify Ticket

Action
as closed
Next status will be 'new'
Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.