Bug 2521

/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

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 => RESOLVED
Resolution: (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 => REOPENED
CC: (none) => laidlaws
Resolution: 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 => RESOLVED
Resolution: (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 => REOPENED
Resolution: DUPLICATE => (none)

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.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED