Re: Setting The System Clock [Linux]

From: John Winters (newstmp_at_sinodun.org.uk)
Date: 10/31/03 

Date: Fri, 31 Oct 2003 20:00:24 +0000 (UTC)

In article <3FA2A5D8.E226031A@sympatico.ca>,
John-Paul Stewart <jpstewart@sympatico.ca> wrote:
>John Winters wrote:
[snip]
>> Precisely - this is the problem. The only reason to have your hardware
>> clock set to local time is to cope with Windows's broken time handling.
>
>Or personal preference.

Well, yersss. This is on a par with saying that a good reason for
keeping your computer in a bucket of water is "personal preference".
It doesn't work well but I do it anyway for personal preference.

>I don't have Windows on any of my machines but
>I keep the hardware clock set to local time for a variety of reasons,
>all of which boil down to "that's the way *I* like it".

Clearly, that's what they'd all have to boil down to. There is no
rational reason to do such a silly thing.

>I know I'm not the only person who does things this way.

Possibly not - it's still a damn fool thing to do, for one very simple
reason. It doesn't work properly and it can never work properly. It
has only downsides and no upside.

>It would be nice to see time changes handled more gracefully in these
>circumstances.

You'll have to code them yourself. No-one else is going to go to any
trouble to cope with such silly behaviour. Bear in mind before you start
that it is utterly impossible to produce a reliable implementation based
on your flawed approach. Yet, if you do it the right way (system clock
and hardware clock on UTC/GMT) then a totally reliable solution is
easy. (This is what *makes* it the right way.)

There is an additional drawback (from your point of view) to your approach
which you may not be aware of. Even if you choose to keep your hardware
clock set to local time, the system clock will still be set to GMT/UTC.
If you want to break that too, then you'll have even more coding to do.

>But they only happen twice per year and take just a
>couple of seconds to fix. It'd be *decades* before I personally could
>recoup the time spent trying to implement a more elegant solution to the
>problem. So it's not worth the effort to me personally to attack the
>problem. If that's the price I pay for keeping hardware clocks in local
>time, then fine.

But why pay any price at all? It has a price; it has absolutely no
benefits - simple answer - don't do it.

HTH
John 

-- 
The Linux Emporium - the source for Linux in the UK
See http://www.linuxemporium.co.uk/
We had a woodhenge here once but it rotted.

Relevant Pages

  • Re: Time Setting...
    ... have you tried putting the hardware clock onto UTC as ... >I am wondering, if the hardware clock is set to the local time, ... That is another way of phrasing the suggestion to tell Linux that your ...
    (alt.os.linux)
  • Re: NTP Configuration for DST?
    ... OpenVMS systems usually have the system clock set to local ... The time NTPD comes up with is converted to local time (using ... We do this using zone and DST information already present in our ...
    (comp.protocols.time.ntp)
  • Re: System time 1 hr ahead of real time
    ... I have my hardware clock set to the local time. ... or get the time from a time server ...
    (Fedora)
  • Re: hware clock left bad after a system failure
    ... >> really have disk or driver problems at all. ... when in fact I run a local time ... but if the system is set to run its hardware clock on grenwich ... I *think* the problem is that the assumption of grenwich time is only ...
    (Linux-Kernel)
  • Re: Best practice for TOD clock
    ... > I'm engaged in an internal dispute about best practice for the TOD clock: ... > The argument for local time I guess is that it's more simple and convenient ... > Can anyone venture a concise statement on why it is best practice to do it ... > are in two different local time zones, would setting the hardware clock on ...
    (bit.listserv.ibm-main)
Loading