Set TZ environment variable when not set

[Uwe Bonnes]

>>>>> "Uwe" == Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de> writes:

>>>>> "Rein" == Rein Klazes <rklazes at 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 ...


-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------