With less than a week for the US day light savings to end, thought why not share an incident related to this when I was a Technical Support Engineer.

The 'Day Light Saving'  dates back to 1967 and  was regularized across the states in the US, barring a couple of states. I am not going to deal with this history for sure, but, a decade ago, it played a kind of spoilsport to the twin celebrations in the office.

After a good stint as a sysadmin, technical support was a relatively newer role for me. Almost a beginner, a ll was well when the day dawned.  I had no clue when a customer called the Support Desk to tell that all alarms from  OpManager  console were generated an hour behind its schedule in March, while the system time was reportedly correct.  Since this problem required a deeper analysis,  I had to convince the customer hard to oblige for a remote session. [We now use Zoho Meeting, which is more flexible than what it used to be with  Webex ]. Having told that I was a beginner, no prizes for guessing what my first troubleshooting step would have been. Yes, restart the service, which did not do the trick. Instead this made the customer irate as he had restarted the service thrice already!

Now, I had to deal with two things at the same time - an irate customer and the problem at hand - alarms were reported an hour behind the system time. I was sure that if the issue was fixed, the customer would definitely calm down. The first thing I did was to apologize for the mistake  and then buy time to further troubleshoot the problem.

Had no clue as to where I should start analyzing the problem. That was when the Y2K problem came as a bright lightning flash. A little bit of  googling  helped me find that this could be a Java bug and that this problem was not specific to  OpManager  alone. I then contacted the Product Technical Architect  who was quick to confirm that this was surely a Java bug and that a fix should be applied to the  JRE  bundled along with the product. All this was happening at midnight and my phone was buzzing with wishes from family and friends, while the contract workers were busy working to help us decorate the office bay to  commemorate   OpManager's  first year release. The developer who was assisting me all through the night had more visibility into the problem by then and he quickly gave me a fix for the  JRE  bundled with the product. It was the  TZUpdater  JAR file, which had to be placed within the  JRE  folder in the  OpManager  installation directory. This was done as per the developer's instructions. Voila!!! I was right back on  track and the problem was fixed after 6 hours of troubleshooting. Since then, this known-error has had the highest hits in our knowledge base portal.

It was 4:00am on the day of my birthday and I had to hit the bed without any further delay so as to join the celebrations at office. At 9:00am, the office was glittering like Christmas Eve and to my biggest surprise, I had my first appreciation from the customer and what else can you ask for on a birthday with wishes and appreciations pouring in from all quarters.

By the way, the latest  TZUpdater  is available for download from java.sun.com