"Uwe" == Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
"Rein" == Rein Klazes rklazes@xs4all.nl writes:
Rein> On Thu, 17 Apr 2003 09:57:43 +0200, you wrote: >>> Okay, I see. But the qllink.dll/synplify.exe behaviour shows we >>> have some TZ environement variable dependancy in the wine time >>> handling code. Any help to fix this is welcome.
Rein> Just to help the discussion: a "getenv("TZ") on my win2000 test Rein> system returns NULL, neither is TZ available in a command Rein> window. So I guesss your applications would fail here as well. Or Rein> are they perhaps restricted to win9x/DOS systems?
Uwe> Well, the application works on win32 with TZ not set. But is then Uwe> sets TZ to GMT0 and spawns off a second process. When comparing a Uwe> "magic string" generated from some time value in both processes, Uwe> things go astray.
Uwe> Obvious the wine time related functions work different in the first Uwe> process with TZ not set and in the second process with TZ set to Uwe> GMT0. I'll have to work out...
It boils down that RtlQueryTimeZoneInformation uses (Linux) C Library functions that honor TZ, while the Win32 implementation ignores TZ.
Temporaryly disabling TZ in ntdll/time.c:TIME_GetBias() provides a workaround, while not disturbing other code pathes.
However Win32 fetches the tzinfo values from [System\CurrentControlSet\control\TimeZoneInformation]
I can fill tzinfo from those registry values, but two questions arise: - How do we fill the Registry on Wine installation with those values (there are a zillion timezones) for a no-win install. timedate.cpl isn't available on a no-win install neither... - Do we need a fallback? Should the present implementation be used in that case? With the TZ workaround?
Bye
B.t.w: I had a test suite the used GetTimeZoneInformation. However this only affects time calls in msvcrt, the underlying Linux C-Library didn't see that change and so the results didn't differ. Argh ...