[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTimeZone.m Bug on Windows

From: S.J.Chun
Subject: Re: NSTimeZone.m Bug on Windows
Date: Fri, 21 May 2004 21:06:45 +0900 (KST)

Don't know whether your patch is merged or not, but for me, it works well. (And 
I do not
have to set Local Time Zone to avoid warning message with this patch.)

  ----- Original Message -----
  From: Roland Schwingel <address@hidden>
  To: address@hidden,address@hidden
  Sent: Fri, 21 May 2004 09:56:10 +0200
  Subject: Re: NSTimeZone.m Bug on Windows

  A few days  ago (May 12th) I posted a patch to fix NSTimeZone on windows 
  to the list but haven't heard a single word about it now. Any problems
  with it? I just want to ensure that it not gets lost.
  Roland Schwingel wrote:
  > Hi...
  > After being busy with other things over a longer a period I pulled 
  > current gnustep sources today from CVS. There is the new function to 
  > init NSTimeZone from Windows data directly. Fine thing from the idea. 
  > But current implementation contained some bugs making it not working 
  > at all on non-english systems.
  > Attached you will find a patch to fix this problem.
  > What are the problems. Windows stores timezoneinformation in the 
  > registry. The current time zone (spelled in windows words) is stored 
  > in localized in the
  > registry at
  > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  > The whole table in the registry containing all timezoneentries is 
  > stored in
  > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
  > Zones
  > But here the keys are in english. The current code in NSTimeZone 
  > tryies to lookup the localized name among the unlocalized keys. This 
  > must fail on non english windows.
  > The localized name can be found underneath each entry in the last 
  > mentioned table. My patch now dives directly in the list and compares 
  > the correct entries. Additionally it fixes an impossible lookup for a 
  > timezone file named according to the windows names, which results in 
  > an annoying NSLog() error. Even if somedays GNUstep would have 
  > timezonefiles for windows it would find them anyway.
  > Hope this patch can be applied
  > Roland
  > PS: Anyway the work for the new NSTimeZone was a good idea (forgot who 
  > made it)
  Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]