It would appear that on 2011-05-02, www.archlinux.org/news/initscripts-update-1/ did say:
> We now strongly discourage the use of HARDWARECLOCK="localtime", as this
> may lead to several known and unfixable bugs. However, there are no plans
> to drop support for "localtime".
And it would appear that /etc/rc.conf now does saith:
> # HARDWARECLOCK: set to "UTC" or "localtime", any other value will result
> # in the hardware clock being left untouched (useful for virtualization)
> # Note: Using "localtime" is discouraged.
Since I multi-boot AND do keep my hardware clock set to local time, I'm a
little bit concerned by this statement. It gives me two questions.
1) just what "Known" bugs that this could lead to are "UNFIXABLE"???
2) While putting something like 'HARDWARECLOCK="DoNotMessWithMyLocalTime"'
would evidently result in the hardware clock not getting overwritten by
the system time on shutdown, How would any value except
'HARDWARECLOCK="localtime"' tell Arch not to expect the hardware clock to
be set to UTC on startup???
I guess I could install ntp and put
ntpd -qg &
in rc.local with the above non-standard rc.conf HARDWARECLOCK definition
to nearly simulate the previous NON-NTP localtime behavior where the
hardware clock was read {at start-up} AND written {at shutdown} BOTH with a
conversion from/to local time...
In that it while it would {I think} incorrectly initially set system time on
boot by interpreting the hardware clock's value as UTC, it would then use ntp
to correct itself to approximately the same time as was indicated by the
local time value that was already in the hardware clock. And then go away.
Then since HARDWARECLOCK wasn't set to either "UTC" nor "localtime" It
shouldn't actually overwrite the hardware clocks localtime with UTC...
My hardware clock may need to be manually reset a little more often But
that's no big deal.
The problem is if for some reason I should boot up when the internet isn't
accessible, there would be no ntp server to correct Arch's misconception
that the hardwareclock was already in UTC which would result in bogus
timestamps on any files I modified during that time (not to mention bogus
clock displays...)
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <<jtwdyp@xxxxxxxx>>
