It would appear that on Jul 11, Tom Gundersen did say:
On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:
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.
Thank you! To me it's a freedom of choice issue. It may not be the wisest choice I could have made. But I drew this particular line in the sand a long time ago. And while I might even change my mind someday, I would do so only for my own reasons and NOT because the prevailing wisdom says it would be the wise thing to do...
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.
Speaking of which, I have occasionally seen fsck be forced due to {I think it said} "filesystems last access time in future" or some such thing. Is that the most severe "weird" thing likely to happen 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).
Actually, I got the rc.local (not rc.conf) method from an Arch wiki https://wiki.archlinux.org/index.php/NTP in the section labeled "Syncing the clock without running the daemon" Again I recognize that the prevailing wisdom is that daemonizing the process is better... But longstanding preferences die hard.
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).
It would appear that on Jul 11, Buce did say:
See http://mailman.archlinux.org/pipermail/arch-general/2011-April/019775.html and other posts in that thread.
Which left a trail of breadcrumbs to the wiki url: https://wiki.archlinux.org/index.php/Systemd#Why_does_systemd_not_support_th... Which in turn did say: => Recent kernels set the system time from the RTC directly on boot without => using 'hwclock', the kernel will always assume that the RTC is in UTC. This => means that if the RTC is in localtime, then the system time will first be => set up wrongly and then corrected shortly afterwards on every boot. This is => possibly the reason for certain weird bugs (time going backwards is rarely => a good thing). Lets see if I understand... With the "recent" kernels, The system is initialized using the RTC as a UTC reference. Then (at some point) it would notice the HARDWARECLOCK="localtime" line in the rc.conf. In response to which perform a math operation based on timezone data and then adjusts the system time accordingly... ??? Am I right in thinking that any automatic fsck operation performed during the boot {especially any such fscking of the root filesystem that is done while it is still mounted "read only"} actually happens before the time gets adjusted?? And that it is those fsck operations, rather than any manually commanded fsck operations performed at other times on unmounted filesystems, that are most likely to to be affected by those so called "certain weird bugs"? Since I have for a long time kept my RTC set to localtime, did not have NTP installed, and did have the time built into my tty login prompt. (I boot to console then decide after login if & when to run startx {granted 9 times out of 10 times it's my first user command}) And this initial time reference on tty1 has matched my local time, I'm thinking the time adjustment that compensates for the RTC having been in localtime must happen before the 1st login prompt is issued. Whereas If I put "ntpd -qg &" in rc.local there is sometimes enough time to type my username before the NTP based time adjustment can be seen to occur... IF I ran NTP as a daemon (simply by adding "ntpd" to the "DAEMONS=()" line in rc.conf?) instead of simply calling it from rc.local, would it sync the system time to the server before the first tty prompt was generated? And if deamonized, would ntpd's syncing to the time server operation replace the process of adjusting for the RTC being in local time, or would the time still be adjusted by whatever mechanism does it without NTP and then afterwards, would NTP adjust the system time again to more accurately sync it to the NTP server's time??? And whether run as a daemon or a rc.local process (as described in the NTP wiki) does the system time still get corrected for the RTC in local time if for some reason the NTP sever(s) can't be reached. And for that matter, perhaps more importantly, I always thought that hwclock was the mechanism that did the adjustment to/from localtime at startup and shutdown... If as http://www.archlinux.org/news/initscripts-update-1/ says: => The adjustment of the hwclock for drift is moved into a daemon that should => not be used in most scenarios as it can lead to subtle bugs (especially if => using dual-boot or ntp). Without hwclock, what process looks at the HARDWARECLOCK="localtime" setting and performs the adjustment to and from "RTC localtime"??? I thank you for your patience. -- | ? ? | | -=- -=- I'm NOT clueless... | <?> <?> But I just don't know. | ^ Joe (theWordy) Philbrook | --- J(tWdy)P | <jtwdyp@ttlc.net> | ? ?