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)