The curse of daylight savings time

Daylight saving is a nightmare for software companies in the south eastern Australian states. The reason for this is that the state governments have been modifying the start and end dates of daylight saving for the last few years. This all started in 2000 for the Sydney Olympics.

This year the end of daylight saving has been moved back a week. I saw in the paper that some people had glitches with alarms on mobile phones waking them up an hour later.

We had an issue reported, where one of our customers could not see some of their field worker jobs on their scheduling screens. The support desk has been looking at it and confirmed there was an issue and were escalating it to engineering.

I asked the normal questions :

• has anything changed - This was the first time this issue had been reported and this customer's system has been running for about six months. No nothing had been changed today.
• Have you checked the log files - they were still looking at it - it always amazes me how long it takes people to check the log files.

I checked the log files and there was no indication to the cause of the issue, although something had gone wrong at 11:30AM where the customer's browsers were reporting an issue with the data. The error reported was a pretty vague JavaScript error.

Could we replicate? I got the identifier for job that was not appearing on the scheduling screen and ran up a scheduling screen on Firefox and the job was there. However the customer runs IE7. When I accessed the screen in IE7 the page failed to load. I got one of the other engineers to load the same screen on a machine with a debugger attached and we found part of the puzzle - the job had a negative duration because the start time for the job was later than the end time. The duration controls the width of the box used to display the job on the screen so a negative duration was not good. We set the start time for the job when the field worker starts the job and the end time when they complete the job. Why would they fiddle with the clock on their tablet during a job - they shouldn't change the time at all. Then it clicked daylight savings - the support desk rang the technician and confirmed that he had changed the tablet clock during the job. The clock on his tablet was wrong because something thought daylight savings had already ended.

We updated the database entries for the job so that it now had a positive duration - Issue resolved.

The problem reoccurred 1/2 hour later when another fieldworker did exactly the same thing. Applied the same fix - Issue resolved again.

We will see what happens next year.