Last weekend's Daylight Savings fire drill is a good occasion to remember that the only right way to keep track of time in a computer is UTC. The core clock used to track important things should never be set to a local timezone and certainly not a daylight savings adjusted time.

The problem with local time is it's not consistent. Sometimes it runs backwards so that '2:31AM' occurs twice in one day. Sometimes it skips an hour; the time '2:31AM' simply does not exist for yesterday. If your database uses local timestamps in a transaction log it's going to be very confusing when things go backwards or skip around. And hourly estimate calculations are screwed up when some days have 23 hours, some have 25. I've even seen screensavers automatically activate at 2AM on a daylight savings time transaction because suddenly the computer had been idle an hour.

It's amazing how many computers get this wrong. Operating systems are mostly OK now; Unix has always gotten it right and I believe MacOS X and Windows XP/Vista all use an absolute time reference internally. But lots of software still uses local timestamps. Apache, for instance, logs its timestamps in local time. Don't do that.

For safety I set my server computers to the UTC time zone so even dumb apps still get an absolute time. A bit annoying to look at timestamps in California, but it works.

Amusing endnote: the OS/390 system Ken uses is shut down twice a year for the daylight savings transition. That's a problem of their local installation, not the OS.