[Bug 7295] wine.inf's timezone data is inconsistent with Windows
http://bugs.winehq.org/show_bug.cgi?id=7295 fgouget(a)codeweavers.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From fgouget(a)codeweavers.com 2007-21-02 11:54 ------- I have used two sources to update Wine's timezone data: * Olson's timezone database http://www.twinsun.com/tz/tz-link.htm This seems to be the authoritative source of timezone data used by the Glibc, Linux, FreeBSD, etc. It can also be found online on Unicode.org's CLDR site: http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/util/data/ * Unicode.org's Common Locale Data Repository (CLDR) Project's table mapping from Windows timezone names to the Olson database timezone ids: http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html See the license in Exhibit 1 there: http://www.unicode.org/copyright.html Some notes: * Wine uses the Olson tzid as the display name. I have kept it that way as it seems to match what is displayed by Linux distributions and tools. If we wanted we could use the following source to get information more (/exactly) like the Windows display names: http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/tool/Misc.jav... * In many places we were using 'old tzids', that is timezone ids that Olson's database only keeps around for backward compatibility. See the 'backward' file in Olson's database: http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/util/data/bac... So for those I switched to the new names. * There are still some differences with the Windows timezone data. They are detailed in a section below. * For some Windows timezones we use a different Olson id than the one specified by the CLDR database. These are detailed in a section below. * Having done the mapping by hand once, I think it would be nice to be able to automate the wine.inf update, especially as many countries seem to like changing their daylight saving rules every year. Automation should be feasible by combining the CLDR's mapping of Windows timezone names to Olson tzids, and parsing the Olson database (which is complex but has clearly been parsed before). * If automated we could even automatically generate a very complete set of registry values in Vista's new 'Dynamic DST' format. * When comparing this data to the contents of the Windows XP registry, make sure you have first applied the 'February 2007 cumulative time zone update for Microsoft Windows operating systems' as it contains some important fixes. http://support.microsoft.com/?scid=kb%3Ben-us%3B931836&x=3&y=14 So here are the remaining differences with Windows. I hope that people can analyze and pitch in on how best to handle them. --- Differences in the TZI field * Central Brazilian Standard Time - America/Manaus Windows XP has DST settings for this timezone: bias=240 / 0 / -60 - std=0000/00/00 (0) 00:00:00:0 - dst=0000/00/00 (0) 00:00:00:0 + std=0000/02/05 (0) 00:00:00:0 + dst=0000/11/01 (0) 00:00:00:0 * Egypt Standard Time - Africa/Cairo Windows XP says Egypt switches to daylight saving time at 23:59:59 on the last Thursday of April, while Olson say the switch is at 00:00:00 on the last Friday of April. This looks like just a one second difference but could widen to a whole week if the last Thursday of April is the last day of April... So who's right? bias=-120 / 0 / -60 std=0000/09/05 (4) 23:59:59:0 - dst=0000/04/05 (5) 00:00:00:0 + dst=0000/04/05 (4) 23:59:59:0 * Greenland Standard Time - America/Godthab The Windows XP DST start date does not match Olson's. bias=180 / 0 / -60 std=0000/10/05 (0) 02:00:00:0 - dst=0000/03/05 (0) 02:00:00:0 + dst=0000/04/01 (0) 02:00:00:0 * Jordan Standard Time - Asia/Amman The Windows XP DST end date does not match Olson's. bias=-120 / 0 / -60 - std=0000/10/05 (5) 00:00:00:0 + std=0000/09/05 (5) 01:00:00:0 dst=0000/03/05 (4) 00:00:00:0 * Mid-Atlantic Standard Time - Atlantic/Noronha Windows XP has DST settings for this timezone: bias=120 / 0 / -60 - std=0000/00/00 (0) 00:00:00:0 - dst=0000/00/00 (0) 00:00:00:0 + std=0000/09/05 (0) 02:00:00:0 + dst=0000/03/05 (0) 02:00:00:0 * Middle East Standard Time Again a difference of a few microseconds that would get as large as a week. bias=-120 / 0 / -60 - std=0000/10/05 (0) 00:00:00:0 + std=0000/10/05 (6) 23:59:59:999 dst=0000/03/05 (0) 00:00:00:0 * Namibia Standard Time - Africa/Windhoek Windows XP says this is GMT+02:00 but Olson says it's GMT+01:00. Windows XP also seems to have the DST dates reversed (Namibia is in the southern hemisphere). - bias=-60 / 0 / -60 - std=0000/04/01 (0) 02:00:00:0 - dst=0000/09/01 (0) 02:00:00:0 + bias=-120 / 0 / 60 + std=0000/09/01 (0) 02:00:00:0 + dst=0000/04/01 (0) 02:00:00:0 * Pacific SA Standard Time Again a difference of a few microseconds that would get as large as a week. bias=240 / 0 / -60 - std=0000/03/02 (0) 00:00:00:0 - dst=0000/10/02 (0) 00:00:00:0 + std=0000/03/02 (6) 23:59:59:999 + dst=0000/10/02 (6) 23:59:59:999 --- Windows -> Tzid mapping differences to the CLDR * Azerbaijan Standard Time -> Asia/Baku Central Brazilian Standard Time -> America/Manaus Georgian Standard Time -> Asia/Tbilisi Jordan Standard Time -> Asia/Amman Namibia Standard Time -> Africa/Windhoek Middle East Standard Time -> Asia/Beirut Montevideo Standard Time -> America/Montevideo The CLDR is missing mappings for all of these. I reported it in CLDR bug 1282: http://www.unicode.org/cldr/bugs/locale-bugs * Central Standard Time (Mexico) Mountain Standard Time (Mexico) Pacific Standard Time (Mexico) These are new too so the CLDR does not have a mapping for them either. Further complicating the matter, they are copies of the old non '(Mexico)' suffixed timezones and thus should have a different display name to distinguish them. * Caucasus Standard Time Wine: Asia/Yerevan CLDR: Asia/Tbilisi Windows now has the '' which maps to 'Asia/Tbilisi' and this one seems to more closely correspond to 'Asia/Yerevan'. See also bug 1282. * Central America Standard Time Wine: America/Regina CLDR: America/Managua Central Pacific Standard Time Wine: Pacific/Guadalcanal CLDR: Asia/Magadan GTB Standard Time Wine: Europe/Athens CLDR: Europe/Istanbul I'm unconvinced by the CLDR mappings for these so I'm essentially sticking with Wine's existing mapping (but with the current Olson tzids). * Dateline Standard Time Wine: Pacific/Kwajalein CLDR: Etc/GMT+12 I'm siding with CLDR bug 988 on this one. * SA Eastern Standard Time Wine: America/Argentina/Buenos_Aires CLDR: America/Buenos_Aires US Eastern Standard Time Wine: America/Indiana/Indianapolis CLDR: America/Indianapolis The CLDR uses the old Olson timezone ids for these. Reported as CLDR bug 1283. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
participants (1)
-
Wine Bugs