Ubuntu 21.10 Time off by 6 hrs

Framework Laptop 13
1

I’m new to my framework (DIY) and not particularly well-versed in linux/ubuntu (fbsd normally).
My time shows 08:49 when it should be 14:49.
Date & Time settings:
Automatic Date and Time on
Automatic Time Zone disabled (location services disabled)
Time Zone MST (Denver, US)
Time format 24-hr
Privacy
Location Services off
The location services settings page has no way to turn the services on, or to turn them on selectively. Since the time zone is set, why doesn’t it show the correct time? At first I thought it was showing UTC, but the offset is backwards and off by an hour. 14:00 MST is 21:00 UTC, not 08:00.

2

What happens if you run sudo dpkg-reconfigure tzdata? Or, what is the output of timedatectl?

3

@Gary_Aitken I had a similar issue (can’t remember exactly, too many installs recently). My solution was to

  • inactivate “Automatic Date & Time,”
  • manually set “Time Zone” by clicking on the existing location (which brings up the map),
  • clicking on the map,
  • backing out and re-activating “Automatic Date & Time”

hth,
-C

4

@Chiraag_Nataraj
timedatectl
Local time: Thu 21-12-09 09:34:34:36 MST
Universal time: 21-12-09 16:34:34:36 UTC
RTC time: 21-12-09 16:34:34:36
Time zone: America/Denver (MST, -0700)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

The actual time was 15:31 local => 22:31 UTC

@CraigO
Didn’t change anything

5

How about timedatectl timesync-status and timedatectl show-timesync? It almost feels like your NTP server might be off…?

6

home/garya%timedatectl timesync-status
Server: n/a (ntp.ubuntu.com)
Poll interval: 8min 32s (min: 32s; max 34min 8s)
Packet count: 0
/home/garya%timedatectl show-timesync
FallbackNTPServers=ntp.ubuntu.com
ServerName=ntp.ubuntu.com
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=8min 32s
Frequency=0
/home/garya%

My other machines are using a local ntp server, but I obviously haven’t set that up yet.

7

Here’s what mine looks like for comparison:

$ timedatectl timesync-status
       Server: 107.194.210.155 (0.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: 11FD067D
    Precision: 1us (-21)
Root distance: 29.280ms (max: 5s)
       Offset: -1.548ms
        Delay: 48.042ms
       Jitter: 15.193ms
 Packet count: 52
    Frequency: -11.699ppm

$ timedatectl timesync-status
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=107.194.210.155
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-21, RootDelay=10.833ms, RootDispersion=23.864ms, Reference=11FD067D, OriginateTimestamp=Thu 2021-12-09 17:59:08 EST, ReceiveTimestamp=Thu 2021-12-09 17:59:08 EST, TransmitTimestamp=Thu 2021-12-09 17:59:08 EST, DestinationTimestamp=Thu 2021-12-09 17:59:08 EST, Ignored=no PacketCount=52, Jitter=15.193ms }
Frequency=-766678

In your case, Server being n/a is very concerning, and I suspect that the issue may be that the Ubuntu NTP server is down. Though, I’m getting an IP address from ntp.ubuntu.com, which might suggest an issue with your DNS resolver? Regardless, the fact that timedatectl isn’t showing an IP address for your NTP server is probably indicative of the problem here.

8

Thanks.
I modified /etc/systemd/timesyncd.conf to add my local server’s IP, then did “service systemd-timesyncd restart” with no obvious effect. Then:
systemctl status systemd-timesyncd.service
systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-12-09 09:40:01 MST; 1h 45min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 8990 (systemd-timesyn)
Status: “Idle.”
Tasks: 2 (limit: 18886)
Memory: 1.0M
CPU: 47ms
CGroup: /system.slice/systemd-timesyncd.service
└─8990 /lib/systemd/systemd-timesyncd

Dec 09 10:13:39 garysframework systemd-timesyncd[8990]: Timed out waiting for reply from 91.189.89.198:123 (ntp>
…
Dec 09 10:31:04 garysframework systemd-timesyncd[8990]: Timed out waiting for reply from 91.189.94.4:123 (ntp.u>

It’s obviously not using my local server.
I suspect the timeout is a result of a slow local wifi connection; unfortunately, I don’t have a way to connect ethernet to get around the wifi router (have USB-C to ethernet converter on order).
In any case, why isn’t it using my local server? From timesyncd.conf:
NTP=192.168.151.101

I notice there are timesyncd.conf files in some of the snaps. Do I have to worry about those?

9

Maybe try restarting systemd-timedated?

Edit: Never mind, the relevant service should be systemd-timesyncd. Do you see an error if you do sudo systemctl restart systemd-timesyncd? Alternatively, do you see anything in the journal (sudo journalctl -xe -u systemd-timesyncd)?

No idea, I avoid snaps like the plague.

10

Do you dual boot with Windows by chance? Windows likes to store the local time in the real-time clock, and Linux usually assumes it’s UTC instead. Treating local time as UTC would get you the offset in the wrong direction, and if daylight savings time differences are also involved that’d get you an extra hour.

3 Likes
11

@Chiraag_Nataraj
Thanks, ugh.
no errors with sudo systemctl restart systemd-timesyncd,
but sudo journalctl -xe -u systemd-timesyncd shows:
(stop and restart stuff)
Dec 09 13:51:27 garysframework systemd-timesyncd[13441]: Timed out waiting for reply from 192.168.151.101:123 (>
Dec 09 19:50:54 garysframework systemd-timesyncd[13441]: Initial synchronization to time server 192.168.151.101>

and the time has been properly set.
So I guess it is some network issue. Not sure why it didn’t load the new server the first time I tried it.

@qbg No dual boot, but thanks for the info, as I will probably be doing a dual boot at some point.

1 Like