One of my biggest pet peeves is the flagrant misuse of time abbreviations common to email and instant messaging communications these days. Most people can remember to "spring forward, fall back" but it's been a little too much to expect the same people to know whether it's currently Standard or Daylight Saving time. In any event, it's poor form to report that a meeting will take place at 10 AM EST (meaning Eastern Standard Time) when in fact it's Daylight Saving Time. This can result in chaos when invitees come from parts of the world (like Arizona) that don't celebrate Daylight Saving Time.
But thanks to the Energy Policy Act of 2005, there's a good chance this situation will improve. That's because, starting in 2007, most of us will be observing 28 more days of Daylight Saving Time, and this change, which starts on March 11, will require action by most of you to keep your network systems running smoothly. So not only does this bill claim to save a ton of energy, it also got me a fat tax credit for my Prius. And to complete the trifecta, it will serve as a stern reminder to email users that Daylight Saving Time is in the summer! What a bill! I may even shelve my plans for DST Awareness Ribbons.
(In addition to learning how the DST change will affect your clocks listening to NIST, you can read a little bit of ancient Babylonian and Greek history in this DST FAQ.
The devices in question include PCs, servers and network infrastructure equipment like routers and switches. We'll focus on the latter.
The typical effects you'll see from failure to reconfigure these devices will be similar to normal issues you see when a device's clock is out of sync. For some systems, such as network management systems, the result will be reports that are off by one hour. This could cause grief for your security event logs as well. Authentication systems that rely on times are particularly troublesome. IPsec VPN encryption protocols are notorious for preventing connectivity when peers' clocks are off by more than a few minutes.
You'll need to consult the manufacturer of your network equipment for specific details about how their systems handle time changes. For a sample, this is the configuration change required for Cisco devices:
You've probably already enabled DST support on your Cisco devices by use of the "summertime" command. This command is used to set the name of the time zone you're in, like CDT for Central Daylight Saving Time. Unbeknownst to most people, there are many other arguments to this command, but the defaults include the time and date that Daylight Saving used to start and stop, which was the first Sunday in April to the last Sunday in October. Now, you have to specify the dates instead of using these defaults.
So, for example, if you're on the Pacific coast, and you have devices using IOS, you used to use the clock summer-time PDT command, and now you'll need something like this:
clock summer-time PDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
And for a CatOS device, you had set summertime enable PDT, and now you'll need to add an extra command like this:
set summertime recurring second Sunday March 02:00 first Sunday November 02:00 60
But most importantly, you should use these summertime commands to help you remember that Daylight Saving Time is in the summer!
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
This was first published in March 2007