Thank you for the report.
I do not have the means nor knowhow to test this, so believe it.
I wonder whether this might be due to some timezone difference - between the inviter and the receiver?

Assigning to the KDE/Plasma team.

Source RPM: korganizer-20.12.0-1.mga8 => korganizer-20.12.0-1.mga8.src.rpm
Summary: korganizer displays wrong time for outlook events => korganizer displays wrong time for Teams invitation events
Assignee: bugsquad => kde

Hmmm maybe a shared quirk with the Plasma panel clock app: Since today (I think) the analog clock show one hour less, but swithing i to digital it shows correct.

Maybe some malfunctioning "daylight saving time" feature?
Here, the shift is in a week, I think.

Dag, I guess from your name you are in Sweden too?

For the clock app it is pretty weird it calulates time differently depending on display!

Do you get the same error in analog clock mode?

CC: (none) => fri

I am actually in Finland, but we do have daylight savings time here too :-) The time zone of KDE and the timezone of the computer is Ok. And as I said Thunderbird and my phone displays the time right. Also the invotor is here in Finland. Checked the invitation and the timezone looks ok to me.From that I assume that the caldav record is correct. 

But you are quite right, Morgan. The analog clock _is_ one hour wrong.

Hello,
I confirm to have a problem on digital clock in LXQt.

CC: (none) => yves.brungard_mageia

See if any of the suggestions from bug 28748 help.

CC: (none) => davidwhodgins

Thing is that it changed overnight, it seems, without reason.
Even if regions are mismatched, there are discrepancies between apps, even in same app (Plasma clock) about what time to display...

For me both MCC and Plasma "systemsetting5/Personalisation/Regional Settings/Date & Time" say region is Europe/Stockholm

Now I issued:
# timedatectl set-timezone Europe/Stockholm

and switched Plasma clock to analog: still wrong, one hour behind.

Now I issued
# ln -sf /usr/share/zoneinfo/Zone/SubZone /etc/localtime

And now all time jumped back two hours, and clock is *three* hours *before* that.

Forgot to back up before last command, but instead went to MCC time setting and told it to sync automatically and am back to the status before this post.

Iḿ tired, So now i stop playing with things i dont grasp...

My understanding is that the plasma digital clock applet uses the system time
as based on the overall system settings as set by mcc, but the analog clock
applet uses the settings from "systemsetting5/Personalisation/Regional Settings/Date & Time". Either that or the other way around. They need to be set to the
same values for timezone, etc.

On my aarch64 rpi 4b, it has the additional problem that it doesn't have an rtc
so it's always Jul 20th, 2021 in the beginning of journalctl -b.

That caused problems with the plasma digital clock applet if plasma started
before chrony had corrected the date/time. Work around is to enable
chrony-wait.service and modify lightdm to wait until it's finished before it
the dm starts.

Checked and all of the settings above in my computer is set to Europe/Helsinki - And has been so for very many years. I haven't caught korganizer with displaying the wrong time before, but do not really know when it started to do so. It is though most disturbing. Already missed one meeting due to this and it was a close call on another...

Note: timedatectl complains about the RTC being set to localtime, instead of UTC. But again this has always been the case.

I think that the problem is in Qt.
Here are some result from Qt outputs within Python:
python3
Python 3.8.12 (default, Sep 12 2021, 19:57:22) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime.currentDateTime()
>>> qdt.toString()
'mar. oct. 26 07:42:15 2021'
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Paris')
>>> tzNow = qdt.toTimeZone(core.QTimeZone(b"Europe/Paris"))
>>> tzNow.toString()
'mar. oct. 26 06:42:15 2021 CET'
>>> qdt.toLocalTime()
PyQt5.QtCore.QDateTime(2021, 10, 26, 7, 42, 15, 631)
>>> qdt.toUTC()
PyQt5.QtCore.QDateTime(2021, 10, 26, 5, 42, 15, 631, PyQt5.QtCore.Qt.TimeSpec(1))
>>> qdt.toLocalTime().toString()
'mar. oct. 26 07:42:15 2021'
>>> qdt.toUTC().toString()
'mar. oct. 26 05:42:15 2021 GMT'

The time from the local time is correct, where timezone is "Europe/Paris", but the time from the time zone  "Europe/Paris" is one hour earlier.

I'm seeing the same issue in the clock on the LXQt panel.

The clock shows 11:26 while the local time (WEST) is 12:26. The happens for other time zones (e.g. CET) as well. I have only noticed it today but this may have something to do with the recent Qt update, two days ago.


$ timedatectl 
               Local time: ter 2021-10-26 12:28:46 WEST
           Universal time: ter 2021-10-26 11:28:46 UTC 
                 RTC time: ter 2021-10-26 11:28:43     
                Time zone: Europe/Lisbon (WEST, +0100) 
System clock synchronized: yes                         
              NTP service: active                      
          RTC in local TZ: no

CC: (none) => mageia

I have run my tests in a "old" Mageia 8 not updated since months.
The problem is the same. 

>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Paris')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'mer. oct. 27 09:04:16 2021 CET'
>>> qdt.toLocalTime().toString()
'mer. oct. 27 10:04:16 2021'
>>> qdt.toUTC().toString()
'mer. oct. 27 08:04:16 2021 GMT'

when the real local time is 10:04
This seems to indicate that the problem was already present and revealed by the current date.
Can this test be run by others?

Open a python3 console, and then:

import PyQt5.QtCore as core
qdt = core.QDateTime.currentDateTime()
core.QTimeZone.systemTimeZoneId()
qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
qdt.toLocalTime().toString()
qdt.toUTC().toString()

It could be interesting to do with a false date before Sunday 24th.

Just noted that we do not need any Teams etc. to repeat the problem.

Added an event to the davical calendar from KOrganizer starting 14:00 today and it shows up at the agenda as startoing at 15:00 !!

I can bet that this problem goes away by itself next week when DST starts here...

[morgan@svarten ~]$ python3
Python 3.8.12 (default, Sep 12 2021, 19:57:22) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Stockholm')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'ons okt. 27 11:11:43 2021 CET'
>>> qdt.toLocalTime().toString()
'ons okt. 27 12:11:43 2021'
>>> qdt.toUTC().toString()
'ons okt. 27 10:11:43 2021 GMT'

Used MCC to set date back a week, then 

>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Stockholm')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'ons okt. 20 12:15:06 2021 CEST'
>>> qdt.toLocalTime().toString()
'ons okt. 20 12:15:06 2021'
>>> qdt.toUTC().toString()
'ons okt. 20 10:15:06 2021 GMT'
>>> 

Next, with date a week forward from now:

>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Stockholm')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'ons nov. 3 12:16:36 2021 CET'
>>> qdt.toLocalTime().toString()
'ons nov. 3 12:16:36 2021'
>>> qdt.toUTC().toString()
'ons nov. 3 11:16:36 2021 GMT'
>>>

I guess it will show up in a half or full year from now.

I ponder rising priority as this really do disturb users work.
But probably we will not get a fix out before it resolves itself for the current half-year anyway...

Does it work in other distros?  

OK in recent KDE Neon:
I launched KDE Neon user edition file:///home/morgan/Hämtningar/neon-user-20211021-0945.iso from https://neon.kde.org/download in VirtualBox:running live mode, set locale to Swedish and the clock applet show correct time both in digital and analog mode.

(In reply to Morgan Leijström from comment #15)
> I guess it will show up in a half or full year from now.

I forgot the word "again"

It works fine in my FC32 desktop, but that is using 

korganizer-19.12.2-1.fc32.x86_64

and

qt-mobility-pim-1.2.2-0.37.20140317git169da60c.fc32.x86_64

> 'mer. oct. 27 09:04:16 2021 CET'
> 'ons nov. 3 12:16:36 2021 CET'
> 'ons okt. 20 12:15:06 2021 CEST'
Note that the output shows the time zone it considers, 'CET' for the winter time, and 'CEST' for the summer time.
Thus the error is that function toTimeZone considers that Central Europe is already in winter time this week. I don't now how this is computed.

(In reply to Dag Nygren from comment #17)
> It works fine in my FC32 desktop, but that is using 
> 
Can you give the output of the above Python script lines from within your Fedora?

Is this what you requested?

% python3
Python 3.8.10 (default, May  4 2021, 00:00:00) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/Helsinki')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Helsinki")).toString()
'ons okt. 27 16:57:25 2021 EEST'
>>> qdt.toLocalTime().toString()
'ons okt. 27 16:57:25 2021'
>>> qdt.toUTC().toString()
'ons okt. 27 13:57:25 2021 GMT'

*** Bug 29595 has been marked as a duplicate of this bug. ***

CC: (none) => joselpddj

This reminded me of bug 27609. And indeed, applying the same "fix" to the timezone package fixes papoteur's Python test.

Before rebuilding/reinstalling the timezone package:

% python3
Python 3.8.12 (default, Sep 12 2021, 19:57:22) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/London')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'Wed Oct 27 20:07:08 2021 CET'

Afterwards:

% python3
Python 3.8.12 (default, Sep 12 2021, 19:57:22) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime.currentDateTime()
>>> core.QTimeZone.systemTimeZoneId()
PyQt5.QtCore.QByteArray(b'Europe/London')
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'Wed Oct 27 21:08:00 2021 CEST'

CC: (none) => mageia

Sounds like a bug in Qt5 then.

This sunday after official change to winter time all Plasma widget clocks are correct - but the calender foldout still shows yesterday.

I have only LXQt installed under Mageia in a virtual machine and today, the time in the panel is now off by one hour (-1). In the U.S., the states that observe Standard Time, do not change the clocks back until 2:00 AM local time Sunday November 7.

I also have three other vm's installed. The incorrect time also appears in PCLinuxOS, but in Fedora and Lubuntu, the displayed time is correct.

CC: (none) => epp

(In reply to Martin Whitaker from comment #22)
> This reminded me of bug 27609. And indeed, applying the same "fix" to the
> timezone package fixes papoteur's Python test.
> 
> Before rebuilding/reinstalling the timezone package:
> 
Hi Martin,
What about pushing this fix?
According to this post [1], we have to use DZIC_BLOAT_DEFAULT set to fat to revert the defaulting to slim which occurs some bugs. This seems to be the fix you applied.
We can think that this is not the good fix, but it seems to be the quicker to apply.
Papoteur

[1] https://github.com/lxqt/lxqt/discussions/2107#discussioncomment-1630059

See also https://bugs.mageia.org/show_bug.cgi?id=27473

There is also a fix in Qt6 about determining the last sunday of the month. 
https://bugreports.qt.io/browse/QTBUG-90553
Perhaps the good fix is to apply this in Qt5?

Fixed in Qt5PatchCollection
https://invent.kde.org/qt/qt/qtbase/-/commit/38a72af4fd311219779f89b2b78cd56d879f61db

Good find, papoteur. That looks to be the proper fix.

added in mga 8/9

src:
    - qtbase5-5.15.2-4.5.mga8

CC: (none) => mageia
Assignee: kde => qa-bugs

Updated a chunk of qt5 libs.
Launching python3
>>> import PyQt5.QtCore as core
>>> qdt = core.QDateTime(2021, 10, 26, 7, 42, 15, 631)
>>> qdt.toUTC().toString()
'mar. oct. 26 05:42:15 2021 GMT'
>>> qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
'mar. oct. 26 07:42:15 2021 CEST'
>>> qdt.toLocalTime().toString()
'mar. oct. 26 07:42:15 2021'

Now, the 2 last commands output the same hour, when before the update, qdt.toTimeZone(core.QTimeZone(b"Europe/Paris")).toString()
gave
'mar. oct. 26 06:42:15 2021 CET'

It seems to me this is a good fix.

@neoclust: can you provide the list of rpms affected?

From http://madb.mageia.org/tools/listRpmsForQaBug/bugnum/29591/application/0

i586 rpms:

libqt5-database-plugin-ibase-5.15.2-4.5.mga8.i586.rpm
libqt5-database-plugin-mysql-5.15.2-4.5.mga8.i586.rpm
libqt5-database-plugin-odbc-5.15.2-4.5.mga8.i586.rpm
libqt5-database-plugin-pgsql-5.15.2-4.5.mga8.i586.rpm
libqt5-database-plugin-sqlite-5.15.2-4.5.mga8.i586.rpm
libqt5-database-plugin-tds-5.15.2-4.5.mga8.i586.rpm
libqt5accessibilitysupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5base5-devel-5.15.2-4.5.mga8.i586.rpm
libqt5bootstrap-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5concurrent-devel-5.15.2-4.5.mga8.i586.rpm
libqt5concurrent5-5.15.2-4.5.mga8.i586.rpm
libqt5core-devel-5.15.2-4.5.mga8.i586.rpm
libqt5core5-5.15.2-4.5.mga8.i586.rpm
libqt5dbus-devel-5.15.2-4.5.mga8.i586.rpm
libqt5dbus5-5.15.2-4.5.mga8.i586.rpm
libqt5devicediscoverysupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5edid-devel-5.15.2-4.5.mga8.i586.rpm
libqt5eglfsdeviceintegration-devel-5.15.2-4.5.mga8.i586.rpm
libqt5eglfsdeviceintegration5-5.15.2-4.5.mga8.i586.rpm
libqt5eglfskmssupport-devel-5.15.2-4.5.mga8.i586.rpm
libqt5eglfskmssupport5-5.15.2-4.5.mga8.i586.rpm
libqt5eglsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5eventdispatchersupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5fbsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5fontdatabasesupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5glxsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5gui-devel-5.15.2-4.5.mga8.i586.rpm
libqt5gui5-5.15.2-4.5.mga8.i586.rpm
libqt5inputsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5kmssupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5linuxaccessibilitysupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5network-devel-5.15.2-4.5.mga8.i586.rpm
libqt5network5-5.15.2-4.5.mga8.i586.rpm
libqt5opengl-devel-5.15.2-4.5.mga8.i586.rpm
libqt5opengl5-5.15.2-4.5.mga8.i586.rpm
libqt5platformcompositorsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5platformsupport-devel-5.15.2-4.5.mga8.i586.rpm
libqt5printsupport-devel-5.15.2-4.5.mga8.i586.rpm
libqt5printsupport5-5.15.2-4.5.mga8.i586.rpm
libqt5servicesupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5sql-devel-5.15.2-4.5.mga8.i586.rpm
libqt5sql5-5.15.2-4.5.mga8.i586.rpm
libqt5test-devel-5.15.2-4.5.mga8.i586.rpm
libqt5test5-5.15.2-4.5.mga8.i586.rpm
libqt5themesupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5vulkansupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5widgets-devel-5.15.2-4.5.mga8.i586.rpm
libqt5widgets5-5.15.2-4.5.mga8.i586.rpm
libqt5xcbqpa-devel-5.15.2-4.5.mga8.i586.rpm
libqt5xcbqpa5-5.15.2-4.5.mga8.i586.rpm
libqt5xkbcommonsupport-static-devel-5.15.2-4.5.mga8.i586.rpm
libqt5xml-devel-5.15.2-4.5.mga8.i586.rpm
libqt5xml5-5.15.2-4.5.mga8.i586.rpm
qtbase5-common-5.15.2-4.5.mga8.i586.rpm
qtbase5-common-devel-5.15.2-4.5.mga8.i586.rpm
qtbase5-doc-5.15.2-4.5.mga8.noarch.rpm
qtbase5-examples-5.15.2-4.5.mga8.i586.rpm


x86_64:

lib64qt5-database-plugin-ibase-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5-database-plugin-mysql-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5-database-plugin-odbc-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5-database-plugin-pgsql-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5-database-plugin-sqlite-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5-database-plugin-tds-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5accessibilitysupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5base5-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5bootstrap-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5concurrent-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5concurrent5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5core-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5core5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5dbus-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5dbus5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5devicediscoverysupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5edid-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eglfsdeviceintegration-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eglfsdeviceintegration5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eglfskmssupport-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eglfskmssupport5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eglsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5eventdispatchersupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5fbsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5fontdatabasesupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5glxsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5gui-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5gui5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5inputsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5kmssupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5linuxaccessibilitysupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5network-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5network5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5opengl-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5opengl5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5platformcompositorsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5platformsupport-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5printsupport-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5printsupport5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5servicesupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5sql-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5sql5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5test-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5test5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5themesupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5vulkansupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5widgets-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5widgets5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5xcbqpa-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5xcbqpa5-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5xkbcommonsupport-static-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5xml-devel-5.15.2-4.5.mga8.x86_64.rpm
lib64qt5xml5-5.15.2-4.5.mga8.x86_64.rpm
qtbase5-common-5.15.2-4.5.mga8.x86_64.rpm
qtbase5-common-devel-5.15.2-4.5.mga8.x86_64.rpm
qtbase5-doc-5.15.2-4.5.mga8.noarch.rpm
qtbase5-examples-5.15.2-4.5.mga8.x86_64.rpm

CC: (none) => andrewsfarm

Tested in 64-bit MGA8 Plasma system.

Chrony had not been installed on this system, making it easy to set system time back to a date a few days before U.S. Eastern Daylight Time had ended. Installed analog clock widget, and confirmed that the time displayed was 1 hour earlier that that displayed by the digital clock in the panel.

Used qarepo to download the 64-bit packages from Comment 33. The following 18 packages are going to be installed:

- lib64qt5-database-plugin-ibase-5.15.2-4.5.mga8.x86_64
- lib64qt5-database-plugin-mysql-5.15.2-4.5.mga8.x86_64
- lib64qt5-database-plugin-sqlite-5.15.2-4.5.mga8.x86_64
- lib64qt5concurrent5-5.15.2-4.5.mga8.x86_64
- lib64qt5core5-5.15.2-4.5.mga8.x86_64
- lib64qt5dbus5-5.15.2-4.5.mga8.x86_64
- lib64qt5eglfsdeviceintegration5-5.15.2-4.5.mga8.x86_64
- lib64qt5eglfskmssupport5-5.15.2-4.5.mga8.x86_64
- lib64qt5gui5-5.15.2-4.5.mga8.x86_64
- lib64qt5network5-5.15.2-4.5.mga8.x86_64
- lib64qt5opengl5-5.15.2-4.5.mga8.x86_64
- lib64qt5printsupport5-5.15.2-4.5.mga8.x86_64
- lib64qt5sql5-5.15.2-4.5.mga8.x86_64
- lib64qt5test5-5.15.2-4.5.mga8.x86_64
- lib64qt5widgets5-5.15.2-4.5.mga8.x86_64
- lib64qt5xcbqpa5-5.15.2-4.5.mga8.x86_64
- lib64qt5xml5-5.15.2-4.5.mga8.x86_64
- qtbase5-common-5.15.2-4.5.mga8.x86_64

No installation issues. After a reboot (logoff/logon might have been enough) the digital and analog clocks were displaying the same time. Restored the correct date, and rebooted once more, confirming that the two clocks still displayed the same time. Everything else appears to be normal.

This looks OK to me. Validating. Needs an advisory.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA8-64-OK
CC: (none) => sysadmin-bugs

Advisory
===================================
There was divergence between time displayed using some Qt function:

The time from the local time (toLocalTime()) was correct, where timezone is for example "Europe/Paris", but the time from the time zone  "Europe/Paris" (with function toTimeZone(core.QTimeZone(b"Europe/Paris")) was one hour earlier for a period around the autumn hour change.
This was in particular sensible in korganizer reminders or in time displayed in analog clock from Plasma or digital clock in LXQt.

With this correction, all time is now correct.
===================================

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0220.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED