Re: [RESENT] TIME_GetBias

[Alexandre Julliard]

Uwe Bonnes  writes:
> Changelog:
>    wine/dlls/ntdll/time.c: TIME_GetBias
>    Calculate the Bias before calling gmtime

This cannot be right, the bias is supposed to be the difference
between local time and GMT, so you have to use gmtime() not
localtime().

[RESENT] TIME_GetBias

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Uwe Bonnes  writes:
    >> Changelog: wine/dlls/ntdll/time.c: TIME_GetBias Calculate the Bias
    >> before calling gmtime

Alexandre> This cannot be right, the bias is supposed to be the
    Alexandre> difference between local time and GMT, so you have to use
    Alexandre> gmtime() not localtime().

Look for the typical sequence:

... RtlLocalTimeToSystemTime ()
...
    gmt = time(NULL);
    bias = TIME_GetBias(gmt, &daylight);

TIME_GetBias(time_t utc, int *pdaylight)
    ...
    ptm = localtime(&utc);
    ptm = gmtime(&utc);
    ret = last_bias = (int)(utc-mktime(ptm));

I my understanding mktime(gmtime(time(NULL))) == time(NULL)

[RESENT] TIME_GetBias

[Alexandre Julliard]

Uwe Bonnes  writes:
> ptm = localtime(&utc);
> ptm = gmtime(&utc);
> ret = last_bias = (int)(utc-mktime(ptm));
>
> I my understanding mktime(gmtime(time(NULL))) == time(NULL)

No, mktime takes local time, it's the reverse of localtime(), not
gmtime().

[RESENT] TIME_GetBias

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Uwe Bonnes  writes:
    >> ptm = localtime(&utc); ptm = gmtime(&utc); ret = last_bias =
    >> (int)(utc-mktime(ptm));
    >> 
    >> I my understanding mktime(gmtime(time(NULL))) == time(NULL)

Alexandre> No, mktime takes local time, it's the reverse of localtime(),
    Alexandre> not gmtime().

But then, what is wrong with
bias = int(time(NULL) - mktime(localtime(mktime(NULL).

like I suppose with my patch

At present, we do 
bias = int(time(NULL) - mktime((gmtime(mktime(NULL)||changes tm_isdst)))

which is diffuse at least and at make the quickworks/synplicity/flexlm combo
stop.

Don't count the hours, I have hunted that bug. Any help is appreciated.

Bye

[RESENT] TIME_GetBias

[Rein Klazes]

On Tue, 16 Mar 2004 20:45:01 +0100, you wrote:
> > > > > > "Alexandre" == Alexandre Julliard  writes:
> Alexandre> Uwe Bonnes <[e-mail]> writes:
> >> ptm = localtime(&utc); ptm = gmtime(&utc); ret = last_bias =
> >> (int)(utc-mktime(ptm));
> >> 
> >> I my understanding mktime(gmtime(time(NULL))) == time(NULL)
>
> Alexandre> No, mktime takes local time, it's the reverse of localtime(),
> Alexandre> not gmtime().
>
> But then, what is wrong with
> bias = int(time(NULL) - mktime(localtime(mktime(NULL).

parsing error.
> like I suppose with my patch
>
> At present, we do 
> bias = int(time(NULL) - mktime((gmtime(mktime(NULL)||changes tm_isdst)))
>
> which is diffuse at least and at make the quickworks/synplicity/flexlm combo
> stop.
>
> Don't count the hours, I have hunted that bug. Any help is appreciated.

Uwe,

I am responsible for that diffuse computation, and there were IMHO good
reasons for it. If you still have the messages, it was discussed on
wine-devel 6-9 June 1999 in a thread "GetTimeZoneInformation patch". The
final conclusion is attached to this message.

First thing to notice is that one of the reasons for choosing this
computation are changes in glibc that broke another more obvious way.

Next this computation was at that time part of the
GetTimeZoneInformation API function only, if you change it you
immediately break the function and the time displayed in my mail reader
is wrong.

Now the function is called in more places, this may simply be done
wrong. I cannot remember what API function(s) are causing your
application to fail.

Your algorithm:

ptm = localtime(&utc);
    ret = last_bias = (int)(utc-mktime(ptm));

is in short:
        bias = utc - mktime(localtime(&utc))

As Alexandre already said mktime and localtime are each others opposite,
so:
    mktime(localtime(&utc) == utc

which leaves:
    
    bias = utc - utc

which makes bias always zero, and tested on my system it surely makes it
return zero. Is that different on your system?
If that is not the case then our assumptions are wrong. Can there be a
buggy libc involved (mine is 2.3.2)?

Hope this helped.

Rein.

[RESENT] TIME_GetBias

[Uwe Bonnes]

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

...    Rein> which leaves:
    
    Rein> 	bias = utc - utc

Rein> which makes bias always zero, and tested on my system it surely
    Rein> makes it return zero. Is that different on your system?  If that
    Rein> is not the case then our assumptions are wrong. Can there be a
    Rein> buggy libc involved (mine is 2.3.2)?

Okay, writing some C test routine, I see that your are right.

However the present implementation makes synplify light not see the flexlm
test license. Do you have DSL? Can you download about 200 MByte?
Registration is required, but I guess
http://www.quicklogic.com/images/QuickWorks953.exe
should work too. Installation has to be done with native Ole and friends,
the installed pasic/spde directory has to be added to the path. Run in
desktop mode or expect messageboxes hidden under images.

The installation leave a 3 day test license in pasic/spde/license.dat.

Start spde.exe. It should report the 3 day test license. If missing path is
mentioned, correct it.

File->Import->synplicity Project

Select e.g. ../pasic/Exemplar/reference/pci5232_208/vhdl/pci5232_208.prj
and okay.

Synplify starts, but brings up "Introduction" with a message "Sorry, no
Synplify license is available".

The start wrapper calculates some magic string from the time. Then TZ is set
to GMT0 and another process is started with this magic string as parameter.

If you change the TimeGetBias() function as mentioned, synplify starts with
the grace license.

Any help appreciated

[RESENT] TIME_GetBias

[Rein Klazes]

On Wed, 17 Mar 2004 13:00:20 +0100, you wrote:
> Synplify starts, but brings up "Introduction" with a message "Sorry, no
> Synplify license is available".

Yes I see that.
> The start wrapper calculates some magic string from the time. Then TZ is set
> to GMT0 and another process is started with this magic string as parameter.

I wonder if the TZ is not causing the problem. In the time zone
calculations we use calls like localtime() that do look at the TZ
variable. 
If the Win API time functions like GetTimeZoneInformation and the
*ToLocalTime* functions do not look at TZ then there is a real problem.
Msdn doesn't mention it (except for the Unix like functions in the
compiler run-time lib's).
Did you happen to look at that?
> If you change the TimeGetBias() function as mentioned, synplify starts with
> the grace license.

I think it helps because with your change, bias is always zero. TZ does
not influence anything anymore.

Rein.

[RESENT] TIME_GetBias

[Rein Klazes]

On Wed, 17 Mar 2004 13:00:20 +0100, you wrote:
> If you change the TimeGetBias() function as mentioned, synplify starts with
> the grace license.

To illustrate my last post, the attached patch makes it work as well. I
still have to confirm that TZ is not used by the win API functions.

Rein.

[RESENT] TIME_GetBias

[Uwe Bonnes]

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

Rein> On Wed, 17 Mar 2004 13:00:20 +0100, you wrote:
    >> If you change the TimeGetBias() function as mentioned, synplify
    >> starts with the grace license.

Locally unsetting TZ was the fix I proposed years ago...

[RESENT] TIME_GetBias

[Rein Klazes]

On Thu, 18 Mar 2004 14:25:22 +0100, you wrote:
> > > > > > "Rein" == Rein Klazes  writes:
> Rein> On Wed, 17 Mar 2004 13:00:20 +0100, you wrote:
> >> If you change the TimeGetBias() function as mentioned, synplify
> >> starts with the grace license.
>
> Locally unsetting TZ was the fix I proposed years ago...

And was it rejected? I can imagine it would break systems that rely on
TZ and don't have something like the timezone database.

After some testing in Windows:

WinApi functions (I tested GetTimeZoneInformation and
LocalFileTimeToFileTime ) are not affected by TZ.
   The VC++ runtime functions (localtime and mktime) are affected by the
TZ value like in Unix.

Apart of unsetting TZ, the only alternative I see would be not to rely
on libc at all (store timezone config in registry values for instance).

Rein.

[RESENT] TIME_GetBias

[Uwe Bonnes]

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

Rein> On Thu, 18 Mar 2004 14:25:22 +0100, you wrote:
    >> >>>>> "Rein" == Rein Klazes  writes:
    >> 
    Rein> On Wed, 17 Mar 2004 13:00:20 +0100, you wrote:
    >> >> If you change the TimeGetBias() function as mentioned, synplify >>
    >> starts with the grace license.
    >> 
    >> Locally unsetting TZ was the fix I proposed years ago...

Rein> And was it rejected? I can imagine it would break systems that
    Rein> rely on TZ and don't have something like the timezone database.

Not allpied and nobody responeded.
I wasn't too persistant than to track it harder.

Rein> After some testing in Windows:

Rein>    WinApi functions (I tested GetTimeZoneInformation and
    Rein> LocalFileTimeToFileTime ) are not affected by TZ.  The VC++
    Rein> runtime functions (localtime and mktime) are affected by the TZ
    Rein> value like in Unix.

Rein> Apart of unsetting TZ, the only alternative I see would be not to
    Rein> rely on libc at all (store timezone config in registry values for
    Rein> instance).

I think that's the way to go. Winesetup should determine and set the
timezone. Who is going to implement it?

[RESENT] TIME_GetBias

[Shachar Shemesh]

Uwe Bonnes wrote:
> I think that's the way to go. Winesetup should determine and set the
> timezone. Who is going to implement it?

Do you realize that time zone information is hardly a static thing? For 
some countries, such as Israel, time zone is something that changes 
annually. Do we really need the chore of keeping that up to date? Also, 
how are people going to update their local setup?

Shachar

[RESENT] TIME_GetBias

[Uwe Bonnes]

> > > > > "Shachar" == Shachar Shemesh  writes:

Shachar> Uwe Bonnes wrote:
    >> I think that's the way to go. Winesetup should determine and set the
    >> timezone. Who is going to implement it?
    >> 
    >> 
    Shachar> Do you realize that time zone information is hardly a static
    Shachar> thing? For some countries, such as Israel, time zone is
    Shachar> something that changes annually. Do we really need the chore of
    Shachar> keeping that up to date? Also, how are people going to update
    Shachar> their local setup?

Please explain how the "time zone information" changes? I understand that
the rules for a given timezone are subject to political influence. But the
time zone itself?  
How is it handled in MS Windows? Probably if there is an unexpected change
in rules, a patch is needed too.

Bye

[RESENT] TIME_GetBias

[Mike McCormack]

Hi Shachar,

Shachar Shemesh wrote:
> Do you realize that time zone information is hardly a static thing? For 
> some countries, such as Israel, time zone is something that changes 
> annually. Do we really need the chore of keeping that up to date? Also, 
> how are people going to update their local setup?

How does Windows deal with this then?

I think in the end, we'll have to go the route of storing our own 
timezone information.  Aric has done some investigation into timezones, 
and found that glibc has no standard API for determining the all the 
information that Wine needs to implement Win32.

Perhaps we can use glibc's data, by importing it, and storing it the 
same way as Windows does... presumably in the registry or a data file 
somewhere... Anybody know how that works?

Mike

[RESENT] TIME_GetBias

[Shachar Shemesh]

Mike McCormack wrote:
> Hi Shachar,
>
> Shachar Shemesh wrote:
> > Do you realize that time zone information is hardly a static thing? 
> > For some countries, such as Israel, time zone is something that 
> > changes annually. Do we really need the chore of keeping that up to 
> > date? Also, how are people going to update their local setup?
>
> How does Windows deal with this then?
>
> I think in the end, we'll have to go the route of storing our own 
> timezone information.  Aric has done some investigation into 
> timezones, and found that glibc has no standard API for determining 
> the all the information that Wine needs to implement Win32.
>
> Perhaps we can use glibc's data, by importing it, and storing it the 
> same way as Windows does... presumably in the registry or a data file 
> somewhere... Anybody know how that works?
>
> Mike

In a nutshell - not well.

Windows has a set of keys in the registry that store the timezone 
information. After Windows 95 they gave up on following the timezone in 
Israel. I guess we can try and figure out the registry timezone info 
structure, but then we'll be only as good as Windows, while we actually 
have enough information to be better! That sounds like an awful shame.

Shachar

[RESENT] TIME_GetBias

[Uwe Bonnes]

> > > > > "Shachar" == Shachar Shemesh  writes:

Shachar> Mike McCormack wrote:
...
    >> somewhere... Anybody know how that works?
    >> 
    >> Mike

Shachar> In a nutshell - not well.

Shachar> Windows has a set of keys in the registry that store the
    Shachar> timezone information. After Windows 95 they gave up on
    Shachar> following the timezone in Israel. I guess we can try and figure
    Shachar> out the registry timezone info structure, but then we'll be
    Shachar> only as good as Windows, while we actually have enough
    Shachar> information to be better! That sounds like an awful shame.

But it's a shame too, if we know the reason for some program not working and
not fixing it. Let's think and work together how to solve _both_ problems...