Daylight saving time didn't activate

Hi, yesterday in Italy started the DST but nothing changed on my config.
I may be using UTC. What can I do?
Thanks

What does timedatectl show you?
It should show local time, UTC, RTC, and time zone. If not properly set then the system time in bios may need to be reset to UTC and the date and time settings in the control panel properly set for the local time zone.
This is mine

$ timedatectl
               Local time: Mon 2023-03-27 08:00:46 CDT
           Universal time: Mon 2023-03-27 13:00:46 UTC
                 RTC time: Mon 2023-03-27 13:00:46
                Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
2 Likes

I have “no” on “System clock synchronized”

Make sure the NTP service is enabled and running:

sudo timedatectl set-ntp true
sudo systemctl enable chronyd.service
sudo systemctl restart chronyd.service
1 Like

Nothing changed, that’s what i get with timedatectl

Local time: gio 2023-03-30 13:11:50 CEST
Universal time: gio 2023-03-30 11:11:50 UTC
RTC time: gio 2023-03-30 11:11:50
Time zone: Europe/Rome (CEST, +0200)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

1 Like

Check the output:

systemctl status chronyd.service
chronyc -n sources
grep -e ^server -e ^pool /etc/chrony.conf

First one print

â—Ź chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-03-30 12:54:18 CEST; 1h 53min ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 916 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 940 (chronyd)
Tasks: 1 (limit: 8646)
Memory: 4.9M
CPU: 137ms
CGroup: /system.slice/chronyd.service
└─940 /usr/sbin/chronyd -F 2

mar 30 12:54:18 fradora systemd[1]: Starting chronyd.service - NTP client/server…
mar 30 12:54:18 fradora chronyd[940]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER >
mar 30 12:54:18 fradora chronyd[940]: Frequency -9.450 +/- 0.644 ppm read from /var/lib/chrony/drift
mar 30 12:54:18 fradora chronyd[940]: Using right/UTC timezone to obtain leap second data
mar 30 12:54:18 fradora chronyd[940]: Loaded seccomp filter (level 2)
mar 30 12:54:18 fradora systemd[1]: Started chronyd.service - NTP client/server.
mar 30 13:26:53 fradora chronyd[940]: Source 85.199.214.99 replaced with 212.6.50.243 (2.fedora.pool.ntp.org)
mar 30 14:05:33 fradora chronyd[940]: Source 31.207.113.74 replaced with 93.94.88.50 (2.fedora.pool.ntp.org)
mar 30 14:40:01 fradora chronyd[940]: Source 129.152.16.145 replaced with 162.159.200.123 (2.fedora.pool.ntp.org)

Second one print a table with different addresses all with same line “0 10 0 - +0ns[ +0ns] +/- 0ns”
Last one print "2.fedora.pool.ntp.org iburst
"

1 Like

Looks like it doesn’t want to work. I will live my life 1h later xD

Verify your timezone:

You can change the timezone like this:
Configuring the Date and Time :: Fedora Docs

Yes it is correct

1 Like

Actually your clock may be correct. You did not give an actual location so I checked for Rome.

According to the system data for time zones the standard time is in zone CET and the savings time is in CEST.

I checked for Rome and I find this data, showing +1 for CET and +2 for CEST, which started on March 26, 2023.

# zdump -v Europe/Rome | grep 2023
Europe/Rome  Sun Mar 26 00:59:59 2023 UT = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600
Europe/Rome  Sun Mar 26 01:00:00 2023 UT = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200
Europe/Rome  Sun Oct 29 00:59:59 2023 UT = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200
Europe/Rome  Sun Oct 29 01:00:00 2023 UT = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600

That data comes from the tzdata package which is currently version

tzdata.noarch                      2022g-1.fc37             @updates

It seems the sync of time using NTP is not functioning properly but the time may be actually set properly.

2 Likes

BTW it looks correct. @fradepe isn’t it?

This is before March 26

$ $ timedatectl
               Local time: Sat 2023-03-25 21:53:41 CET
           Universal time: Sat 2023-03-25 20:53:41 UTC
                 RTC time: Sat 2023-03-25 20:53:41
                Time zone: Europe/Rome (CET, +0100)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

This is after March 26

$ timedatectl
               Local time: Thu 2023-03-30 21:59:03 CEST
           Universal time: Thu 2023-03-30 19:59:03 UTC
                 RTC time: Thu 2023-03-30 19:59:03
                Time zone: Europe/Rome (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no
1 Like

Yes, it is, but i have UTC with 1h less

It should show something like

MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^+ 84.245.9.254                  1   6    17    65   -213us[ -271us] +/- 7394us
^- 164.92.155.23                 2   6    35    59   -302us[ -302us] +/- 8033us
^- 213.136.0.252                 1   6    17    64   +216us[ +216us] +/-  307ms
^* 62.204.66.235                 2   6    17    65   +114us[  +56us] +/- 7034us

If your network dosn’t allow access to the ntp servers, you can set the time correctly and then run the command

hwclock -w

If you multiboot windows, then it will mess with the hardware clock.

I do. Should i try?

That’s what i get from hwclock --verbose

hwclock from util-linux 2.38.1
System Time: 1680242793.739863
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 0 seconds after 1969
Last calibration done at 0 seconds after 1969
Hardware clock is set on UTC
It is assumed that the hardware clock is kept in UTC time.
Waiting signal from clock…
…clock signal received
Time read from the hardware clock: 2023/03/31 06:06:34
Hw clock time : 2023/03/31 06:06:34 = 1680242794 seconds since 1969
Time since last adjustment is 1680242794 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2023-03-31 08:06:33.889112+02:00

Somthing was in italian so i translated (I hope right)

Someone who do multiboot, might advice on that.

If you run

LC_ALL=C.UTF8 hwclock --verbose

You will get all messages in English.

Check the config within windows. It is possible time is set wrong there and it may carry over to linux via the RTC settings.

Check the bios time settings and ensure it is set properly at UTC as timedatectl seems to indicate.

The timedatectl output you posted above in post #5 shows the proper time zone and the 2 hour difference between UTC and local time so other than making sure you have the the proper RTC & UTC settings and getting NTP to function properly I see nothing specific to address.

Note that if the RTC/UTC setting is quite some time different than the actual UTC then NTP cannot make the adjustment and sync it for you.

Hello everyone, i wanted to write here with a working solution but apparently it did everything on his own. Now it shows correct time. :upside_down_face:
Thank you everyone

1 Like