Re: Set TZ environment variable when not set

[Rein Klazes]

On Wed, 16 Apr 2003 21:05:28 +0200, you wrote:
> Changelog:
>    memory/environ.c: build_environment
>    Set the TZ value to GMT0, if TZ is not set
>
> Synplify.exe from the Quicklogic FPGA suite refused to work with the demo
> license. Setting TZ to any value made it work. GMT0 should be a good
> approach.
>
> Awaiting the "flame war" about noise level for that silent change :-)

Uwe,

Some programs, like Agent email/news client that I use, check the
existence of TZ before attempting other timezone API call's.

With your patch Agent displays all times in UTC, which is not making me
happy. A correct patch should take care of the local timezone and
daylight saving.

Rein.

Set TZ environment variable when not set

[Uwe Bonnes]

> > > > > "Rein" == Rein Klazes  writes:

Rein> On Wed, 16 Apr 2003 21:05:28 +0200, you wrote:
    >> Changelog: memory/environ.c: build_environment Set the TZ value to
    >> GMT0, if TZ is not set
    >> 
    >> Synplify.exe from the Quicklogic FPGA suite refused to work with the
    >> demo license. Setting TZ to any value made it work. GMT0 should be a
    >> good approach.
    >> 
    >> Awaiting the "flame war" about noise level for that silent change :-)

Rein> Uwe,

Rein> Some programs, like Agent email/news client that I use, check the
    Rein> existence of TZ before attempting other timezone API call's.

Rein> With your patch Agent displays all times in UTC, which is not
    Rein> making me happy. A correct patch should take care of the local
    Rein> timezone and daylight saving.

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.

Bye

Set TZ environment variable when not set

[Rein Klazes]

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.

Just to help the discussion: a "getenv("TZ") on my win2000 test system
returns NULL, neither is TZ available in a command window. So I guesss
your applications would fail here as well. 
Or are they perhaps restricted to win9x/DOS systems?

Rein.

Set TZ environment variable when not set

[Uwe Bonnes]

> > > > > "Rein" == Rein Klazes  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?

Well, the application works on win32 with TZ not set. But is then sets TZ to
GMT0 and spawns off a second process. When comparing a "magic string"
generated from some time value in both processes, things go astray.

Obvious the wine time related functions work different in the first process
with TZ not set and in the second process with TZ set to GMT0. I'll have to
work out...

Bye

Set TZ environment variable when not set

[Uwe Bonnes]

> > > > > "Uwe" == Uwe Bonnes  writes:
> > > > > "Rein" == Rein Klazes  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 ...