Re: OK so HARDWARECLOCK="localtime" is "strongly discouraged" BUT???

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




It would appear that on Jul 11, jesse jaara did say:

> 
> Check the systemd wiki page it has info for setting windows to UTC time
> 
 
 It's not so much that Windows likes local time. It's that I insist on
 it... I MUCH prefer to manually set/verify the hardware clock's time
 with the bios set-up screen prior to loading an OS and I have no intention
 of having to mentally convert to/from UTC to see if it's correct. 

It would appear that on Jul 11, Thomas Bächler did say:

> 
> Am 11.07.2011 17:20, schrieb Joe(theWordy)Philbrook:
> > 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. 
> 
> 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>
 
> > 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...

> - Complicates travelling and changing time zones.
> - Whatever, think of anything involving your system clock, and using
> localtime will make it harder.
> 

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>.

OK OK I acknowledge that I'm stubborn... But I just realized: there may be a
flaw in my plan to use "ntpd -qg &": You say the potential fsck bug would
be "due to time changing during bootup." Tell me that letting it get all
the way to the login prompt And then letting "ntpd -qg &" correct the time
difference between NewYork and UTC isn't likely to mess with fsck...

I'm thinking that an automatically run fsck based on the mount count and/or
an unclean shutdown would be done before rc.local gets to run. And I'd
have to type really fast to login and start a manually called fsck for
"ntpd -qg &" not to be done messing with the system time before fsck
started. But I don't know for sure.

Thanks

-- 
|   ~^~   ~^~
|   <*>   <*>       Joe (theWordy) Philbrook
|       ^                J(tWdy)P
|     \___/         <<jtwdyp@xxxxxxxx>>

[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux