[tz] Non-valid timezones, is there a rule to remove them?

yoshito_umaoka at us.ibm.com yoshito_umaoka at us.ibm.com
Fri Jan 24 16:43:17 UTC 2014


>> I'm maintaining a mapping data between the IANA tzids and Windows 
>> time zones in the Unicode CLDR project and review the data about 
>> quarterly basis [http://www.unicode.org/repos/cldr/trunk/common/
>> supplemental/windowsZones.xml].
>> 
>> -Yoshito 
> 
> I've found a few differences between your mapping table and my tzdata [
> http://paste.stg.fedoraproject.org/4440/90540445/].
> I would be happy to provide it patch formatted, just let me know if 
> it's of your interest.
> 
> Moreover, what is the reason to have those kind of differences?
> Could it be different from distro to distro?
> 

These are FAQs. I think CLDR project should provide a document about this.
This document [
http://cldr.unicode.org/development/development-process/design-proposals/extended-windows-olson-zid-mapping
] is a little bit old, but you can see some useful background information 
about the mapping data. (Sorry for my crappy English)

CLDR project defines stable set of tzids, because tzids are used also for 
locale data for display names. For example -

TZ database: America/Argentina/Buenos_Aires vs. CLDR: America/Buenos_Aires

In old versions of the tz database only had "America/Burnos_Aires" and 
CLDR project uses it as a key for localized display names for the zone. 
Later, the tz database reorganized Argentina zones, then 
"America/Buenos_Aires" was moved to backward file as below:

Link    America/Argentina/Buenos_Aires  America/Buenos_Aires

Because we don't want CLDR locale data files to change the key identifying 
the zone, we preserve America/Buenos_Aires as the canonical name of the 
zone, America/Argentina/Buenos_Aires is added as an alias. The mapping is 
defined in another place [
http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml]

<type name="arbue" description="Buenos Aires, Argentina" 
alias="America/Buenos_Aires America/Argentina/Buenos_Aires"/>

In this file, first entry of alias is the canonical 'long' id for the zone 
in CLDR project, and remaining entries in alias attribute are its alias. 
That means, the consumer of windowsZones.xml needs to use this additional 
mapping data.


For 'missing' data, such as "Australia/Lord_Howe" - is really unmappable. 
In the tz database, this zone is defined as

Zone Australia/Lord_Howe 10:36:20 -     LMT     1895 Feb
                        10:00   -       EST     1981 Mar
                        10:30   LH      LHST

However, Windows does not have any zone using UTC+10:30 offset. I use a 
small tooling for maintaining the mapping data in the ICU project and I 
have exception data for such zones [
http://source.icu-project.org/repos/icu/icuapps/trunk/WinTZ/src/com/ibm/icu/dev/tools/wintz/mapper/MapData.java
]. I think the comments below explain why these are not included.

    /*
     * There are some Olson time zones that do not have the same base UTC 
offset in
     * Windows time zones. These zones are not supported by Windows.
     */
    static final String[] NO_BASE_OFFSET_MATCH_ZONES_ARRAY = {
        "Australia/Eucla",      // +8:45
        "Australia/Lord_Howe",  // +10:30
        "Etc/GMT-14",           // +14:00
        "Pacific/Chatham",      // +12:45
        "Pacific/Kiritimati",   // +14:00
        "Pacific/Marquesas",    // -9:30
        "Pacific/Norfolk",      // +11:30
    };

    /*
     * These Olson time zones are using different DST rules from Windows 
zones with
     * same base offset.
     */
    static final String[] NO_DST_RULE_MATCH_ZONES_ARRAY = {
        // UTC-10:00/North American DST rule.
        // Closest match - "Hawaiian Standard Time" (no DST)
        "America/Adak",

        // UTC-08:00/no DST.
        // Closest match - "Pacific Standard Time" (observes DST).
        "Etc/GMT+8",
        "America/Metlakatla",
        "Pacific/Pitcairn",

        // UTC-09:00/no DST
        // Closest match - "Alaskan Standard Time" (observes DST).
        "Etc/GMT+9",
        "Pacific/Gambier",

        // UTC-06:00/Southern Hemisphere style DST rule.
        // Closest match - "Central America Standard Time" (observes 
Northern Hemisphere style DST rule).
        "Pacific/Easter",

        // UTC-03:00 zone with North American DST rule.
        // Closest match - "Greenland Standard Time" (observes EU DST 
rule).
        "America/Miquelon",

        // UTC+02:00 with DST (Mar - Sep).
        // Closest match - "E. Europe Standard Time", "Israel Standard 
Time" and some others
        "Asia/Gaza",
        "Asia/Hebron",
    };

There is a request to add 'unmappable' zones included in the data [
http://unicode.org/cldr/trac/ticket/5589] and I'm planning to work on this 
in near future.

I don't want to hijack this ML for discussing CLDR specific 
implementation. If you have further questions, please post your question 
directly to the CLDR project. You can post your questions to CLDR user 
mailing list (cldr-users at unicode.org) [
http://www.unicode.org/consortium/distlist.html#cldr_list] or problem 
reports/new feature requests to the CLDR trac [
http://unicode.org/cldr/trac].

Thanks,
Yoshito


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140124/350d5bd0/attachment.html>


More information about the tz mailing list