"Olson, Arthur David (NIH/NCI) [E]" <olsona@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@PartyGaming.com] Sent: Thursday, October 09, 2008 3:20 To: Olson, Arthur David (NIH/NCI) [E]; markdavis34@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)