Version: (using KDE KDE 3.97.0) Installed from: Ubuntu Packages OS: Linux Hi I've been testing KDE4 RC2 on my laptop which is in Australia/Sydney timezone. If I configure the panel clock to show Australia/Sydney timezone and select that timezone as my timezone from the list, the time jumps ahead 11 hours. In System Settings all the configuration fields are shaded. Adding a plasmoid clock widget thing with a timezone of America/New York shows the time as being 5 hours behind "local". $ date -R Sun, 16 Dec 2007 00:23:09 +1100 $ date Sun Dec 16 00:23:27 EST 2007 $ date -u Sat Dec 15 13:23:50 UTC 2007 Default panel clock says "00:24" - so it is picking up the right time for Sydney, it just thinks the time is UTC as The New York clock says "19:24". It should be showing "08:24". This all works fine in KDE 3.5.8. Expected Behaviour: Clock should understand the timezone the system is in and adjust accordingly when the timezone is changed, rather than assume UTC. In the above example with system set to Australia/Sydney time should say "00:24" - when "Show Timezone" is selected it should show the current timezone locale instead of "local". The New York clock should show "08:24" and a UTC clock should show "13:24" (although I can't find a UTC timezone selection in the clock options). Thanks James
I can't replicate this at all, and neither the time engine nor the KDateTime/KTimeZone/KSystemTimeZone classes (in kdelibs) have changed recently. I changed my system time zone to Australia/Sydney: % date Sun Dec 16 03:44:07 EST 2007 % date -R Sun, 16 Dec 2007 03:44:09 +1100 % date -u Sat Dec 15 16:44:11 UTC 2007 From the plasma debug output (see ~/.xsession-errors): plasma(16151)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig: readConfig(): local zone= "Australia/Sydney" The clock says 03:45 (in the local timezone). If I change the timezone to Europe/London (currently UTC), I get 16:44 (which is correct, as confirmed by my watch :-P). If I change the timezone to America/New York, I get 11:44 (five hours behind UTC, which sounds right to me). Can you check your ~/.xsession-errors for the line I mentioned above [KSystemTimeZonesPrivate::readConfig: readConfig()]?
alex: I think james' problem is that his system time is not UTC like a normal linux comp; it's his local time. (dual-booting with windows or something?) have you tested for that?
But the system should deal with that, as shown by the date utility. Userspace doesn't care what the hardware clock is set to, because the kernel and libc deal with that and give you either UTC or local time, as requested. Besides, if there is an issue, it's with KTimeZone/KDateTime, since the time engine gets the current date and time using them.
Hi Thanks for the feedback I created a new KDE4 user as I thought KDE3.5 might be fooling with something. Checked .xsession-errors with the following results: $ grep "local zone" .xsession-errors korgac(12020)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig: readConfig(): local zone= "/etc/localtime" plasma(12004)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig: readConfig(): local zone= "/etc/localtime" /etc/localtime is a binary file, have no idea how to check what the contents are. k4@box:~$ date Sun Dec 16 11:24:23 EST 2007 k4@box:~$ date -R Sun, 16 Dec 2007 11:24:28 +1100 k4@box:~$ date -u Sun Dec 16 00:24:31 UTC 2007 So here is how I can reproduce it with my new k4 user: 1. Panel clock says: "11:29 Sunday Local" 2. Add a Digital Clock widget 3. Hit the spanner to Configure 4. Appearance > Check show timezone > Apply > OK 5. New clock on desktop says 11:29 Sunday Local 6. Configure again 7. Timezones > America/New York > Apply > OK 8. Time in clock changes to *correct* time in New York, 19:29 Saturday America/New York, confirmed by http://www.google.com.au/search?q=time+in+new+york 9. About 10 seconds later it changes to 06:29 Sunday America/New York, which is correct for 5 hours behind 11:29 Sunday UTC What would be the log to tail to find out why the swap is happening ? The only other thing to add is that it would be nice for the timezone to be written in as Australia/Sydney rather than "Local" - if I fly to Australia/Perth - "Local" is not the correct thing to have as its meaning changes but the time stays the same, plus a UTC selection in the timezones list would be nice - I guess I can open a "wish". I'm not dual booting and the maths should be simple enough to handle a system clock in "X" timezone. Hope this helps, let me know if I can be of more assistance. James
Created attachment 22572 [details] Change the timezone login in updateSource() to match sourceRequested() .xsession-errors will contain everything output by plasma. There's also the following lines, which should appear (but, from what you've already posted, may not): kded(10312)/ktimezoned KTimeZoned::checkTimezone: checkTimezone() kded(10312)/ktimezoned KTimeZoned::findLocalZone: /etc/localtime: "Australia/Sydney" The line plasma(12004)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig: readConfig(): local zone= "/etc/localtime" suggests something odd with your local set up. Can you look for KTimeZoned::findLocalZone in your .xsession-errors? From the fact that it displays correctly, then updates incorrectly, the problem appears to be in the updateSource() method of the time engine. It uses a different logic to sourceRequested(). Attached is a patch to do the same as in sourceRequested(). I still can't duplicate the problem, even if I place a second clock on the desktop and wait for the time to change. Is there any chance you could compile kdesupport, kdelibs, kdepimlibs and kdebase with this patch and test it again?
Oh, yes, and please can you put the timezone name thing as a separate bug report, as a feature request (wish)? It's pretty simple to do, but let's keep separate things separate.
Created attachment 22574 [details] Change the timezone login in updateSource() to match sourceRequested() I should really check my patches compile before doing anything with them...
Patch looks good, if it fixes James' problem, please commit it. I cannot reproduce the problem, so it's hard to say anything really sensible for me.
SVN commit 749076 by alexmerry: Don't duplicate code for doing the same task, and especially don't do it in two different ways. CCBUG: 154102 M +10 -23 timeengine.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=749076
OK, I think the problem is with your system set up, but now all the time fetching code uses the method that appears to work despite the fact ktimezoned appears to be having trouble finding the name of your time zone. I'm still interested in what exactly is failing in ktimezoned, so if you could paste any lines that have "ktimezoned" in them from your .xsession-errors, that would be great.
Hi Alex I logged in as K4 again and went through the steps. The 10 second thing isn't exactly 10 seconds - it's when the clock ticks over to the next minute - e.g it went from 08:30 to 19:31 with the "local" panel clock staying as 00:30 to 00:31. Here's some results from tailing the .xsession_errors file: Step 1 (panel clock check "show timezone" plasma(25844) KTimeZoneWidget::setSelected: No such zone: "Local" plasma(25844) Clock::configAccepted: Timezone unknown: () plasma(25844) Clock::configAccepted: Timezone unknown: () Steps 2-9 plasma(25844) KTimeZoneWidget::setSelected: No such zone: "Local" plasma(25844) KTimeZoneWidget::setSelected: No such zone: "Local" plasma(25844) Clock::configAccepted: Timezone unknown: () plasma(25844) Clock::configAccepted: Timezone unknown: () plasma(25844) KTimeZoneWidget::setSelected: No such zone: "Local" Here is everything that has ktimezoned in it, weirdly my /etc/timezone file has the text "User defined" in it... $ grep -i ktimezoned .xsession-errors kded(25802)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added File "/usr/lib/kde4/share/kde4/services/kded/ktimezoned.desktop" for "" ["KDirWatch-1"] kded(25802)/ktimezoned KTimeZoned::checkTimezone: checkTimezone() kded(25802)/ktimezoned KTimeZoned::checkTimezone: checkTimezone(): /etc/timezone opened kded(25802)/ktimezoned KTimeZoned::checkTimezone: checkTimezone(): local= false , name= "User defined" kded(25802)/ktimezoned KTimeZoned::findLocalZone: /etc/localtime: "/etc/localtime" kded(25802)/kded4 Kded::loadModule: Successfully loaded module "ktimezoned" $ cat /etc/timezone User defined So I guess if the timezone can't be found - in my case "User defined" is no help -then it defaults to UTC. I'm wondering why the second clock shows the correct time though until the update kicks in - maybe it is getting the correct timezone from somewhere. In regards to recompiling with the patch, you'll have to excuse me as I am only an egg when it comes to that. Is it at all possible using Kubuntu packages ? Cheers James
That's... really bizarre. It's figuring out that /etc/timezone doesn't have anything useful in it (that's checkTimezone(): local = false). Then it, for some reason, decides that the file at /etc/localtime corresponds to the time zone "/etc/localtime", which is just weird. Can you give the output of "ls -l /etc/localtime"? Unfortunately, you can't compile in the patch using Kubuntu packages. The reason it shows the correct time first and then an incorrect time thereafter is that there are two different methods called, one when first switching to a new timezone, and another on every minute change after that. These two methods previously calculated the time in two different ways (for some reason). I've now changed it so that they both calculate it in the same way: the method that worked on your system. I suspect that putting "Australia/Sydney" into your /etc/timezone then rebooting (so that the init scripts update /etc/localtime) will fix your problems in the meantime. If that works, I suggest we close this as INVALID, on the basis it is almost certainly a system configuration problem.
Hi Alex $ ls -l /etc/localtime -rw-r--r-- 1 root root 785 2007-10-13 08:49 /etc/localtime Out of interest, in KDE3.5 the Date/Time System Settings admin give "Currie Australia AU Tasmania King - Island" as my system timezone - for some unknown reason. If I set the timezone in KDE3.5 then it updates /etc/timezone correctly - haven't checked KDE4 yet. Anyways, I did some grepping and had a look at the tzdata.config script for that deb package as installed on the system, grepped for "User defined" and hey presto there it is: 350 echo "User defined" > /etc/timezone ... 389 if grep -q "^User defined$" /etc/timezone 2>/dev/null ; then 390 rm -f /etc/timezone 391 fi So it seems to be the result of a misconfigured package install (debconf) or an error in that script. Given the tzdata.config script I'm not sure if this is unqiue to my system, I'll leave you to mark the bug as you please. Hope this helps and thanks James
The reason that it decides that /etc/localtime corresponds to the time zone "/etc/localtime" is that it can't find a match between the contents of /etc/localtime and one of the time zone definition files in /usr/share/zoneinfo. Normally /etc/localtime is either a symlink to one of those files, or a copy of one. Time zone definition files don't themselves contain the name of the time zone - the time zone name is normally the relative path starting from /usr/share/zoneinfo. Because there is no match, the absolute path name is used as the zone name, for want of any better information. This suggests that /etc/localtime may not have been installed in a standard way.
I believe r749076 should have fixed the issue, so I'll close this as FIXED. If you have the same problem with the next RC, then you can reopen it.