FW: Mapping Localised Windows TZ to TZID
yoshito_umaoka at us.ibm.com
yoshito_umaoka at us.ibm.com
Fri Oct 10 02:19:56 UTC 2008
"Olson, Arthur David (NIH/NCI) [E]" <olsona at dc37a.nci.nih.gov> wrote on
10/09/2008 05:59:27 PM:
> I'm forwarding this message from Ian Davies.
>
> --ado
>
> From: Ian Davies [mailto:iand at PartyGaming.com]
> Sent: Thursday, October 09, 2008 3:20
> To: Olson, Arthur David (NIH/NCI) [E]; markdavis34 at home.com
> Cc: Ian Davies
> Subject: Mapping Localised Windows TZ to TZID
>
> Gents,
>
> My developers are using the following mapping to [establish] then
> map a Windows TZ to a unix TZID, [Olson], LDML etc.
>
> http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html
>
> The issue is the only registry entry they have located so far has
> the Windows TZ stored as a text string and this is localised on non
> English Windows. In Windows is there a language [independent]
> reference for the TZ that machine is currently set to that we could
utilise?
>
> Please also pass on this enquiry to any parties who may be able to help.
>
> Regards, Ian
>
The CLDR's Windows TZ mapping table uses TimeZoneInfo.Id values
(http://msdn.microsoft.com/en-us/library/system.timezoneinfo.id.aspx),
which are spposed to be language independent. Thiese are exactly same wit
Windows NT time zone registry key names
(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\*). Windows 16bit platforms used to have the keys in different
location and each key name did not contain "Standard Time" For example,
"Eastern Standard Time" (Windows NT/2000/XP/Vista/2003/2008) vs. "Eastern"
(Windows 95/98/Me). Also, Microsoft localized key names in some localized
Windows versions (as far as I know, it is not the case for Windows XP and
beyond.) Because all of Windows 16bit platforms (95/98/Me) are no longer
supported and MS no longer provide tz registry update for these platforms,
I thought it does not make sense to maintain the mapping table in CLDR.
There are not a small numbers of Windows time zones out of date even with
the latest time zone update. When I worked the CLDR mapping data for CLDR
1.6 release, I did pretty comprehensive survey. In fact, Windows TZ to
the tzdatabase is usually 1-to-n mapping. Someone requested to include
the reverse mapping data, but there were so many issues. I decided to use
Windows time zone display name (usually includes exemplar cities) as a
hint and carefully pick one tzid from the tzdata which reasonably match
the rule. When multiple tzids were available, I just picked most dominant
(based on population of the target region) one. When Microsoft time zone
display name is obviously wrong (for example, with the latest update, the
display name "(GMT-03:00) Georgetown" is used for "SA Eastern Standard
Time" - but its zone offset differs from "America/Guyana"). In this case,
I used Etc/* as fallback.
-Yoshito Umaoka (ICU Project)
More information about the tz
mailing list