In /var/log/dmesg, I see systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time. but, it's actually applying a delta of +240 minutes, so the clock is set 8 hours ahead of the real localtime. # cat /etc/sysconfig/clock ZONE="Canada/Eastern" UTC=false ARC=false
Assignee: bugsquad => eugeni
/etc/sysconfig/clock seems to be only used by ntpd sysinit initscript, so it's quite normal for him to be ignored by systemd. However, I can't figure out how to configure clock usage in systemd, excepted through ntpd.
CC: (none) => guillomovitch
*** Bug 2742 has been marked as a duplicate of this bug. ***
Created attachment 795 [details] /lib/systemd/system/hwclock-load.service Copied from Mandriva 2011. After copying, ran systemctl enable hwclock-load.service After a reboot, time is correct.
Created attachment 796 [details] /lib/systemd/system/hwclock-save.service Also copied from Mandriva, but the systemctl enable fails, so I don't think it'll update the hardware clock on shutdown/reboot.
*** Bug 2957 has been marked as a duplicate of this bug. ***
CC: (none) => ramaspaceship
Blocks: (none) => 2120
Interesting information: systemd doesn't support localtime for HW clock: https://wiki.archlinux.org/index.php/Systemd#Why_does_systemd_not_support_the_RTC_being_in_localtime.3F
According to https://bugzilla.redhat.com/show_bug.cgi?id=707877, hwclock-load.service and hwclock-save.service are deprecated in systemd. BTW, I couldn't find them in mandriva anymore.
Created attachment 957 [details] RealTimeIsUniversal.reg Now that I know about the reg key to have windows work with the hardware clock set to utc, I'm changing my system. Perhaps we should consider only supporting hardware clock with utc. In the first boot, provide a link to the attached registry file, and an explanation that existing Mageia or Mandriva systems can be changed using mcc/System/Manage Date and Time, Change Time zone/Select correct time zone normally, then answer yes to the question "Is your hardware clock set to GMT", or by manually changing the word LOCAL to UTC in /etc/adjtime, and changing UTC=false to UTC=true in /etc/sysconfig.clock.
WARNING: The attached registry file seems to be only for the EASTERN timezone, not everywhere. May-be the only helpful value inside it is '"RealTimeIsUniversal"=dword:00000001' as suggested by the Arch Linux wiki link above. I will make a try next time I use Windows. If using UTC only is chosen (why not but a fix for systemd is needed anyway, as it is buggy here: it should detect local time for hardware clock and not assume UTC only), no manual change should be done by the user (I mean that system files must be adjusted by the install tool). Anyway, this could be of no interest for connected computers if ntp worked (see bug 2958), and this is the reason why the hwclock-xxxx-service scripts were dropped.
(In reply to comment #9) > WARNING: The attached registry file seems to be only for the EASTERN timezone, > not everywhere. May-be the only helpful value inside it is > '"RealTimeIsUniversal"=dword:00000001' as suggested by the Arch Linux wiki link > above. I will make a try next time I use Windows. Sorry, I didn't examine the file contents after exporting it from regedit (after adding it as sper the Arch Linux wiki link). I thought I had only exported the one key, not the group of keys.
can you test with systemd + initscripts from testing to tell if this is still valid ?
CC: (none) => dmorganec
Closer but still off. Clock time was roughly 1930 (2330 utc). Changed UTC to local in /etc/adjtime, and set UTC to false in /etc/sysconfig/clock. Rebooted, used the bios setup to set the time to 1930. After booting into cauldron with systemd and initscritps 9.25-0.3.mga2, the date command shows the local time as 2330. So it is adding 4 hours to the hardware clock, as it should, to figure out what the current utc time is, but it's using that result as localtime, instead of as the utc time. Btw, I figured out how to avoid the lockup at shutdown. The service vnstat has to be uninstalled, not just disabled. There seems to be a problem with systemd trying to run vnstat when eth0 is stopped, even if it's been disabled.
Since the last update, without changing anything in the clock configuration, the loca
Since the last update, without changing anything in the clock configuration, the local time is now correctly displayed.
(In reply to comment #14) > Since the last update, without changing anything in the clock configuration, > the local time is now correctly displayed. Same for all people here ?
Assignee: eugeni => bugsquad
Looks good here. Just to be sure it wasn't just ntpd fixing the time, I rebooted into a cauldron install with the ethernet disconnected. The time was still set correctly.
Ok thanks, feel free to reopen
Status: NEW => RESOLVEDResolution: (none) => FIXED
I have a similar problem with Mageia 2 Alpha. I have installed the KDE version Live CD to my hard drive. DMESG: RTC time: 6:57:09, date: 11/29/11 This was correct local time, but the digital clock was showing 17:57 My timezone is Australian Eastern Daylight Saving: GMT + 11 hours. HW clock is NOT set to GMT. If I correct the clock in Mga 2, I change the hardware clock, and it is wrong elsewhere. I am not "techy" enough to give the same details as Dave.
Status: RESOLVED => REOPENEDCC: (none) => laidlawsResolution: FIXED => (none)
It works properly now when systemd is used, which is what this bug report was raised for. There is a separate bug for getting the time correct when using sysvinit. See bug 3512. Please confirm your system is using sysvinit, and if so, re-close this bug as a duplicate of 3512.
This is over my head, but I haven't changed anything from a standard installation, so I suppose that it is still sysvinit.
Easiest way to confirm which is being used is to run the command ps 1 If it shows the command is init, then sysvinit is being used. Otherwise, it'll show /bin/systemd.
Before I read that I checked that there is the usual /etc/init.d hierarchy. That is a clue, I believe. I will close this bug and do nothing until I have downloaded the DVD.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Changed status to "Duplicate of Bug 3512." *** This bug has been marked as a duplicate of bug 3512 ***
Resolution: FIXED => DUPLICATE
This is absolutly not a duplicate: #3512 is about problem when using sysvinit, when this is about a problem using systemd.
Status: RESOLVED => REOPENEDResolution: DUPLICATE => (none)
Summary: Clock is set to utc + 4 hours when it should be utc - 4 hours. => clock setting issue with systemd
OK, I finally manage to fix the issue. Contrarily to what is stated in the arch wiki, systemd perfectly support hardware clock in either local or universal time. /etc/adjtime content should however match the reality, otherwise systemd will apply a wrong correction. hwclock --systohc --utc/--localtime will update /etc/adjtime, and dmeg | grep RTC will tell what systemd does at boot time.