synchronize time

[Tim]

On Mon, 2012-03-05 at 09:36 -0600, Aaron Konstam wrote:
> It is not hard and that is what I have been saying from the beginning.

It's the opposite of what you've been saying, repeatedly.  Geez.

You kept saying CUPS wouldn't work if UTC was set.  That's wrong.
You said that you'd set the clock correctly, that was wrong.

For your benefit, and anyone else following the thread, ignoring the
hole you're digging and just discussing clocks and timekeeping...

The hardware clock is the one that actually runs on the motherboard,
whether the computer is running or not (the BIOS battery also powers the
clock).  Gnome, and probably others, also call it the system clock.
It's this clock that the UTC flag refers to.

The software clock is the one that that Linux is running when the OS is
running.  It's what you see whenever you see the time on the desktop.
Generally, you set your timezone so that it shows local time.  But, if
you travel, for instance, you can change the timezone at will.  That'll
change the display of time, without actually changing the clock (the
displayed time always been an offset from the clock, the offset being
set by your choice of timezone).

The software clock is set going using the time from the hardware clock
when you boot.  And the hardware clock is tweaked to match the software
clock when you shutdown.  NTP, or other time-keeping software, generally
just keeps the software clock running on time.  Letting your OS update
the hardware clock, to match, on shutdown.  Though, NTP (or similar)
could update both when they adjust the clock to be correct.

You can run the hardware clock on local or UTC.  

The advantage of UTC, is that it's a consistent time, unmangled by
daylight savings, and constant if you move across timezones.  The
displayed time is changed, not the clock.

But if you dual-boot with an OS that doesn't understand UTC, you can run
the clock on localtime.  The hardware clock will get changed as daylight
savings starts and ends, which can cause some problems.  Even more so if
Linux correctly sets the time at the changeover, then Windows dumbly
moves the time by an hour, just because of the date, without actually
checking what time the clock was set to against a timeserver.  More fun
ensues if you reboot several times on that date, and Windows insists on
doing it more than once (yes, I have seen that happen, it's stupid, and
not supposed to happen, but can).

A hardware clock running on localtime will also change time if you
change timezones and you reset the time to suit the new localtime (your
change will change the hardware and software clocks).  This can also
cause a few nuisance problems if you do change the clock/timezone a few
times (e.g. users travelling cross-country).  You can find that files
get confusing dates (in the future, or simply not at the time you recall
making them - which can be a problem for any software that uses dates in
organising data).

To get sane time on your computer, you need to do three things:

      * Set the UTC flag appropriately to match whether the hardware
        clock is running on UTC or localtime.
      * Set the timezone to match where you actually are.
      * Set the time correctly.

Letting your computer run an NTP, or other time keeping program, keeps
the time running correctly with no further manual tweaking needed by
you, so long as you did the prior three things correctly, and so long as
there's nothing wrong with your hardware (such as the battery that the
hardware clock depends on being okay).  If the time keeps going wrong,
software aborts/crashes/errors, then you need to check what's wrong.

-- 
[tim at localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.