Imperfect fixes for daylight-saving time problems

After the Y2K scare, you’d think that the computer industry could handle without much difficulty a little thing like a change in daylight-saving time from the traditional second week in April to the second week in March. And for the most part, the industry did seem to handle it, with only some hiccups reported here and there.

But that analysis doesn’t entirely jibe with the view of the guys in the trenches. One of those guys is Chris Poe, technology director for Atrion Networking Corp., a system integrator in Warwick. Providence Business News recently spoke with Poe about what the DST change looked like from inside the problem.

PBN: Some software and hardware makers released daylight-saving time patches that caused as many problems as they solved. Why did that happen?
POE: It’s important that when you make a change in the timing on a system you are mindful of how that timing affects other systems. For example, if I were to apply patches for daylight-saving time to my Exchange Server and I don’t do it to my PCs, which take information from my Exchange Server, there will be a synchronization problem between the two. A lot of vendors … were not educating customers as to how other systems interact with the system they were patching or updating.

PBN: These vendors had years to address this problem. They couldn’t create decent patches in that time frame?
POE: It was crazy. We didn’t start to hear from vendors until six to eight weeks before the impending date. One vendor would send e-mail blasts out to the community saying, we are working on the DST issue, we will be posting documents to the Web, and they will be changing continuously. That same vendor right up to and through the DST date was still making updates and changes to their approach.

- Advertisement -

PBN: What were some of the problems caused by these patches?
POE: Calendars and conference schedules on the PCs of users were off by an hour. Companies were patching their conferencing systems, but the partners they invited to conferences didn’t make the corresponding adjustments. So I set up a conference for 10 o’clock and all my partners would show up at 9.

PBN: What did you do to avoid the pitfalls poised by these patches?
POE: We took a proactive approach to it. We looked at all the technologies that we support for our clients. We looked at each patch and asked, if we were to apply the patch in isolation, how will it affect other systems with which the patched system operates? We asked, if we don’t patch at all, will there be any impact whatsoever? Some systems may have clocks on them, but they don’t use them for anything functional.
And we created a Concern Index to make it easy for our customers to determine what things they need and need not be worried about. Items were rated as “no concern”; “low concern,” in which not patching a system might cause some administrative inconvenience; “moderate concern,” where some end-user inconvenience might occur; and then there were concerns which required attention because business processes would be impacted if they weren’t attended to.
We considered the majority of upgrades and patches that came out to be published in a hasty manner. Our approach was to be conservative and not apply patches and upgrades unless there was a compelling reason to do so. We just don’t take the latest and greatest and install it on any system for fear that because it is the latest and greatest, it’s probably not thoroughly tested. We would rather see something prove its stability over a period of time before we endorse it for clients. So most of the time we chose workarounds to address concerns and made manual adjustments for DST.

PBN: Did the process work?
POE: Yes, the process proved itself. On Monday morning, no one knew what was really going to happen. … In some ways, this might have even been scarier, because we have so many systems that interoperate in so many different ways. We were prepared for the worst. But lo and behold, we didn’t receive one single DST support call. We know of vendors and other competitors that were not so fortunate. I know one vendor who had to stop taking calls at its help center because there was so much activity after DST from customers who thought about it too late or applied patches and updates but didn’t do it universally across all their systems, so they had inconsistencies between them.

PBN: Are we going to have to go through this again in November, when it’s time to turn the clocks back?
POE: No, we don’t have to do it again in November. Between now and November, the natural cycle of software and hardware upgrades will include the DST adjustments in them.

No posts to display