I chose digital clock, but I can see this with the analog clock, too. My timezone is CEST and when I tell the clock to show the timezone, it correctly shows CEST. Output by `date` is the correct time (currently GMT+2), but the time shown by the clock is the system time (UTC, GMT). Reproducible: Always Steps to Reproduce: 1. Start plasmashell, ensure that a clock item (analog or digital) is shown 2. Ensure that timezone is not set to GMT 3. Compare the output of the clock widget and `date` Actual Results: Clock widget shows GMT time. Expected Results: Clock widget should show the time according to the current timezone setting.
Thanks for the report! How are you setting your timezone (and making sure it's set)? Also can you please give me output of "env | grep LC" Thanks
The timezone is set by a symlink: /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin env | grep LC returns nothing. I think that is the most common technique these days and is also what timedatectl from systemd does. Changing that does actually make a difference, so it is getting weird now. I changed the timezone to GMT and the clock showed that the timezone is now GMT (before it showed CEST). Changed it back and the timezone did change back, but it also set the correct time now. So there might be a problem with the initial setup of the time?
Could you also check the value of the TZ env var?
There is no TZ env var set.
Ok so your timezone is now correct, right? Do you have a way to reproduce that state? We use "QTimeZone::systemTimeZoneId()" for the current timezone and that uses many ways to make sure it has the correct timezone. I have seen it broken if your locale is set to C though (then the timezone is GMT). Which distro are you running btw?
Created attachment 86779 [details] digital clock in a hurry I have a similar problem with digital clock. The timezone showed by it is correct, but the time itself is one hour ahead of my local time (e.g. digital clock is one hour ahead of "date" output)
Which distribution are you running that on?
I'm on openSUSE 13.1
(In reply to comment #5) > Ok so your timezone is now correct, right? Do you have a way to reproduce > that state? We use "QTimeZone::systemTimeZoneId()" for the current timezone > and that uses many ways to make sure it has the correct timezone. Actually, I can't. The symlink is exactly the same as before. There are no env vars referring to the timezone or GMT. I don't know what was causing it, but it's gone. > I have > seen it broken if your locale is set to C though (then the timezone is GMT). No, that's not the case over here. > Which distro are you running btw? Exherbo, as given in the Platform field above. I still don't understand, what happened.
As there's no way to reproduce this bug, I'm closing this. Please reopen if you find a way to reproduce that state with steps on how to reproduce; it's also possible this is a bug in QTimeZone.
I still have the issue. My locale is now apparently right.
Can you give me the output of $ timedatectl status $ sudo hwclock --debug $ date
$ timedatectl status Local time: Thu 2014-06-05 18:22:44 CEST Universal time: Thu 2014-06-05 16:22:44 UTC RTC time: Thu 2014-06-05 16:22:44 Time zone: n/a (CEST, +0200) NTP enabled: n/a NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2014-03-30 01:59:59 CET Sun 2014-03-30 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2014-10-26 02:59:59 CEST Sun 2014-10-26 02:00:00 CET $ sudo hwclock --debug [sudo] password for david: Sorry, try again. [sudo] password for david: hwclock from util-linux 2.24.1 Using /dev interface to clock. Last drift adjustment done at 1388772877 seconds after 1969 Last calibration done at 1388772877 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2014/06/05 16:23:08 Hw clock time : 2014/06/05 16:23:08 = 1401985388 seconds since 1969 Thu 05 Jun 2014 18:23:08 CEST -0.391118 seconds $ date Thu 5 Jun 18:23:17 CEST 2014 Run at ~18:23, plasma clock shows 16:23 I'm in UTC+2
Created attachment 87028 [details] QTimeZone testapp Ok, I think the "Time zone: n/a (CEST, +0200)" might be the problem. Can you please run the attached code and paste the output?
*** Bug 335951 has been marked as a duplicate of this bug. ***
Hi, coming from bug #335951. The 'tzinfo' utility returned "Europe/London" true Hope that helps...
Thanks; I'll need some additional data. Please run plasmaengineexplorer (make sure it's the one coming from your kf5 env), select "time" and in the list that appears find "Local" (should be the last one), expand that and check if all the data in there are correct (posting a screenshot would also be cool).
Andreas - which distribution are you running btw?
I'm running gentoo. It seems I didn't build plasmaengineexplorer, as I can an only find the one from plasmate (git), which I think is still on kde-4 level. Which kf5 package contains the explorer?
Right; it's part of plasmate now, so please build that, branch frameworks (you can run just the cmake, then cd into build/engineexplorer and build only that folder, no need to install even).
Created attachment 87091 [details] Snapshot of plasmaengineexplorer output Ok, built plasmaengineexplorer as instructed and ran it; the output time there is the correct one.
Oh that's very interesting; thanks. I looked again at the code and all it does is text: Qt.formatTime(dataSource.data["Local"]["Time"], main.timeFormat); So it takes the value directly from the dataengine and passes it to Qt.formatTime(). Either that function is messing things up or there is a wrong conversion between C++ QTime and QML Date. It doesn't happen on my machine however, so that makes debugging that a bit harder. I'd like to try some patches; can you ping me on irc sometime around 2 PM your time (mck182 in #plasma on freenode) if you're interested in helping me debug this, it would be really helpful.
Created attachment 87095 [details] Minimal example to trigger the timezone bug IRC tomorrow afternoon won't work for me, unfortunately, but I was able to isolate the bug; see the attachment for a brief explanation.
Created attachment 87096 [details] Fix for the timezone bug. Patchy patch. Maybe it would be a good idea to have just the "DateTime" object in the source and leave all formatting to the consumer. Going off on a tangent here, but DigitalClock.qml says: // Qt's QLocale does not offer any modular time creating like Klocale did // eg. no "gimme time with seconds" or "gimme time without seconds and with timezone". // QLocale supports only two formats - Long and Short. Long is unusable in many situations // and Short does not provide seconds. So if seconds are enabled, we need to add it here. Not true any more, there's a third mode now, NarrowFormat, which might be very useful in getting rid of all the timeFormatCorrection() stuff: http://qt-project.org/doc/qt-5/qlocale.html#FormatType-enum
That's a perfect work, thank you very much Andreas; I owe you a beer :) That was pretty much what I wanted to try out. > Maybe it would be a good idea to have just the "DateTime" object in the source and leave all formatting to the consumer. The applet is the consumer and the applet does the formatting. Or what formatting you have in mind? > Not true any more, there's a third mode now, NarrowFormat, which might be very useful in getting rid of all the timeFormatCorrection() stuff: The purpose of the timeFormatCorrection() is for options "Show seconds" and "Show timezone", the NarrowFormat for time is pretty much the same as ShortFormat and neither provides seconds or timezone, therefore we need to add it ourselves if the users sets that option...and that's what timeFormatCorrection() does ;)
(In reply to comment #25) > That's a perfect work, thank you very much Andreas; I owe you a beer :) Thanks, give a shout when you happen to be in Oxford. ;) > > Maybe it would be a good idea to have just the "DateTime" object in the source and leave all formatting to the consumer. > > The applet is the consumer and the applet does the formatting. Or what > formatting you have in mind? Returning an object via QDateTime::date() and QDateTime::time() already is kinda sorta pre-formatting, as it drops certain information (and mucks things up, as it turns out). Can't you in principle get any information you want out of the QDateTime object already with the right format string? > > Not true any more, there's a third mode now, NarrowFormat, which might be very useful in getting rid of all the timeFormatCorrection() stuff: > > The purpose of the timeFormatCorrection() is for options "Show seconds" and > "Show timezone", the NarrowFormat for time is pretty much the same as > ShortFormat and neither provides seconds or timezone, therefore we need to > add it ourselves if the users sets that option...and that's what > timeFormatCorrection() does ;) I see... Cheers, Andreas
> Returning an object via QDateTime::date() and QDateTime::time() already is kinda sorta pre-formatting, as it drops certain information (and mucks things up, as it turns out). Can't you in principle get any information you want out of the QDateTime object already with the right format string? Ah yes, that is true. This design is inherited from the KDE4 version of it and I guess it was meant as a kind of shortcut or maybe the KDE4 applet was actually needing it, I don't know. But I agree we can just keep DateTime, remove the rest and use the Qt date/time formatter. I'll cook a patch.
Hm, the Plasma 4-based version never made the transition to QML.
Git commit fa8c62b32a0473cbc70c36226fc731d6c1076183 by Martin Klapetek. Committed on 11/06/2014 at 13:38. Pushed by mklapetek into branch 'master'. Fix time showing applets not showing correct time for some timezones Apparently passing QDateTime::time() to the Qt.formatTime is messing things up; might also be a Qt bug, on the other hand the docs for QTime say that "Unlike QDateTime, QTime knows nothing about time zones or daylight savings time (DST)". Passing the full QDateTime object makes the applets show correct time in all timezones. Hats off to Andreas Eckstein for finding out this M +2 -2 applets/analog-clock/contents/ui/analogclock.qml M +2 -2 applets/digital-clock/package/contents/ui/DigitalClock.qml http://commits.kde.org/plasma-workspace/fa8c62b32a0473cbc70c36226fc731d6c1076183
One more occurance I'm afraid, in the clock I get when I lock the screen. Grepping for '"Time"' points to this file as the offender: /usr/share/plasma/look-and-feel/org.kde.lookandfeel/contents/components/InfoPane.qml
Git commit a7bf16f5bbca8f0767eef45af9bfdf6017f109d7 by Martin Klapetek. Committed on 11/06/2014 at 13:56. Pushed by mklapetek into branch 'master'. Fix time also in the lock screen M +1 -1 lookandfeel/contents/components/InfoPane.qml http://commits.kde.org/plasma-workspace/a7bf16f5bbca8f0767eef45af9bfdf6017f109d7
Fixed, thanks :)