Created attachment 11989 [details]
Screen capture with default

Hi, thanks reporting this bug.

This is reproduced in a VM M7 GNOME default settings and timezone is Europe/Paris same as Central Europe Time.

So, to sum up:
- GNOME clock is 1 hour far away more than Real Time.
- timedatectl command displays the good Real Time.

Assigning to GNOME maintainers.

Assignee: bugsquad => gnome
CC: (none) => ouaurelien

Confirmed on my system using xorg, not wayland.

Primary user is using tty1 signed into plasma. Time displayed correctly.
Testing user is signed into tty2 signed into gnome. Time at the top of the screen
and in the gnome clocks application are 1 hour into the future.

I'm also using utc for system time.

$ ll /etc/localtime 
lrwxrwxrwx 1 root root 36 Dec  7  2018 /etc/localtime -> ../usr/share/zoneinfo/Canada/Eastern

# cat /etc/adjtime 
-0.223635 1579037991 0.000000
1579037991
UTC

# cat /etc/sysconfig/clock
UTC=true
ZONE=Canada/Eastern
ARC=false

CC: (none) => davidwhodgins

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

CC: (none) => listas.apl

gnome applications appear to be displaying the time assuming that daylight
saving time is still in effect, kde plasma and system applications correctly
display the time recognizing that the local time is now standard time.

Note from bug 27610 that this can be temporarily fixed by downgrading to timezone-2019c.1.mga7.

CC: (none) => mageia

Culprit is GLib and fixed in Glib 2.66.2 release that's why Cauldron appears to not be affected.

This has been fixed in upstream merge here:
https://gitlab.gnome.org/GNOME/glib/-/issues/2224

https://gitlab.gnome.org/GNOME/glib/-/milestones/57

https://gitlab.gnome.org/GNOME/glib/-/issues/2224

I really don't know if commits can be applied in glib2.0-2.60.2-1.3.mga7.

Status comment: Gnome with timezone-2020d-1.mga7 => Gnome with timezone-2020d-1.mga7 displays clock with one hour ahead. Culprit: Glib2.0-2.60.2 fixed upstream with commits in Glib 2.66.
Source RPM: timezone-2020d-1.mga7.src.rpm => glib2.0-2.60.2-1.3.mga7.src.rpm

Hello to contribute and simplify task here it is an little script

#!/bin/bash
# by surfzoid
echo This script will corect the bad time display in gnome with the buggy Glib when read timezone 2020d rpm.
if [ 0 -eq $(id -ru) ];
 then echo "we have root aces" ; 
 
grep '/^timezone-2020d-1.mga7.x86_64/' /etc/urpmi/skip.list &>/dev/null ; if [ 0 -eq ${?} ];
 then echo "timezone-2020d-1.mga7.x86_64,Already in skip list..." ;
 else echo '/^timezone-2020d-1.mga7.x86_64/' >> /etc/urpmi/skip.list; fi
 
grep '/^timezone-java-2020d-1.mga7.noarch/' /etc/urpmi/skip.list &>/dev/null ; if [ 0 -eq ${?} ];
 then echo "timezone-java-2020d-1.mga7.noarch,Already in skip list..." ;
 else echo '/^timezone-java-2020d-1.mga7.noarch/' >> /etc/urpmi/skip.list >> /etc/urpmi/skip.list; fi
 
urpmi --auto --downgrade timezone-2019c timezone-java-2019c

else echo "this script need to be run as root user." ; fi
exit 0

CC: (none) => surfzoid

Created attachment 11992 [details]
script to automate the downgrad and skip list for update

(In reply to Aurelien Oudelet from comment #7)
> Culprit is GLib and fixed in Glib 2.66.2 release that's why Cauldron appears
> to not be affected.
> 
> This has been fixed in upstream merge here:
> https://gitlab.gnome.org/GNOME/glib/-/issues/2224
> 
> https://gitlab.gnome.org/GNOME/glib/-/milestones/57
> 
> https://gitlab.gnome.org/GNOME/glib/-/issues/2224
> 
> I really don't know if commits can be applied in glib2.0-2.60.2-1.3.mga7.

That appears to be a different (even if similar) issue.  The commit that fixed it was reverting a change in glib2.0 which was made after the version in Mageia 7.

I found where they backported the fix to Fedora 33 where they also fixed another timezone related issue, and I was able to apply that patch to our glib2.0 package in SVN, but I doubt it will fix this bug.

No, I think the real issue is this line in the release notes for tzdata 2020b:

    zic now defaults to '-b slim' instead of to '-b fat'.

Support for the slim format was only added in GLib 2.65.

Only one way to find out :o)  Please test.

glib2.0-common-2.60.2-1.4.mga7
libglib2.0_0-2.60.2-1.4.mga7
libgio2.0_0-2.60.2-1.4.mga7
libglib2.0-devel-2.60.2-1.4.mga7
libglib2.0-static-devel-2.60.2-1.4.mga7
glib-gettextize-2.60.2-1.4.mga7

from glib2.0-2.60.2-1.4.mga7.src.rpm

(In reply to Martin Whitaker from comment #11)
> No, I think the real issue is this line in the release notes for tzdata
> 2020b:
> 
>     zic now defaults to '-b slim' instead of to '-b fat'.
> 
> Support for the slim format was only added in GLib 2.65.

Oh good catch.  Do we fix that in glib2.0 or timezone?

I'd guess it's much easier and safer to fix it in timezone.

(In reply to David Walser from comment #13)
> (In reply to Martin Whitaker from comment #11)
> > No, I think the real issue is this line in the release notes for tzdata
> > 2020b:
> > 
> >     zic now defaults to '-b slim' instead of to '-b fat'.
> > 
> > Support for the slim format was only added in GLib 2.65.
> 
> Oh good catch.  Do we fix that in glib2.0 or timezone?

Upstream tends to go for '-b slim'... So, this is like egg or chicken first.

But as Martin said, this is safer to reverra Timezone as long as it does not introduce issue.

I see this in the tzcode Makefile, which might be relevant:
# Rearguard users might also want "ZFLAGS = -b fat"; see below.

But that also reminds me, this commit should not have been backported to Mageia 7:
http://svnweb.mageia.org/packages?view=revision&revision=1610859

I wonder if reverting that would be enough to fix this.

CC: (none) => luigiwalser, nicolas.salguero

(In reply to David Walser from comment #12)
> Only one way to find out :o)  Please test.
> 
> glib2.0-common-2.60.2-1.4.mga7
> libglib2.0_0-2.60.2-1.4.mga7
> libgio2.0_0-2.60.2-1.4.mga7
> libglib2.0-devel-2.60.2-1.4.mga7
> libglib2.0-static-devel-2.60.2-1.4.mga7
> glib-gettextize-2.60.2-1.4.mga7
> 
> from glib2.0-2.60.2-1.4.mga7.src.rpm

No change. Still correct under plasma, 1 hour forward under gnome.

Changing the default back to fat fixes the bug on my machine. I'll push a build to updates_testing.

(In reply to Martin Whitaker from comment #19)
> Changing the default back to fat fixes the bug on my machine. I'll push a
> build to updates_testing.

Make sure you revert that commit I referenced as well.

(In reply to David Walser from comment #20)
> Make sure you revert that commit I referenced as well.
That took a bit of unpicking...

Please test timezone-2020d-1.1.mga7 from core/updates_testing when it reaches the mirrors.

Advisory:
----------------------------------------

A recent update to the timezone package uncovered multiple bugs in timezone
handling in glib2.0.  One of the bugs in glib2.0 has been patched and two of
the changes in timezone have been reverted.

References:
https://advisories.mageia.org/MGASA-2020-0418.html
https://gitlab.gnome.org/GNOME/glib/-/issues/2215
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
glib2.0-common-2.60.2-1.4.mga7
libglib2.0_0-2.60.2-1.4.mga7
libgio2.0_0-2.60.2-1.4.mga7
libglib2.0-devel-2.60.2-1.4.mga7
libglib2.0-static-devel-2.60.2-1.4.mga7
glib-gettextize-2.60.2-1.4.mga7
timezone-2020d-1.1.mga7
timezone-java-2020d-1.1.mga7

from SRPMS:
glib2.0-2.60.2-1.4.mga7.src.rpm
timezone-2020d-1.1.mga7.src.rpm

Assignee: gnome => qa-bugs
Status comment: Gnome with timezone-2020d-1.mga7 displays clock with one hour ahead. Culprit: Glib2.0-2.60.2 fixed upstream with commits in Glib 2.66. => (none)

Confirmed fixed.

Checked by starting gnome on tty2 and correct time shown.

Rebooted due to microcode update, and confirmed both kde plasma on tty1 and
gnome on tty2 were showing the correct time.

Validating the update.

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

Advisory committed to svn.

Keywords: (none) => advisory

Correct time is displayed in M7 GNOME i586 and x86_64 VM after a reboot.
Plasma still displays the correct time.
This is a global OK. Great job all.

Whiteboard: MGA7-64-OK => MGA7-64-OK, MGA7-32-OK

I have updated this morning with update testing and after reboot, it's all good at home.

Thank you!

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

https://advisories.mageia.org/MGAA-2020-0231.html

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