Daylight Saving Time Strikes Again! Well, almost.

This post is very old and likely contains information that is no longer accurate and links which no longer work. Proceed with caution.

We lucky folks in Indiana have had a rough two years dealing with time. As I wrote about last year, Indiana just started observing Daylight Saving Time (DST) in 2006. Now, for 2007 we also have to change the dates on which DST starts and ends. DST now begins on the second Sunday in March, and ends on the first Sunday in November – This year it’s March 11th and Nov 4th. Why on earth we didn’t just wait to start along with the new rules is anyone’s guess.

I don’t think we should be using DST at all, but that’s a rant for another time

Here I was, all set for another round of server updates, reboots, etc. Turns out that I didn’t need to worry quite so much. When I updated all of the time zone files on our servers last year for Indiana’s initial DST switch, they had already made the changes with the new start and end dates for 2007 and beyond. You can confirm this on most UNIX systems as follows:

# zdump -v /etc/localtime | grep 2007
/etc/localtime  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST isdst=0 gmtoff=-18000

If it says Mar 11 and Nov 4 you’re good. If it says Apr 1 and Oct 28 you need to update your time zone definitions. On FreeBSD, this can be as simple as downloading new zoneinfo files, recompiling them, and re-selecting the time zone:

• Download the time zone data files
• Exctact the contents to /usr/src/share/zoneinfo
• cd /usr/src/share/zoneinfo; make install
• tzsetup
• Choose the time zone again

A reboot may be necessary to ensure that all running programs are on the same time zone. Running programs may not pick up the change. You could also update FreeBSD to a recent version, which includes these changes. If you choose to do the OS update, be sure to run tzsetup afterward to be absolutely certain that a new tz file gets installed to /etc/localtime. After you’re done, re-run the zdump command above to be check that you now have the proper DST change dates for 2007.

If you are running any Cisco gear (or other IOS-alike devices) this should work to make the change:

clock timezone EST -5
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

Adjust the time zone to yours, of course.

There may be other programs that handle time zone data internally (such as Java and Outlook) so you’ll have to be sure there are no loose ends in that department. Those of us in Indiana have some practice with this, so at least for us it may not be that bad.

I am aware that many of these problems could be avoided by using UTC on all our server clocks. While that may be preferable, we like to have everything in local time. It’s a choice, and we deal with the consequences. One of which is we never schedule jobs to run overnight between 1-3am – they could be run twice or not at all.

UPDATE: 3/1/07:

I have also been informed that you can copy the /etc/localtime file from an updated system to any other system that needs it. This could be especially useful if you are unable to update all of the Time Zone definitions for any particular reason.