[Bug]: time is shifting by 2 hours #13

Closed
opened 2026-08-03 18:26:03 +00:00 by FredBezies · 3 comments
FredBezies commented 2026-08-03 18:26:03 +00:00 (Migrated from github.com)

Description

Hello.

I grabbed the last development ISO you made. In Calamares, I choose Europe/Paris to be my timezone. But on first start, displayed time is shifting by 2 hours.

The workaround was to install ntp and enter in a terminal: sudo ntpdate fr.pool.ntp.org

I tried to activate automatic sync for time in KDE date and time settings option, but I'm unable to activate this option.

So which ntp tool - ntp ? chrony ? openntpd ? - is used here and can be used to automatically sync your local
time ?

Thanks a lot for your answer.

Have a good day.

Steps to Reproduce

  1. Grab last development ISO
  2. Install it in a Virtual Machine
  3. Set for a timezone, like Europe/Paris one
  4. Look at time

Expected Behavior

No time shift.

Actual Behavior

Time is 2 hours in the future

Environment

  • ISO version: last one from July 28th
  • Install method: Calamares online
  • Desktop: KDE

Relevant Log Output


Code of Conduct

  • I agree to follow this project's Code of Conduct
### Description Hello. I grabbed the last development ISO you made. In Calamares, I choose Europe/Paris to be my timezone. But on first start, displayed time is shifting by 2 hours. The workaround was to install ntp and enter in a terminal: sudo ntpdate fr.pool.ntp.org I tried to activate automatic sync for time in KDE date and time settings option, but I'm unable to activate this option. So which ntp tool - ntp ? chrony ? openntpd ? - is used here and can be used to automatically sync your local time ? Thanks a lot for your answer. Have a good day. ### Steps to Reproduce 1. Grab last development ISO 2. Install it in a Virtual Machine 3. Set for a timezone, like Europe/Paris one 4. Look at time ### Expected Behavior No time shift. ### Actual Behavior Time is 2 hours in the future ### Environment - ISO version: last one from July 28th - Install method: Calamares online - Desktop: KDE ### Relevant Log Output ```shell ``` ### Code of Conduct - [x] I agree to follow this project's Code of Conduct
c-ludenberg commented 2026-08-04 18:12:16 +00:00 (Migrated from github.com)

hey fred, good catch — this was a real bug, now fixed.
short version: the iso ships ntp (ntp-dinit) but never enables the ntpd service at install time. so nothing ever syncs the clock. your vm's rtc holds local time (qemu likes -rtc base=localtime, and paris = utc+2 in summer) while linux treats /etc/adjtime as utc. so at boot it reads that paris value as utc and the clock lands 2h ahead. your ntpdate workaround is literally what ntpd does automatically — that's why it fixed the display.
fix is merged for the next dev iso: ntpd enabled in services-artix.conf (offline + online). first boot, as long as you have network, it corrects within seconds. no manual steps.
to your "ntp / chrony / openntpd?" — it's ntp (ntp-dinit). you don't need the others.
and the greyed-out kde "automatic sync" toggle: expected. that toggle controls systemd-timesyncd, but this is a dinit box — no systemd to drive it. time still syncs fine via ntpd, the toggle just has nothing to do. cosmetic.
if you can retest on the next dev iso (or on your current install: sudo dinitctl enable ntpd && sudo dinitctl start ntpd), the shift should be gone. thanks for the clean report — zero digging needed.

hey fred, good catch — this was a real bug, now fixed. short version: the iso ships ntp (ntp-dinit) but never enables the ntpd service at install time. so nothing ever syncs the clock. your vm's rtc holds local time (qemu likes -rtc base=localtime, and paris = utc+2 in summer) while linux treats /etc/adjtime as utc. so at boot it reads that paris value as utc and the clock lands 2h ahead. your ntpdate workaround is literally what ntpd does automatically — that's why it fixed the display. fix is merged for the next dev iso: ntpd enabled in services-artix.conf (offline + online). first boot, as long as you have network, it corrects within seconds. no manual steps. to your "ntp / chrony / openntpd?" — it's ntp (ntp-dinit). you don't need the others. and the greyed-out kde "automatic sync" toggle: expected. that toggle controls systemd-timesyncd, but this is a dinit box — no systemd to drive it. time still syncs fine via ntpd, the toggle just has nothing to do. cosmetic. if you can retest on the next dev iso (or on your current install: sudo dinitctl enable ntpd && sudo dinitctl start ntpd), the shift should be gone. thanks for the clean report — zero digging needed.
FredBezies commented 2026-08-05 18:41:12 +00:00 (Migrated from github.com)

Well, I still have to do a sudo ntpdate fr.pool.ntp.org to get the right time. Maybe the fix in the ISO is better than manually installing and enable ntpd.

And I'm used to write bug reports. 17 years of using Archlinux helps a little here :)

Well, I still have to do a sudo ntpdate fr.pool.ntp.org to get the right time. Maybe the fix in the ISO is better than manually installing and enable ntpd. And I'm used to write bug reports. 17 years of using Archlinux helps a little here :)
FredBezies commented 2026-08-09 09:09:14 +00:00 (Migrated from github.com)

Sorry to say that, but with last ISO from github action https://github.com/Antergos-NeXT/antergos-iso/actions/runs/31129619700 I still have a time shift. Ouch :(

Sorry to say that, but with last ISO from github action https://github.com/Antergos-NeXT/antergos-iso/actions/runs/31129619700 I still have a time shift. Ouch :(
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Euri-Linux/euri-iso#13