Digital clock applet misbehaving

[reyfer]

As you can see in the snapshot below, I have this annoying bug that is driving me crazy.....the digital clock applet is always showing one hour AHEAD of the actual time......all other clocks in my system show the right time, but the digital clock shows one hour ahead......even from the installer, when choosing timezones, the map on the installer shows the right time but the digital clock on the taskbar shows one hour ahead......how can I fix that?

[claydoh]

My, you look familiar

The only thing I can find related to this is that there is/was a bug in Qt or tzdata that has your time zone has some time zone data info incorrectly defined.

https://bugs.kde.org/show_bug.cgi?id=343610

Either that, or as grumpy Jim mentioned, look to see if you don't have multiple time zones selected in the widget, and in system settings as well.
Which I believe you have already done

[reyfer]

If I set the timezone to UTC -4:30 I get the right time, if I set it to America/Caracas (which is UTC -4:30) I get the wrong time.....it's like for some reason the system thinks the timezone America/Caracas is UTC -3:30 instead of UTC -4:30. But again it only happens on the digital clock, the analog clock has the right time

[evenadam]

What is the output when you run 'date'?

[xennex81]

My God, more digital clock issues. A user in the chat had an issue with the clock not showing the appropriate AM/PM format. He had to go debug the application himself. Not sure what came out of it. He's not online. His $LC_TIME was correct, yet the application misbehaved. It's unfortunate that they are using QLocale and that stuff to obtain the proper time zone setting, you cannot even configure it manually (to your preference) (I mean the local setting, in which format you want to show something). That was something that was possible in KDE4 but not in KDE5. Another detrimental change. Why they constantly throw away stuff that works well is beyond me.

They should stop moving for a while, for a change.

[apachelogger]

My God, more digital clock issues. A user in the chat had an issue with the clock not showing the appropriate AM/PM format. He had to go debug the application himself. Not sure what came out of it. He's not online. His $LC_TIME was correct, yet the application misbehaved. It's unfortunate that they are using QLocale and that stuff to obtain the proper time zone setting, you cannot even configure it manually (to your preference) (I mean the local setting, in which format you want to show something). That was something that was possible in KDE4 but not in KDE5. Another detrimental change. Why they constantly throw away stuff that works well is beyond me.

They should stop moving for a while, for a change.

I feel that I need to clearify this.

Up to and including KDELibs4 KDE software had a more refiend concept of localization (e.g. the fact that you could set time formatting independent of everything else). This was however at odds with the rest of Linux which is using POSIX locales pretty much everywhere for everything (do a web search for 'posix locale' in case you are interested in some of the technical background there). When the advanced KDE stuff was introduced the hope was that eventually the rest of the world would see the error of their ways and would adopt the flexibility of KDE software. Unfortunately this did not happen and since basically everything else is using the (supposedly) inferior locale technology we decided to remove the advanced KDE features in favor of the actual Linux default: locales.

This ultimately is why language&country configuration in Plasma 5 and Kubuntu 15.04+ is only offering Language_Country options for a very limited amount of aspects and doesn't allow you to fully customize every aspect of it. This simply isn't something Linux allows for.

Now, I understand that this is causing some confusion and disappointment, but in the long run this is going to allow for a better and more integrated experience. You might have noticed that in Kubuntu 13.10, 14.04 and 14.10 setting a language+country combination that doesn't exist in real life (such as english&France) in Plasma 4 would cause weird problems in other applications would cause problems in software that isn't using KDE libraries. This was fallout from the very problem KDE's very customizible format caused. If everything about localization can be configured in KDE software but the rest of the Linux system only knows these POSIX locales then one has a really really really hard time to translate between the two and make non-KDE software behave according to expectations. I would know, I spent more than a month on trying to solve this very problem

So what's the net-gain from this change?
The settings you get in Plasma 5 are *exactly* what every Linux application understands as far as localization is concerned. This in turn means that configuring the language&country settings in KDE correctly also applies to every single other application on every Linux distribution. Be it LibreOffice or Firefox or whatever else. This is a level of integration we previously weren't able to provide. Did we have to limit ourselves to make this change happen? Yes. But in the long run we are convinced it is going to pay off by enabling all Linux distributions offer a more coherentlocalization experience.


Also, about the original issue. I don't think this actually has anything to do with it but is instead a specific bug in the digital clock applet, I think the google+ post on this is a good starting point actually. (If it was a foundations problem it would also apply to the analog clock).

[Snowhog]

A clear and detailed explanation. Thanks apachelogger.

[reyfer]

Also, about the original issue. I don't think this actually has anything to do with it but is instead a specific bug in the digital clock applet, I think the google+ post on this is a good starting point actually. (If it was a foundations problem it would also apply to the analog clock).

Exactly, it only happens with the digital clock, analog and even fuzzy clocks are working fine, so it must be something in the digital clock applet code

[reyfer]

Bumping this thread just to say that it is definitely something wrong on the digital clock timezone code, I have this issue not only on Kubuntu, but also on Netrunner, KaOS, all the KDE Plasma 5 distros I have tested have the same issue of the digital clock applet showing the Caracas, Venezuela time zone as UTC -3:30 when it should be UTC -4:30, and the analog clock shows the right time

[Guest]

Very strange behaviour when you add multiple timezones.

The time for Sydney in the Panel is correct (We are not currently in Daylight savings), but when you hover over it shows totally different times for all the timezones that are configured.