Bug 101954 - time wrong in applet clock (in different timezone)
Summary: time wrong in applet clock (in different timezone)
Status: RESOLVED FIXED
Alias: None
Product: kicker
Classification: Plasma
Component: kclockapplet (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Gebauer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-20 04:22 UTC by Paul Campbell
Modified: 2005-04-22 04:00 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
test program (1.13 KB, text/plain)
2005-03-20 04:28 UTC, Paul Campbell
Details
patch (192 bytes, patch)
2005-03-20 20:31 UTC, Paul Campbell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Campbell 2005-03-20 04:22:24 UTC
Version:           unknown (using KDE 3.4.0, Gentoo)
Compiler:          gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
OS:                Linux (i686) release 2.6.10-gentoo-r6

starting with KDE 3.4 (really I think qt 3.3.4) the kicker applet clock's ability to show different timezones is broken. As I'm sure you're aware relative timezone offsets between timezones change over time. For example I live in New Zealand these days but work for a company near San Francisco, the time difference in NZ is a day a head and 3, 4, or 5 hours behind depending on whether NZ has DST, the US has DST or for a couple of small periods during the year (ie now) when neither does.

Anyway there are two bugs here - the first is very simple and has probably always been there - the clock code calculates the timezone difference when it starts up and doesn't assume that it ever changes while the applet is running ... in reality it probably should check about once an hour.

The second bug is the one that's bugging me at the moment - starting with QT 3.3.4 QT's changed the way it calculates QDateTime:secsTo() - which the clock applet uses to figure out relative timezone offsets, it doesn't for this any more and clocks in different timezones don't work correctly any more (at least for me here in the southern hemisphere), I'll attach a test program to this bug once it's submitted
Comment 1 Paul Campbell 2005-03-20 04:28:48 UTC
Created attachment 10207 [details]
test program

This code shows 2 different ways to calculate QDateTime::secsTo(), secsTo3() is
what QT 3.3.3 used, secsTo4() is what QT 3.3.4 uses. Here in NZ I see the
following output at the moment:

hr=19
hr=15
t3 = -72000
t4 = -75600
off=-21

notice the difference in hours is 4 hours but the 'off' from the same code
you're currently using is -21 (3 hours behind where it should be 4)

[[I think that the real problem is that deep in QT there's a call of mktime()
that ends up being called with the wrong TZ set]]
Comment 2 Paul Campbell 2005-03-20 20:31:55 UTC
Created attachment 10216 [details]
patch

This one line fix fixes the 2nd problem for me - but nees to be tested in the
northern hemisphere before being submitted
Comment 3 Aaron J. Seigo 2005-04-22 04:00:32 UTC
CVS commit by aseigo: 

patch by Paul Campbell for tz calc oddness
BUGS:101954


  M +2 -1      zone.cpp   1.11


--- kdebase/kicker/applets/clock/zone.cpp  #1.10:1.11
@@ -100,5 +100,6 @@ int Zone::calc_TZ_offset(const QString& 
   QDateTime t1( QDateTime::currentDateTime() );
   setCurrentTimeZone(_defaultTZ);
-  return QDateTime::currentDateTime().secsTo(t1);
+  return QDateTime::currentDateTime().time().secsTo(t1.time()) +
+         (QDateTime::currentDateTime().date().daysTo(t1.date()) * 86400);
 }