On August 8, 2005, President George W. Bush signed the Energy Policy Act of 2005. This Act changed the time change dates for Daylight Saving Time in the U.S. Beginning in 2007, DST will begin on the second Sunday of March and end the first Sunday of November.
For 2007 and beyond, the daylight saving time period will be: 2 a.m. on the second Sunday in March to 2 a.m. on the first Sunday in November
Impact to Networking Systems
Having correct time management is a very big concern for most organizations. This is especially true of systems that require accurate time and time stamping for proper operations.
For networking systems, the clock or clock source is usually from a trusted chronological source ? such as a private or public Atomic clock. The control of Daylight Savings Time and time offsets are usually configured by different organizations to suit location and different time tracking purposes.
Interaction with Network Time Protocol (NTP)
Network Time Protocol (NTP) is used to synchronized the time of various network ?elements? to a specified server or reference time source. These reference time sources utilize very accurate instruments, usually in the form of an atomic clock. The standard timescale used (by most nations) is he Coordinated Universal Time (UTC) ? which as a standard uses several factors such as the Earth?s rotation around it?s axis, the Gregorian calendar etc. The UTC timescale is disciplined with respect to the international Atomic Time (TAI) and is disseminated through various means, including GPS (Global Positioning Systems, radio and satellite.
Typical network deployments of NTP are conducted via the following sequence:
Impact to Cisco IOS/CATOS
Cisco IOS and CATOS are designed to provide proper Daylight Saving Time (DST) functionality for all time zones worldwide. The summertime command is used in conjunction with accurate clocks (access via the Network Time Protocol ? NTP) to provide accurate year round time stamping with proper time offsets for DST.
The impact of these changes in DST is that the default values, which have been set for US Standards, will be incorrect until the default values are changed in later versions of code.
It is recommended that the summertime command setting be entered for all devices to the proper date, time and offset values.
Details of the summertime command are outlined in this document.
Cisco IOS Summertime Command
To configure Daylight Saving Time (DST) on Cisco devices running IOS software, the set clock summertime command is used.
To configure the system to automatically switch to summer time (daylight saving time), use one of the formats of the clock summer-time command in global configuration mode. To configure the Cisco IOS software not to automatically switch to summer time, use the no form of this command.
clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
clock summer-time zone date date month year hh:mm date month year hh:mm [offset]
clock summer-time zone date month date year hh:mm month date year hh:mm [offset]
no clock summer-time
Name of the time zone (for example, "PDT" for Pacific Daylight Time) to be displayed when summer time is in effect. The length of the zone argument is limited to 7 characters.
Indicates that summer time should start and end on the corresponding specified days every year.
Indicates that summer time should start on the first specific date listed in the command and end on the second specific date in the command.
(Optional) Week of the month (1 to 5 or last).
(Optional) Day of the week (Sunday, Monday, and so on).
Date of the month (1 to 31).
(Optional) Month (January, February, and so on).
Year (1993 to 2035).
(Optional) Time (military format) in hours and minutes.
(Optional) Number of minutes to add during summer time (default is 60).
Summer time is disabled. If the clock summer-time zone recurring command is specified without parameters, the summer time rules default to United States rules. Default of the offset argument is 60.
This command was introduced.
Use this command if you want to automatically switch to summer time (for display purposes only). Use the recurring form of the command if the local summer time rules are of this form. Use the date keyword to specify a start and end date for summer time if you cannot use the recurring keyword.
In both the date and recurring forms of the command, the first part of the command specifies when summer time begins, and the second part specifies when it ends. All times are relative to the local time zone. The start time is relative to standard time. The end time is relative to summer time. If the starting month is chronologically after the ending month, the system assumes that you are in the southern hemisphere.
The following example specifies that summer time starts on the first Sunday in April at 2 a.m. and ends on the last Sunday in October at 2 a.m.:
Router(config)# clock summer-time PDT recurring 1 Sunday April 2:00 last Sunday October 2:00
If you live in a place where summer time does not follow the pattern in the first example, you can specify the exact date and times. In the following example, daylight saving time (summer time) is configured to start on October 12, 1997 at 2 a.m., and end on April 26, 1998 at 2 a.m.:
Router(config)# clock summer-time date 12 October 1997 2:00 26 April 1998 2:00
The actual IOS configuration modification required is as follows:
router (Config)# clock summer-time extended_DST recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
I hope this helps and please feel free to contact me anytime.
This information has helped me as well, what is the equivalent command for CATos? I am in the eastern standard time zone. so can you give me the complete commands for both the IOS and CATOS (version 7.6(16).
If you are saying that cisco recommends that we add the summertime command to all of our equipment, does that mean that the NTP function does not work correctly? My reason is that if I am pulling a time from an accurate source, it is totally independent of what my device thinks. It should set the time to what ever it is. That is one the reason why I am using NTP. Please help an old mind understand. Thanks..
NTP is an excellent source of accurate time. I believe that it is a best practice for network devices to learn their time via NTP.
But one thing to recognize about NTP is that it communicates in UTC. If you are happy to have your routers and switches process and report in UTC then do not configure or use the local timezone or summertimes functions. But if you want your routers and switches to report time according to your location then you need to configure the offset from UTC for your timezone. And if you are in a location that does obsesrve daylight savings time then you should configure the summertime command.
So we are not saying that NTP does not work correctly. But the correct operation of NTP has no concept of different timezones or of daylight savings time. If you want to accomodate these functions of time zone and daylight savings time then you must configure them.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...