27 Apr
2013
27 Apr
'13
1:37 a.m.
On 27/04/2013 08:51, Cory Smelosky wrote:
NTP doesn't help if your clock and all systems
stop though. ;)
That's happened to me a couple times...
On 27 Apr 2013, at 02:30, "Mouse" <mouse at rodents-montreal.org> wrote:
>>> [F]or me, (3) half the other clocks in the house _are_ computers,
>>> which _do_ get it right without manual intervention - and on which I
>>> can install new DST rules whenever I want.
These days I struggle to find something that needs a manual update. The
clock in my TV , PVR and bedside radio (not a Tivo) all seem to update
from the digital signals. The clock in the radio shack
is set to Zulu
time so that works fine (and it syncs from DCF77
http://en.wikipedia.org/wiki/DCF77) so the clock must know how to remove
the DST offset when its added. The Android Mobile which frequently gets
used as a SatNav updates automatically as well....
I think I Central Heating still needs a manual update, as does by wrist
watch , which I kind of wear as habit as I tend to check the time on the
Android Phone. I guess I should include my Accutron Tuning Fork watches
but the batteries in those only seem to last a couple of months so not a
real issue....
Heh. My problem is that a lot of the computers are
set up to
multi-boot, and *each* OS wants to be in charge of resetting the
battery clock, so you get another hour each time you switch OSes.
NTP is your
friend. Turn on ntpdate at boot, and start ntpd with -g
(or whatever the equivalents are for your OSes), and you should be
fine. Or just tell all of them that the hardware clock is to be kept
in UTC - of course, that assumes they're all non-broken enouigh to be
capable of being told that?. /~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B