Re: [RESENT] TIME_GetBias
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> 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(). -- Alexandre Julliard julliard(a)winehq.org
"Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> 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) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> 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(). -- Alexandre Julliard julliard(a)winehq.org
"Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> 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 -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Tue, 16 Mar 2004 20:45:01 +0100, you wrote:
"Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> 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. -- Rein Klazes rklazes(a)xs4all.nl On 08 Jun 1999 11:10:53 +0200, you wrote:
rklazes(a)casema.net (Rein Klazes) writes:
Well the previous code was mine as well. It returned the wrong answer on one of my machines since summer tiem started, gmttime() returned only a one hour difference with local time, ignoring the daylight saving time. The affected program is Agent 32bit.
This is the only solution that I could come up with that works on both my machines: one Linux Debian 2.0 bios time is UTC and one with Debian 2.1 with libc upgraded to 2.1 with bios time is local time (the one that failed the previous code).
Strange, it seems to work fine for me, both with libc 2.0 and 2.1.
Cannot explain this, unless you have libc 2.1.0, libc 2.1.1 fixes a number of problems with timezones. I upgraded this morning to the latest glibc (debian 2.1.1-10, was 2.1.1-5), and still the problem exists. So I looked at the code again, and now I think I can explain why it doesn't work here. time(NULL) returns UTC as seconds since the epoch. localtime() breaks this down and returns the local time taking into account timezone and daylight. mktime() does exactly the inverse this means that: mktime(localtime(x)) = x for all x; Now the code doesn't use localtime(), but gmtime() instead. At this time gmtime(time(NULL)) returns a tm structure with tm_isdst = 0. This is perfectly reasonable to me. tm_hour differs of course two hours in my timezone (Europe/Amsterdam). mktime() in glibc-2.1.1 takes the tm_isdst into account, adding an hour to the effective time when daylight time is in effect. Nett result is that: mktime(gmtime(x)) = x - 3600 for current x values; mktime() in previous versions calculated tm_isdst according to the time zone rules, and filled it in the tm structure. The extra hour is not added so we have: mktime(gmtime(x)) = x - 7200 for current x values; The changed mktime() behaviour is discussed here: http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1098 The old behaviour can be reproduced using tm_isdst<0, but I think it is better to set it to the same state as the local time, this should work even when the daylight is making a change.
Of course the assumption of 60 minutes difference is ugly, I haven't found a way to get the actual value. Yet note that the function still returns the correct total difference between GMT and local time even when the actual daylight saving time diffence is not 60 minutes. This by the also hard coded 60 minutes difference in tzinfo->DayLightBias. The current solution relies on the program to do something sensible with TIME_ZONE_ID_UNKNOWN.
I'm afraid there is no way around that, at least according to the doc. If we return something else than TIME_ZONE_ID_UNKNOWN, we also have to set StandardDate and DaylightDate, and I don't know of any portable way to retrieve this info under Unix.
You could do some binary search using localtime() to find the dates. Yet I do not know any program that is even interested in daylight, so I leave that out. New patch in wine-patches, tested on glibc-2.0.7 and glibc-2.1.1. Rein. -- Rein Klazes rklazes(a)casema.net
"Rein" == Rein Klazes <rklazes(a)xs4all.nl> 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 -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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. -- Rein Klazes rklazes(a)xs4all.nl
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. -- Rein Klazes rklazes(a)xs4all.nl
"Rein" == Rein Klazes <rklazes(a)xs4all.nl> 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... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Thu, 18 Mar 2004 14:25:22 +0100, you wrote:
"Rein" == Rein Klazes <rklazes(a)xs4all.nl> 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. -- Rein Klazes rklazes(a)xs4all.nl
"Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes:
Rein> On Thu, 18 Mar 2004 14:25:22 +0100, you wrote: >> >>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> 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? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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 -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
"Shachar" == Shachar Shemesh <wine-devel(a)shemesh.biz> 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 -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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
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 -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/
"Shachar" == Shachar Shemesh <wine-devel(a)shemesh.biz> 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... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
participants (5)
-
Alexandre Julliard -
Mike McCormack -
Rein Klazes -
Shachar Shemesh -
Uwe Bonnes