[Bug 7295] wine.inf's timezone data is inconsistent with Windows
Wine Bugs
wine-bugs at winehq.org
Wed Feb 21 11:54:01 CST 2007
http://bugs.winehq.org/show_bug.cgi?id=7295
fgouget at codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From fgouget at 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.java?rev=1.37&content-type=text/vnd.viewcvs-markup
* 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/backward?rev=HEAD&content-type=text/vnd.viewcvs-markup
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.
More information about the wine-bugs
mailing list