teg at jklm.no
Sat Jan 22 12:44:07 PST 2011
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 947 bytes
Desc: not available
More information about the systemd-devel