On Mon, Sep 02, 2002 at 02:41:17PM +0100, Ian Collier wrote: > I've noticed that my own "general info" window under Licq gives a > timezone of "GMT-100". That ist wrong.
> I'm using Solaris which doesn't have the tm_gmtoff element of the tm > structure. I think Linux does tend to have that element, but the code > there is wrong too because tm_gmtoff should already include the DST > offset if applicable. No, the code for tm_gmtoff is correct. It adds an hour to the negative offset in summer. So the offset is the same as in winter. The code for the global timezone variable is wrong because it adds an hour although timezone is not affected by DST. Patch is attached. > >Licq always sets the timezone offset to the non DST offset > > but why, and is there another patch similar to the above which affects > the GUI side of things, or does the other user just have the wrong > timezone set in ICQ? The GUI does not have to cope with different timezones. The daemon calculates a unix timestamp from the broken down time in the packet. The ICQ server sets the time in the packet according to your timezone. In the old UDP proctocol the time in the packets was always in GMT. I think it's easier to always use the non DST offset, because it avoids some cornercases (27th October...). What does the Windows client? Daniel
diff -rudw licq-20020831/src/user.cpp licq-20020831-my/src/user.cpp --- licq-20020831/src/user.cpp Fri Jul 26 07:45:04 2002 +++ licq-20020831-my/src/user.cpp Mon Sep 2 17:00:24 2002 @@ -1645,7 +1645,7 @@ #ifdef USE_GMTOFF return -(tzone->tm_gmtoff) + (tzone->tm_isdst == 1 ? 3600 : 0); // seconds _east_ of UTC #elif defined(USE_TIMEZONE) - return timezone + (tzone->tm_isdst == 1 ? 3600 : 0); // seconds _west_ of UTC + return timezone; // seconds _west_ of UTC #else #warning Unable to determine local timezone return 0;
