[systemd-devel] hwclock

[Lennart Poettering]

On Sat, 22.01.11 21:44, Tom Gundersen (teg at jklm.no) wrote:

> Hi guys,
> 
> I'm trying to figure out how our hwclock handling works, and in
> particular if there are any scenarios we don't handle.
> 
> First, I think there is a typo in the explanation given in
> hwclock-load.service. Is the attached patch correct?

Well, it's the UTC offset between system and hw clock. Which clock is
offsetting which other one is a matter of PoV ;-)
 
> Secondly, hwclock allows us to specify whether the hardware clock is
> in utc or localtime, but we don't do this at the moment. In this case
> hwclock will fall-back to localtime (at least it says so in the man
> page, this seems like the completely wrong default to me...). Is the
> intention that the user should run "hwclock --systohc --utc"/"hwclock
> --systohc --localtime" manually to set this? If so, maybe it would be
> worth to put this explicitly in the service file (because the
> semantics here are truly bizarre).

Whether the RTC is UTC or not should be configured in /etc/adjtime, 3rd
line. Some distros have other places for that, but it is definitely our
intention to have this configurable only at one standard place, and that
the adjtime/hwclock maintainers have defined.

See part about "The Adjust Function" on hwclock(8), last paragraph.

> Lastly, hwclock can either read the timezone from /etc/localtime, or
> it can read it from the TZ variable. Would a patch to support the TZ
> variable (maybe in the same place as the locale stuff) be welcome? On
> Arch we configure the timezone in a configuration file rather than
> symlinking into /ush/share/zoneinfo/, and I'd like to keep this
> functionality if possible (now that systemd gives us the opportunity
> to do so cleanly).

I think using env vars for timezone configuration is not a good idea,
and if used should be used exclusively to override system configuration
per-user. I don't think it should be used on the system level and the
hwclock logic we have in there.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.