* UTC can get out of whack with the rotation of the earth around the
sun, because our rotation is not uniform, but is calculated rather
than measured (well, sort of)
As Crist Clark points out, leap seconds are about the Earth's
rotation about its own axis, not its revolution (orbit) around the
sun. Atomic clocks are much more consistent and uniform than the
Earth's rotation. If we don't correct for the differences somehow,
eventually wall clock time would get out of sync with the day/night
cycle. In $LARGE_NUMBER years, 1:00 PM would be in the middle of the
night.
Earth's orbit and the Julian calendar have the same problem, which
is why we have leap days. Otherwise, the calendar would get out of
sync with the seasons.
* When writing code regarding dates and times, know that any year may
have 366 days, and any minute may have 61 seconds.
I wouldn't even define it that narrowly. We might end up with 62 or
63 or 57 seconds in a minute, or 364 or 367 days in a year.
Internally, store everything using a fixed-unit offset (e.g.,
traditional Unix time, i.e., seconds from 1 Jan 1970). Use OS
provided facilities to translate to and from human-friendly
representations, and thus make it the OS's problem. (If the OS is
your problem... sucks to be you. You'll need lots of tables of
historic, idiosyncratic clock/calendar changes to get it right.)
For program timers (timeouts, etc.), don't use wall clock time at
all, since the wall clock may be wrong, and the admin may fix it,
yielding time travel. Most OSes provide something like a "seconds
since boot" value, which should always monotonically increase (unless
you're running Windows 95, heh), regardless of what the admin is doing
to confuse matters.
From the other side of the coin: As an admin, avoid advancing the
wall clock in large steps, or going backwards at all. If you must do
either, do it in single-user mode, or whatever your platform's
equivalent is. Don't assume the programmers got it right.
Another programmer tip: When storing dates and times in a file,
database, etc., and you have to care about multiple timezones: Store
at least three of UTC, local time, calculated difference, logical
local timezone. The extra information lets one figure out
after-the-fact what the timezone tables on the system said when the
user entered the information. When the gov'mint monkeys with the time
zones, there's always a lag between official announcement and local
implementation. Without knowing what the time zone tables said, it
can be hard to know if you should apply a correction later.
-- Ben
