Double check your system clocks for daylight-saving time

It is daylight-saving time again. Do we need to worry about unpatched systems not tracking the correct time this time around?

This is the second year since the dates for changing the clocks was changed in the United States, so you would expect everything to be caught up and working correctly. Here in Arizona and in other parts of the country that do not observe daylight-saving time, it is still a good idea to double-check your system clocks. We still run into machines that insist they are on Mountain Standard/Daylight Time rather than Arizona Time. Symptoms of improperly synchronized system clocks include invalid log entry time-stamps, failed VPN logins, unreachable encrypted Web pages and other seemingly bizarre system anomalies. Public/private key establishment handshakes and Kerberos logins can be especially sensitive to time-stamp discrepancies. Modifying system configuration settings so that system time is obtained using the Network Time Protocol and a reliable time server can minimize the effort required to make sure all your servers and desktops are making the time transition (or not) for daylight-saving time changes as they should. This way, you would only need to check that the time server is distributing the correct time, rather than manually checking each system’s clock setting.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

It is daylight-saving time again. Do we need to worry about unpatched systems not tracking the correct time this time around?

This is the second year since the dates for changing the clocks was changed in the United States, so you would expect everything to be caught up and working correctly. Here in Arizona and in other parts of the country that do not observe daylight-saving time, it is still a good idea to double-check your system clocks. We still run into machines that insist they are on Mountain Standard/Daylight Time rather than Arizona Time. Symptoms of improperly synchronized system clocks include invalid log entry time-stamps, failed VPN logins, unreachable encrypted Web pages and other seemingly bizarre system anomalies. Public/private key establishment handshakes and Kerberos logins can be especially sensitive to time-stamp discrepancies. Modifying system configuration settings so that system time is obtained using the Network Time Protocol and a reliable time server can minimize the effort required to make sure all your servers and desktops are making the time transition (or not) for daylight-saving time changes as they should. This way, you would only need to check that the time server is distributing the correct time, rather than manually checking each system’s clock setting.

Read more about infrastructure management in Network World's Infrastructure Management section.