Hello,
Since DST a weekend ago, my Gnome shell shows the wrong time. It is one hour ahead, yet the system time is correct:
# timedatectl
Local time: Tue 2020-11-03 11:42:34 CET
Universal time: Tue 2020-11-03 10:42:34 UTC
RTC time: Tue 2020-11-03 10:42:34
Time zone: Europe/Amsterdam (CET, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
# hwclock --show
2020-11-03 11:42:13.841795+01:00
When I go to Gnome settings > Details > Date & Time > I can see the timezone set to CEST (Amsterdam, Netherlands) which is correct, yet the Gnome shell claims the time isn’t 11:42 but 12:42 instead.
The options Automatic Date & Time and Automatic Time Zone are switched on. When turned off, the time remains wrong. I can set the time manually when these settings are turned off, but that only causes time to drift.
I have two laptops with the same problem. Both systems are running Leap 15.2 with Gnome version 3.34.7
https://i.ibb.co/h89B3Qn/Screenshot-from-2020-11-03-12-42-00.png](https://ibb.co/Hg4t5wM)
Looks like your seeing this bug: “Gnome shows wrong time after update timezone to 2020b-lp152.3.3.1” https://bugzilla.suse.com/show_bug.cgi?id=1178349
You can downgrade the package to 2020a-lp152.2.1, or wait for the fixed package to arrive in the repositories.
Ah thank you. I did not find this issue before.
Similar problem with my Leap 15.2 with GNOME Version 3.34.7.
Other than different time zones the main difference when view Gnome settings > Details > Date & Time >
am seeing the Automatic Time Zone is not displayed.
My GNOME top of the screen clock incorrectly shows UTC+10:00 AEST while system shows UTC+1100 AEDT
paulparker@linux-hxi5:~> sudo hwclock --show
2020-11-04 09:05:45.280424+11:00
paulparker@linux-hxi5:~> sudo timedatectl
Local time: Wed 2020-11-04 09:05:48 AEDT
Universal time: Tue 2020-11-03 22:05:48 UTC
RTC time: Tue 2020-11-03 22:05:48
Time zone: Australia/Sydney (AEDT, +1100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
paulparker@linux-hxi5:~>
The good more Technical team are working on it
.
new “timezone” and “timezone-java” packages (2020d-lp152.8.1) have been release now which, hopefully, fixes this issue.