On Mon, Jan 5, 2009 at 4:19 PM, Peter Beckman <beckman@angryox.com> wrote:
* 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