diff --git a/docs/site/TEMP-TEXT-FILES/day-period-design.txt b/docs/site/TEMP-TEXT-FILES/day-period-design.txt deleted file mode 100644 index bf745fbeff1..00000000000 --- a/docs/site/TEMP-TEXT-FILES/day-period-design.txt +++ /dev/null @@ -1,128 +0,0 @@ -Day-Period Design -Problem: -The two part AM/PM day division is not universal and some cultures require greater granularity in day divisions to properly represent a time. For more information, please see CLDR bugs 169, 992, 1935. -Proposal -New dayPeriods.xml under Supplemental directory: - -  -   -   -..... -  -  -... -  - -New XML rules in locale xmls : - -  -   -    translation for typeName1 -    translation for typeName2 -... -   -  -... - -On "dayPeriods" in the future we can add an optional type if we need it, to support multiple rules for the same locale. For now we won't support that. -Definition and validation -If locales are not defined in dayPeriods.xml, dayPeriods fallback to AM/PM. -"from" and "to" are closed intervals(inclusive). -"after" and "before" are open intervals(exclusive). -"at" means starting time and end time are the same. -There must be exactly one of {at, from, after} and exactly one of {at, to, before} for each dayPeriodRule. -The set of dayPeriodRule's need to completely cover the 24 hours in a day (from 0:00 before 24:00), with no overlaps between each dayPeriodRule. -Both hh:mm [period name] and hh [period name] can be parsed uniquely to HH:mm [period name]. -For example, you can't have because "12 {morning}" would be ambiguous. -One dayPeriodRule can cross midnight. For example: - -However, this should be avoided unless the alternative is awkward, because of ambiguities. While the use of the dayPeriods without hours is not recommended, they can be used. And if the user sees "Tuesday night" they may not think that that includes 1:00 am Tuesday. -dayPeriodRule's with the same type are only allowed if they are not adjacent. Example: - - -24:00 is only allowed in before="24:00". A term for midnight should be avoided in the rules, because of ambiguity problems in most languages. -"Tuesday midnight" generally means at the end of the day on Tuesday (24:00) -Most software does not format anything for 24:00, only for 00:00. And you don't want 00:00 Tuesday (the start of the day) to be formatted as midnight, meaning the end of the day. -When parsing, if the hour is present the dayperiod is checked for consistency. If there is no hour, the center of the first matching dayPeriodRule is chosen (starting from 0:00). -Document that if people are rounding -- including the rounding done by the time format -- then the rounding needs to be done before the dayperiod is computed. -Examples: -New xml file: Supplemental/dayPeriods.xml - -  -   -   -  -  -   -   -   -   -   -   -  -  -   -   -   -   -   -   -  -. . . - -Examples in locale XML files: -In en locale file(en.xml) - -  -   -   AM -   a.m. -   PM -   p.m. -   -  - -// was: -  AM -  a.m. -  PM -  p.m. -Also, in root, replace all instances (except in Gregorian) of -  AM -  PM -by -   -    -   -In de locale file(de.xml): - -  -   -   morgens -   vormittags -   Mittag -   nachmittags -   abends -   nachts -   -  - -In zh locale file(zh.xml): - -  -   -   凌晨 -   清晨 -   上午 -   中午 -   下午 -   晚上 -   -  - -Code changes -The example code needs to be changed to get the AM/PM data from the new location (high priority) -LDML2ICU needs to change to map the new data. -ICU code needs to use the new structure -We need to have a chart for the dayPeriodRules, like we do for plurals. -Add invariant testing in CheckAttributes. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/delimiter-quotation-mark-proposal.txt b/docs/site/TEMP-TEXT-FILES/delimiter-quotation-mark-proposal.txt deleted file mode 100644 index 5cffa7acf28..00000000000 --- a/docs/site/TEMP-TEXT-FILES/delimiter-quotation-mark-proposal.txt +++ /dev/null @@ -1,17 +0,0 @@ -Delimiter (Quotation Mark) Proposal -Delimiter Consistency -The following is a proposal for how to handle the delimiter issues in CLDR, raised in bug http://unicode.org/cldr/trac/ticket/4201. -There are qute a number of problems in our delimiter data. Most of these are in the ‘lesser vetted’ languages, but some are in major languages. Problems include use of ASCII quotes, and obvious inconsistencies in data. -The goal for the v49 release is to at least have consistent data, then have the translators look at the changes in the data submission phase for v50. -Data Cleanup. I went through the data, and cleaned up obvious problems (such as a generic ASCII quote on one side, and a curly quote on the other). I then compared it to the Wikipedia data where available; if there was a difference between CLDR and Wikipedia, I looked for original sources on the web. It is often a bit tricky, since there are be variant practices in many languages. The goal is to have it to be the most customary usage, but often it may not be clear which variant predominates. -Note that for a great many locales (especially African ones), there isn’t much to go on, so I left it at minor cleanup. I suspect that many of them are problematic; it might be worth asking whether they follow the conventions of another language, like French, rather than asking what the characters are. See below for the results. -Bidi. I tried to gauge from sources what the practice is. However, it is the visual practice, so we have two alternatives. -Use the ASCII ugly quotes -Reverse the two, which would be correct with all BIDI or with correct markup. -Personally, I lean towards #2. -The first sheet has recommendations for changing; the others are just scratch sheets. -The Proposed columns contain the recommendations for v49. -The Style columns just show a label for each type, since it is sometimes hard to distinguish the directions of the marks. -The Old columns show the current values. -And the last column shows the locales in question. -Quotation (Delimiter) Proposal \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/english-inheritance.txt b/docs/site/TEMP-TEXT-FILES/english-inheritance.txt deleted file mode 100644 index bc7e0ebdcf1..00000000000 --- a/docs/site/TEMP-TEXT-FILES/english-inheritance.txt +++ /dev/null @@ -1,115 +0,0 @@ -English Inheritance -Summary -This proposal intends to solve some of the problems that have come up during our review of the various regional locale variants. The goal is to create a clear and understandable policy for the various English locales in CLDR. -International English (en_001) -A few releases back, we created the en_001 locale in CLDR, that was intended to remove much of the U.S. specific data that existed in the "en" locale at the time, and serve as the inheritance point for most English locales that didn't have a direct relationship to the U.S. This was a good starting point, but in order to clean this up and make things more consistent worldwide, the following changes are recommended: -Make en_001 be as country neutral as possible. This would mean making en_001 have the following characteristics: -Date formats - For full, long, medium formats use European style day, month, year. For numeric dates, use ISO 8601 format. -Time formats - Use 12 hour clock, as this is the predominant format for English speaking locales ( ref : https://en.wikipedia.org/wiki/Date_and_time_representation_by_country) -Spelling of unit names - (metre vs. meter) - Since the BIPM spelling is "metre", "centimetre", etc., The "en_001" locale should prefer "metre" over the American spelling "meter". Thus, much of the units data that is currently in en_GB would move from there to en_001, and en_GB would just inherit it. -For units such as gallon that have both a “US” version and an “imperial” version: Both versions should have the qualifier (“US” or “imperial”), should not remove the “imperial” as in the GB versions. -Time zone names: en_001 should us “∅∅∅” to cancel the short metazone names inherited from en, for example: - - -∅∅∅ -∅∅∅ -∅∅∅ - - -Use en_001 as the basis for translation in the CLDR Survey Tool instead of en. -Make en_CA (English - Canada) inherit from en_001 instead of en. The en_CA locale should be reviewed to make sure that items that previously were correctly inherited from "en" (such as well understood time zone abbreviations ) are copied into the en_CA locale. -Make sure that proper time formats are in place for en_XX locales, where XX is any country where 12 hour clock is customary according to CLDR's supplemental data. -Review the inheritance table (below), making any necessary adjustments. It has been suggested that en_ZA and en_ZW should inherit from en_GB instead of en_001. -Reference: English locales and inheritance: -Locale Territory Name Inherits From -en_AG Antigua & Barbuda en_001 -en_AI Anguilla en_001 -en_AS American Samoa en -en_AU Australia en_GB -en_BB Barbados en_001 -en_BE Belgium en_GB -en_BM Bermuda en_001 -en_BS Bahamas en_001 -en_BW Botswana en_001 -en_BZ Belize en_001 -en_CA Canada en -en_CC Cocos (Keeling) Islands en_001 -en_CK Cook Islands en_001 -en_CM Cameroon en_001 -en_CX Christmas Island en_001 -en_DG Diego Garcia en_GB -en_DM Dominica en_001 -en_ER Eritrea en_001 -en_FJ Fiji en_001 -en_FK Falkland Islands en_GB -en_FM Micronesia en_001 -en_GB United Kingdom en_001 -en_GD Grenada en_001 -en_GG Guernsey en_GB -en_GH Ghana en_001 -en_GI Gibraltar en_GB -en_GM Gambia en_001 -en_GU Guam en -en_GY Guyana en_001 -en_HK Hong Kong en_GB -en_IE Ireland en_GB -en_IM Isle of Man en_GB -en_IN India en_GB -en_IO British Indian Ocean Territory en_GB -en_JE Jersey en_GB -en_JM Jamaica en_001 -en_KE Kenya en_001 -en_KI Kiribati en_001 -en_KN St. Kitts & Nevis en_001 -en_KY Cayman Islands en_001 -en_LC St. Lucia en_001 -en_LR Liberia en_001 -en_LS Lesotho en_001 -en_MG Madagascar en_001 -en_MH Marshall Islands en -en_MO Macau en_GB -en_MP Northern Mariana Islands en -en_MS Montserrat en_001 -en_MT Malta en_GB -en_MU Mauritius en_001 -en_MW Malawi en_001 -en_MY Malaysia en_001 -en_NA Namibia en_001 -en_NF Norfolk Island en_001 -en_NG Nigeria en_001 -en_NR Nauru en_001 -en_NU Niue en_001 -en_NZ New Zealand en_GB -en_PG Papua New Guinea en_001 -en_PH Philippines en_001 -en_PK Pakistan en_GB -en_PN Pitcairn Islands en_001 -en_PR Puerto Rico en -en_PW Palau en_001 -en_RW Rwanda en_001 -en_SB Solomon Islands en_001 -en_SC Seychelles en_001 -en_SD Sudan en_001 -en_SG Singapore en_GB -en_SH St. Helena en_GB -en_SL Sierra Leone en_001 -en_SS South Sudan en_001 -en_SX Sint Maarten en_001 -en_SZ Swaziland en_001 -en_TC Turks & Caicos Islands en_001 -en_TK Tokelau en_001 -en_TO Tonga en_001 -en_TT Trinidad & Tobago en_001 -en_TV Tuvalu en_001 -en_TZ Tanzania en_001 -en_UG Uganda en_001 -en_UM U.S. Outlying Islands en -en_US United States en -en_VC St. Vincent & Grenadines en_001 -en_VG British Virgin Islands en_GB -en_VI U.S. Virgin Islands en -en_VU Vanuatu en_001 -en_WS Samoa en_001 -en_ZA South Africa en_001 -en_ZM Zambia en_001 -en_ZW Zimbabwe en_001 \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/european-ordering-rules-issues.txt b/docs/site/TEMP-TEXT-FILES/european-ordering-rules-issues.txt deleted file mode 100644 index 7d34526c477..00000000000 --- a/docs/site/TEMP-TEXT-FILES/european-ordering-rules-issues.txt +++ /dev/null @@ -1,28 +0,0 @@ -European Ordering Rules Issues -The European ordering rules feature is a new collation feature in CLDR which attempts to reflect the efforts within the European community to come up with a single non-language specific way to sort the characters used in various European languages. -A copy of a near-final draft (FprEN 13710:2010) is available to Unicode members in the UTC document register (L2/14-143). -This document describes current issues in an attempt for us to have a clear picture of what level of EOR support will be contained within CLDR 21. -Current Status -EOR rules as defined by EN 13710:2011 Annex G ( March 2011 draft ) are currently included in the latest CLDR root locale as . There are a number of issues with these rules as currently written, see below... -EOR tailorings for specific languages should be relatively easy to create once we settle on the base EOR rules. These should be able to be created by doing an import of the base EOR rules and then importing the language specific tailoring on top of that. -The import feature in ICU is now considered to be stable and ready for use. -Issues with current EOR rules: -The ignoring rules for currency etc. should be filtered out in the CLDR context. ( Mark, John, Åke) -The rule for U+029F SMALL CAPITAL L is missing (typo in standard). ( Åke ) -There are relevant comments by Kent Karlsson in ticket #763 (2010-10-27), with a modified proposal ---- ⃩(⃩ = U+20E9 ( ⃩ ) COMBINING WIDE BRIDGE ABOVE) is the (currently) weightiest, at level 2, non-letter general purpose combining mark ---- ⃩ is used in the proposal to make all "variants" come after all single-accented versions of letters ---- resetting to just A, B, etc. would make variant versions come before accented versions -( Åke ) The current reset rules work fine with MimerSQL, but I think you must check the ICU behaviour. Kent might have a vital point here. -(Kent) (digraphs) ----tertiary difference in DUCET; keep it that way -( Åke ) Kent is right, it should be tertiary difference. (EN13710 needs a revision). -(Kent) -hv/hwair is a case pair and should be treated as such, not be given two different level 2 weights ( Åke ) I agree. (EN13710 needs a revision). -Questions -Which EOR base to use? If EN13710 needs revisions, how do we make that happen? -Should we use Kent's modified rules as attached to http://unicode.org/cldr/trac/ticket/763 ? -What locales should provide EOR based tailorings? -Need to add EOR to BCP47. -Choices -Wait for EN13710 to be fixed -Put in a fixed version ourselves -Put in the "stock" version, knowing about the problems. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/extended-windows-olson-zid-mapping.txt b/docs/site/TEMP-TEXT-FILES/extended-windows-olson-zid-mapping.txt deleted file mode 100644 index 38872ffce35..00000000000 --- a/docs/site/TEMP-TEXT-FILES/extended-windows-olson-zid-mapping.txt +++ /dev/null @@ -1,159 +0,0 @@ -Extended Windows-Olson zid mapping -This proposal was approved by the CLDR TC on 2012-01-11 with some minor updates. See update comments. -Background -There are two dominant time zone implementations in operating systems - Windows and Olson time zone database. Software sometimes require to one to another. For example, Java uses Olson time zone database and the default time zone is initialized by platform. When Java is running on Windows OS, it requires to map the Windows system time zone to a matching Olson time zone. -The current version of CLDR (as of 2.0) includes the mapping data from Windows tzid to Olson zone ID. The mapping data is currently 1-to-1 mapping. However, Windows uses a single time zone for larger territories comparing to Olson time zone database, the actual mapping should be 1-to-n. -For example, Windows zone "(UTC-06:00) Central America" (ID: Central America Standard Time) covers Central American regions with UTC offset of -6 hours, with no daylight saving time. In the Olson tz database, America/Belize, America/Costa_Rica, America/El_Salvador, America/Guatemala, America/Managua, America/Tegucigalpa, Pacific/Galapagos and Etc/GMT+6 would be equivalent to this zone. For now, CLDR only has America/Guatemala as the mapping. Therefore, a software utilizing the CLDR data returns America/Guatemala even the system locale is CR (Costa Rica). By adding mapping data associated with regions, CLDR users can get better mapping. In this example, if location is CR, Windows Central America Standard Time would be mapped to Olson America/Costa_Rica. -Another requirement to CLDR is to allow user to map from a Olson time zone to a Windows time zone. In the example above, you can get Windows Central America Standard Time from America/Guatemala, but you cannot get the same Windows ID from America/Costa_Rica. -The goal of this proposal is to extend the current mapping data (supplemental/windowsZones.xml) to include more Olson time zones associated with regions. -Design Proposal -Regional Mapping -supplemental/windowsZones.xml currently use element. The has multiple child elements. The current data (2.0) look like below. -  -   -    -    -    -    -    -.... -The element is also used by supplemental/metaZones.xml for CLDR meta zone - Olson time zone mapping and its definition is below - - - - - - -metaZones.xml already contains multiple mapping per single meta zone by region like below - -   -   -   -   -   -   -   -   -So we could use the same scheme for representing Windows-Olson mapping. For example, mapping data for Windows "Central America Standard Time" could be represented as below - -   -   -   -   -   -   -   -Default Mapping -The mapping data in supplemental/metaZones.xml is designed for getting a single Olson time zone by a metazone and a region. Therefore, only a single Olson zone is allowed for a unique combination of metazone and region. In this mapping data, we selected a default Olson time zone per metazone/region combination and a global default Olson time zone for all regions (the one associated with "001"). The historical inverse mapping (Olson -> metazone) is represented by element in the same file. -One of our goal is to support better Olson -> Windows mapping. But having a separated inverse mapping table like the one in metaZones.xml does not make much sense, because a Windows time zone is uniquely determined by a Olson time zone. However, when we add multiple mapping data for a unique combination of a Windows time zone and a region, we have to represent which one is used as default Olson time zone. For example, Windows time zone (UTC-06:00) Saskatchewan (ID: Canada Central Standard Time) is mapped to two Olson time zones - America/Regina and America/Swift_Current. Both Olson time zones are Canadian (CA). When input is Windows ID "Canada Central Standard Time" and region "CA", we have to pick one. Also, when a Windows time zone is mapped to multiple Olson time zones in multiple regions, we have to pick one for global default for the case region is unknown (similar to "001" zone in metaZones.xml). -For now, I could think of following options for representing defaults: -[Update] In the CLDR TC call on 2012-01-11, the TC members agreed to take Design Option 3 below. -Design Option 1 - New attribute to indicate global/regional default -Adding a new attribute "defaultfor" to element. The value of "defaultfor" attribute is either "all" or "region" -For example, the mapping data for Windows time zone (UTC-05:00) Esstern Time (US & Canada) (ID: Eastern Standard Time) look like below - -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -When a is unique to a region (territory), defaultfor="region" is not required. -Con: The attribute defaultfor does not make sense for the use of in supplemental/metaZones.xml. -Design Option 2 - Use the ordering to represent the defaults -Use the first element for a Windows time zone as its default and the first element for a unique combination of Windows time zone and a region as its default for the region. For example, -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -Con: The data depends on the order of elements, which could be easily messed up with a certain type of tooling. -Design Option 3 - Use of territory="001" to indicate global default, use a list of Olson time zone in type attribute -Add an extra element to represent global default using territory "001". Also, use space delimited list in type attribute and use the first one as the regional default. For example, -   -   -   -   -   -   -Con: A global default will be appeared twice. Also, the semantics of type attribute differs from the use in supplemental/metaZones.xml. -Version Information -Olson tz database is updated frequently. Also, Windows time zone data is updated at least twice every year (two major scheduled update in August and December). When one of them is updated, the mapping data may need to be updated as well. Therefore, it is important to record what version of data was used for the mapping data. Olson tz database uses year and revision letter withing a year as version string, such as "2011n". Windows also has version information in the registry - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\TzVersion. The value is represented by DWORD and the current value is 0x07dc0000 (It looks high 16-bit represents calendar year: 0x07dc = 2012, and low 16-bit seems to represent revision info within a year). -This proposal adds two version attributes in the container element - - - -The tzver attribute uses the Olson tz database version string. The wintzver attribute uses fixed 8-digit hexadecimal numeric string. For example, -  -   -   .... -[Update] In the CLDR TC call on 2011-01-11, the CLDR TC members agreed to add time zone data version information in element. It should be also applied to supplemental/metaZones.xml. Also, they suggested to use attribute names - "typeVersion" corresponding to type attribute, "otherVersion" corresponding to other attribute in element. So the proposal is updated as below - -This proposal adds two version attributes in the container element - - - - - -The tzver attribute uses the Olson tz database version string. The wintzver attribute uses fixed 8-digit hexadecimal numeric string. For example, -  -   -   .... -Olson time zone Base UTC offset -Australia/Eucla +08:45 -Australia/Lord_Howe +10:30 -Etc/GMT-14 +14:00 -Pacific/Chatham +12:45 -Pacific/Kiritimati +14:00 -Pacific/Marquesas -09:30 -Pacific/Norfolk +11:30 -Other Considerations -Olson time zone Comment -America/Adak -10:00/DST(US rule). (UTC-10:00) Hawaii is only the Windows zone using -10 hour offset, but no DST is observed. -Etc/GMT+8 -08:00/No DST. Windows has two zones with -8 hour offset - (UTC-08:00) Pacific Time (US & Canada) and (UTC-08:00) Baja California - but both of them observe DST. -America/Metlakatla -Pacific/Pitcairn -Etc/GMT+9 -09:00/No DST. (UTC-09:00) Alaska is only the Windows zone using -9 hour offset, but it observes DST. -Pacific/Gambier -Pacific/Easter -06:00/DST(Southern Hemisphere style rule). Windows has two zones with -6 hour offset and DST enabled - (UTC-06:00) Central Time (US & Canada) and (UTC-06:00) Guadalajara, Mexico City - but both of them uses Northern Hemisphere style DST rules. -America/Miquelon -03:00/DST(Canada rule). (UTC-03:00) Greenland is the closest match (-3 hour offset, EU style DST rule). However, Canada rule used by Miquelon differs from EU rule used by Greenland by 2 or 3 weeks on DST start, 1 week on DST end. -Unmappable Windows Time Zone (Mid-Atlantic Standard Time) -Windows time zone (UTC-02:00) Mid-Atlantic (ID: Mid-Atlantic Standard Time) uses UTC offset of -2 hour with daylight saving time (start: last Sunday in March / end: last Sunday in September). In Olson tz database, there are three zones using -2 hour offset (America/Noronha, Atlantic/South_Georgia and Etc/GMT+2), but any of them observe daylight saving time. In the CLDR 2.0, we used Etc/GMT+2 as the mapping just because it was only the zone with -2 hour offset. Recently, Windows added (UTC-02:00) Coordinated Universal Time-02 (ID: UTC-02). Because we want to make the mapping from Olson to Windows unique, Olson Etc/GMT+2 should be only used for the new Windows zone UTC-02. So, this proposal remove the mapping data for Windows Mid-Atlantic Standard Time. I do not know why Microsoft keeps this zone. I assume no one really need this zone. -Unmappable Olson Time Zones -There are two kinds of unmappable Olson time zones. The first category is a set of Olson time zones that do not have the same base offset in Windows repertoires. The following zones belong to this category for now. -Because the mapping such zone to a Windows zone is harmful, these Olson time zones are excluded in the mapping data. -The second category is a set of Olson time zone that do not have any Windows time zones with equivalent (or similar) daylight saving time rule. The following zones belong to this category. -Olson time zone with no DST above (such as Etc/GMT+8) could be mapped to a Windows time zone using the same base offset, because Windows allow users to turn off daylight saving time in the control panel or via Windows API. However, it still requires extra operation, so we do not include these mappings. Significant difference in daylight saving time rules will result mapped zone to return incorrect time zone offset (for both direction), we also exclude these DST incompatible zones from the mapping data. -Region of Non-location Olson Time Zones -Olson tz database contains canonical time zones not associated with a specific region. Etc/* zones and POSIX compatibility zones (such as EST, EST5EDT, PST8PDT...) fall into this category. In this proposal, "ZZ" is used as the region for these non-location time zones. For example, -   -   -[Alternative] "001" (World) might be another candidate, but I prefer "ZZ" over "001", because 1. such zone is applicable to only a piece of world, 2. "ZZ" represents the semantics of "unknown" explicitly. -Equivalent Windows Time Zones -Windows' time zone grouping is sometimes hard to understand. For example, (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague, (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb, (UTC+01:00) Brussels, Copenhagen, Madrid, Paris and (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna shares the same rule (offset +1 hour / EU DST rule). To define mapping between these and Olson time zone require some heuristic decisions. This proposal uses the following policies to determine the mappings. -Windows exemplar location name. For example, Europe/Paris is mapped to (UTC+01:00) Brussels, Copenhagen, Madrid, Paris. -Olson time zone for a territory near by or related to another Olson time zone are grouped. For example, Europe/Madrid is mapped to (UTC+01:00) Brussels, Copenhagen, Madrid, Paris by the policy above. Europe/Ceuta is a zone associated with region ES, which is same with Europe/Madrid (and using the exact same rule in recent years), Europe/Ceuta is also mapped to (UTC+01:00) Brussels, Copenhagen, Madrid, Paris -When a mapping is not determined by above rules, use the most stable and populous Windows time zone as the mapping. For example, among the group of Central European time zones, we pick (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna as the default and use this for other European zones such as Europe/Luxembourg. -The last policy is also used to decide mappings for Etc/* zones when multiple Windows time zones with the same offset/with no daylight saving time are available. -Deprecated Windows Time Zones -Microsoft dose not delete existing time zone registry key even it's no longer used. Therefore, if you look time zone registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones) on Windows XP, you'll probably find some zones not included in Windows 7. In the past, we tried to keep these zones in the mapping data. However, this proposal drops them because we want to provide unique Olson -> Windows mapping. In Windows, these deprecated time zones have a flag in the registry. For example, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Kamchatka Standard Time has a DWORD value - IsObsolete = 0x00000001. Windows 7 does not show such zone in the time zone selection list in the control panel (I thought such mechanism was not available in Windows XP, but I'm not sure). -Maintenance -The mapping data involves some heuristic decisions. Also, in general, Windows time zone is not well maintained for minor regions comparing to the Olson tz database. There are some architectural limitations in Windows time zone implementation. For these reasons, maintaining the mapping data is not definitely a trivial effort. However, once we populate the mapping data, and developing a series of tools validating the mapping data from various aspects, I found that the incremental update would not be really a huge task. There is a program importing Windows time zone registry to create a TimeZone object in ICU. With this program, you can compare a Windows time zone with a Olson time zone side by side. Also, I developed a simple tool and collected exemplar locations from Windows time zone display name, as well as mapping data from a Windows exemplar location to a matching Olson time zone. With such tools, we could automate the mapping data validation. When some changes are necessary, we still need some heuristic decisions, but I believe such task is not really a big task. For now, these codes reside in ICU repository, but we could move them to CLDR later. -ICU Time Zone Data -We currently generate an ICU resource file from supplemental/windowsZones.xml. The mapping data in the current form (1-to-1 map) is used by ICU4C to detect the default system time zone on Windows platform. This implementation has been there for several releases. When a new Olson time zone data version is published, ICU team ships updated data to ICU users, including the mapping data generated from windowsZones.xml. We want to use the same resource for past ICU releases, we cannot change the current ICU resource format. Therefore, LDML2ICUConverter must filter non-default mappings once windowsZones.xml is updated. For future ICU use, LDML2ICUConverter may generate two tables, one in the current format, another for additional mappings. \ No newline at end of file