On Tue, 16 Mar 2004 20:45:01 +0100, you wrote: > >>>>> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes: > > Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
On 08 Jun 1999 11:10:53 +0200, you wrote: > [EMAIL PROTECTED] (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 [EMAIL PROTECTED]