DevDisasters

Trans-Atlantic Time Trap

• By Alex Papadimoulis
• 11/01/2009

Nobody believed the French. Not the entire country, or Frenchmen in general, but rather the folks who worked at the European Branch Office in Paris. The bug they described-their computer's internal date was randomly changing-reeked of user error and seemed far too implausible to be caused by the corporate reporting system.

But the French employees relentlessly called app support whenever their clock would mysteriously change. It was always a predictable dialog.

"Ca me fait chier," Pierre would grumble. "The date! It just changed again!"

Moe T. was often the support developer on the other line.

"Did you try changing it back, Pierre?" he would ask. "You could also reboot."

Random Bug
Moe simply could not reproduce the problem. It only seemed to happen at random, and only a few times a month. That is, until two years later, when Pierre noticed a pattern.

"If we print the GL-DLG-ADM report on the fifth day of the month," he explained in an e-mail, "it will 'swap' the day and the month on our computer. So, if my computer says it's Oct. 5, then the report will change my computer date to May 10. But, this only will happen if the report is one page long."

It sounded like a superstitious diagnosis to an even stranger problem, and none of the developers believed it. No matter how many times they ran a one-page GL-DLG-ADM on their machines, their computer date remained the same.

But Pierre was insistent and demanded that Moe log in to his machine to watch the problem firsthand. Sure enough, running GL-DLG-ADM did, in fact, change Pierre's system date. The month number became the day number and the day number became the month number.

With no apparent root cause, Moe offered up a simple workaround: run single-page reports twice and, if that fails, reboot the computer. Pierre wasn't thrilled, but was content that a non-French employee had finally witnessed the problem.

Back to Basic
Moe went back and dug through the code, but couldn't find a thing. He looked at the report itself, the report generator, the report printer and the report runner ... and still, nothing. With other things taking precedence, and a workaround in place, the date issue fell onto the backburner.

That is, until a year later, when Moe just happened to flip through some VBA documentation and noticed this:

Date: returns the current system date
Note: assigning a value to Date will change the current system date to the value

He did a double take.

"Wait a sec," he said to himself. "VBA lets you set the system date by setting a value to the function?" His mind immediately jumped to the bizarre French date bug. The report used VBA Macros and must have somehow been assigning a value to Date.

After another hour of digging through sub-routine after sub-routine and script after script, he finally found the offending code buried in the page header macro:

' format the date
Date = month & "/" & day & _ 
       "/" & year

On most computers, including the developers', the code simply set the system date to the current month, day and year. On the French computers-where dates use the DD/MM/YYYY format-the code swapped the months and the days. And then, on the second page, it swapped them back. After the twelfth day of the month, when most reports were run, the line silently failed.

It took just a few minutes to fix. And after three years, the French employees could finally stop counting forms before printing, and always making sure to print an even number of pages per workstation-or failing that, rebooting after printing, which set the PC time to network time.