[Top][All Lists]

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

Re: NSTimeZone.m Bug on Windows

From: Roland Schwingel
Subject: Re: NSTimeZone.m Bug on Windows
Date: Fri, 21 May 2004 09:56:10 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007


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:


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


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


PS: Anyway the work for the new NSTimeZone was a good idea (forgot who made it)

reply via email to

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