On Thu, Jun 20, 2013 at 01:36:02PM +0400, Konstantin Khomoutov wrote: > > Why is UTC time bogus? > > Well, I am simply afraid of a possible knee-jerk reaction of an admin > who for whatever reason manages to hit the BIOS setup program and sees > martian time there, which they would likely attempt to "fix". > I mean, keeping the time, which BIOS thinks is local, as UTC is > certainly possible but it requires implementing a policy, so that > everyone managing such a machine should be trained to keep that in mind.
The training is simple: use NTP, on every single machine, always. If the time is off this means your network or NTP client is down. The RTC clock is needed only during boot-up. > Now imagine a heterogenous environment (as I do have at my $dayjob) > where there's lots of Windows machines and a number of Debian (and > other Linux-based) machines. I positively see no reason to introduce > distinctions between these boxes with regard to their BIOS time. > This is really an "implementation detail". > > IMO, putting a string "LOCAL" to the /etc/adjtime file is way less > hassle to carry out than implementing a policy and training admins. Except, there's a laundry list of possible breakage caused by RTC using the local time when DST changes are involved. > For a bedroom x86 machine, keeping its BIOS time as UTC is perfectly > acceptable as it usually has zero to one administrators. I'd say, it's only bedroom machines (and sometimes student labs) that dual boot Windows with other systems. On a server, you really don't want sudden failure, possibly with data loss, to happen if it's rebooted during one of those four hours a year[1]. Failures I've read about that did not involve a reboot at that time all had Windows involved somehow, so I hope during the remaining 8762 hours you should be safe. Still, off hours are when you tend to do maintenance, and you don't want a leisure upgrade to become an urgent search for backups. [1]. Usually, a particular problem applies to only one of those hours, but with different issues in mind all four are at risk. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130620113214.ga14...@angband.pl
