[arch-general] OK so HARDWARECLOCK="localtime" is "strongly discouraged" BUT???

[Tom Gundersen]

On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook <jtwdyp at ttlc.net> wrote:
> It would appear that on Jul 11, Thomas Bächler did say:
>> This is no reason. Especially if you dual-boot, keeping the hardware
>> clock in UTC is something to make your life so much easier.
>
> NOT dual-boot, Multi-boot, And I don't think in UTC <see above>

The more OS'es you have, the better reason to keep RTC in UTC. You
shouldn't need to _think_ about time at all... Anyway, if you want to
do it, I will not try to persuade you otherwise.

>> > 1) just what "Known" bugs that this could lead to are "UNFIXABLE"???
>>
>> - Inconsistencies due to switches from/to DST.
>> - Weird bugs (like in fsck) due to time changing during bootup.
>
> OK I'll buy that I do NOT want fsck to phsck up my filesystem...

The point is: The time in your system will from time to time be wrong,
and this might lead to weird things happening. Usually with fsck.

> Hence my willingness to put "ntpd -qg &" in rc.local and prevent system
> time from "FIXING" my hardwareclock...
> As much as I also don't like letting the internet set my system time.
> (some things just shouldn't be totally automatic.) I mean if this
> trend goes much further people will stop wanting to slice their own bread
> anymore...<snicker>.

If you insist on having RTC in LOCALTIME, then the best thing you can
do is to set this value in rc.conf, and enable ntp (no need for
rc.conf, just enable the daemon).

This will work as well (or as badly) as it did before we added this
warning, nothing really changed.

For the record (for anyone else reading this): using LOCALTIME is
never the right thing to do (though it will work "well enough" most of
the time).

HTH,

Tom