[systemd-devel] hwclock

[Kay Sievers]

On Sat, Jan 22, 2011 at 21:44, Tom Gundersen <teg at jklm.no> wrote:
> 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?
>
> 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).
>
> 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).

We call hwclock --systz, which should apply the local timezone offset if needed.

The time itself should be set by by the compiled-in kernel's rtc
driver at bootup:
  [    0.809694] rtc_cmos 00:07: setting system clock to 2011-01-22
17:43:27 UTC (1295718207)

Usual dual boot boxes should set Windows to UTC time too and not rely
aon any rtc-in-locatime nonsense. That works fine for years now.

The only real problem is booting live CDs, where we don't know the
timezone, and should not touch the rtc on shutdown.

Kay