If the clock is configured to show Caracas timezone (-4:30), the clock will show the time by one hour off. For example: date command -u: sáb ene 31 03:24:17 UTC 2015 date command: vie ene 30 22:53:28 VET 2015 time displayed by the clock widget: 23:53 (VET) 30/1/15 (one hour off) $ env | grep LANG LANGUAGE= LANG=es_VE.UTF-8 Reproducible: Always Steps to Reproduce: 1. Go to digital clock preferences, timezone tab 2. Select Caracas timezone. 3. Check the "show date" box. 4. Use the mouse wheel to switch the displayed time (the "show local timezone" checkbox does nothing). Actual Results: 23:53 (VET) 30/1/15 Expected Results: 22:53 (VET) 30/1/15 This happens on plasma 5.2.0 (this version isn't shown on the selector at the moment of this bug report).
Hmm, indeed, for some reason we have GMT-3:30 in the engine. Do you know which Qt5 version are you running?
As far as I can say, this offset is probably wrong in Qt and/or the data underneath - QTimeZone for America/Caracas returns 3.5h offset. Iirc Qt takes the data directly from the CLDR database. Adding John Layt who created QTimeZone.
I am running Qt 5.4.
Chile is also affected, and this is Plasma Shell only. Symptoms: a) The correct time is displayed when I: - Right click on the Date/Time applet, select the Time Formats option, if I look at the time displayed in the dialog box, it's the right one. - Lock the screen - Start sddm b) When I use the Digital Clock, I see the current hour minus one (9:56 instead of 10:56) c) When I use the Fuzzy Clock, or the Analog Clock, I see the current hour plus one (11:56 instead of 10:56)
Do you have plasmaengineexplorer installed? If so can you run it, select the "time" engine, locate America/Santiago and check if the time is correct in there? We do have some javascript timezone magic going on in the clock applet so that might be to blame. However I've just added the clock with Chilean timezone and shows me correct time as far as I can say (12:02 as of writing this comment, which is what google suggests too).
I can confirm what Alejandro said. I'm having the exact same problems in Chile, using Plasma 5.2 and Fedora 21. The "date" command shows the correct time, while the clock widgets don't. What I can add is that the tzdata package was recently upgraded from the Fedora repos to the version 2015a, which does introduce some changes for the Chilean time zone. However, these changes should make no difference at this time of the year. I can also confirm that this issue dissapears when downgrading tzdata to its previous version, 2014i.
As in comment #5 --> "Do you have plasmaengineexplorer installed? If so can you run it, select the "time" engine, locate America/Santiago and check if the time is correct in there?" That^ is what will really help. Best in both cases with tzdata 2014i and 2015a.
Created attachment 91136 [details] Santiago time (old tzdata, 2014i)
Created attachment 91137 [details] Santiago time (new tzdata, 2015a) I'm attaching screenshots corresponding to both versions of tzdata. The time in the plasma engine explorer is correct in both cases, while it's wrong in both clock widgets when using the 2015a version of tzdata.
Thanks, that's helpful. And interesting, one applet one hour ahead, one applet one hour behind. Are the applets still wrong with 2015a even if you log out and log back in (or just kill plasmashell and start it again)?
Yes, they're still wrong after restarting plasmashell. I also tried removing ~/.kde/, but it's still the same.
https://bugreports.qt.io/browse/QTBUG-44614
In my case, with local time also set to America/Santiago, not only the time is wrong in the digital time widget, but the date in the calendar which appears after clicking on the digital clock is wrong as well (one day off). So it's not 1 hr. late but 23 hrs. forward.
Created attachment 91991 [details] attachment-12043-0.html Does it work with tzdata 2014j?
(In reply to Nikita Skovoroda from comment #14) > Created attachment 91991 [details] > attachment-12043-0.html > > Does it work with tzdata 2014j? Unfortunately I can't downgrade to 2014j as this tzdata version is no longer available in the Arch repositories.
Just use https://wiki.archlinux.org/index.php/Arch_Rollback_Machine
Ok, it does work correctly with tzdata 2014j.
Most probably it's the same bug ( https://bugreports.qt.io/browse/QTBUG-44614 )
After a distro switch and nagging a bit the KaOS team, I have results. Local: DateTime: vie, abr. 17 15:08:58 2015 GMT QDateTime Offset: -10800 int I couldn't get any meaningful result with America/Santiago, since that location only stores the timezone itself. I got this with Local. The Local data source gives the correct time. At that time, my Plasma clock said 14:08:58.
Also, I don't know if this is relevant, but I'm getting messages of "Time engine Clock skew signaled" in the debug output of my plasmashell process.
After the old date for CLST -> CLT switch, the time and date are once again displayed correctly.
Any updates for this bug? I am still seeing the wrong time on the clock widget in my timezone (-4:30). Updated summary: * Qt 5.4.2. * Plasma 5.3.2. * "date" command shows the correct time. * Login manager (sddm) shows correct time. * System settings -> Regional settings -> Formats: the sample date/time shows correct time. * Analog clock widget shows correct time. * Digital clock shows incorrect time (one hour more). * plasmaengineexplorer -> time source for America/Caracas: shows incorrect time and offset is wrong (should be -16200 instead of -12600). Tried to downgrade my tzdata package to 2014j and reboot but it made no difference at all. Also tried the little QtQuick test in the linked Qt bugreport but got the correct time using both tzdata package versions. tl;dr: everything shows the correct time EXCEPT the digital clock widget (and the time source from the engine explorer).
Created attachment 93436 [details] Clock widgets + engine explorer (tzdata 2015e). Analog clock widget shows the correct time while the digital one doesn't. The offset shown on the engine explorer is wrong, shows -13200 (60*60*-3.5) when it should be -16200 (60*60*-4.5).
This is a Qt bug, and it should be fixed on the Qt side. Check https://bugreports.qt.io/browse/QTBUG-44614 status
Yes, please try nagging the Qt bug report.
According to https://codereview.qt-project.org/#/c/120779/ this is fixed in Qt 5.5, please update.
*** Bug 353864 has been marked as a duplicate of this bug. ***