[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


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
   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:

 * Unicode.org's Common Locale Data Repository (CLDR) Project's table
   mapping from Windows timezone names to the Olson database timezone ids:
   See the license in Exhibit 1 there:

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:

 * 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:
   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

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

 * 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

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