Classic WTF: Long Distance DATE$ing

The Fourth of July was this weekend, and this is the perfect time for us to have our little Summer Vacation. For this week, sit back, enjoy some nice weather along with some Classic WTFs (nice weather not guaranteed, definitions of "nice" may vary from user to user).

This story originally ran in 2006, and is one of those examples where we let the submitter speak for themselves. - Remy

Mot did a pretty good job in telling this tale of Long Distance DATE$ing, so I'll just turn it on over to him ...

VBA (not VB) is Visual Basic for Applicaitons, embedded into other apps. A fine, extensible subset and superset of VB commands. Works pretty well if you stay within its bounds.

VBA has a DATE$ command, used to set the workstation date. Why you would want to reset the workstation's date is left to your imagination, but the command is documented in the help.

All was well until a HPC (Highly Paid Consultant) came in and used DATE$ to (try to) store a date string, then parsed it (using US date format) and printed it on a form. The thing is, it worked okay because of the way the data and commands he was using defaulted to 'today' - he was trying to store 'today', and print 'today', and it seemed to work fine. No one knew, but because of the command 'DATE$ = (system date with US formatting) it also kept resetting the system date on the PC to 'today', format MM/DD/YYYY.

So then the app was rolled out to Europe. They use date format DD/MM/YYYY. The first time someone printed a form, if it was during the first 12 days of the month, it would reset their PC's date to by reversing months and days. The second time it would print a form, it would set the date back correctly. So, some people had their PC's time messed up until reboot (or manual date change), some did not. The forms all looked okay (the date format was hardcoded to US format on the forms, but the users were used to things like that coming from the US)

On the 13th and later, it would not mess up, because it would silently swallow the 'invalid date' error. If you printed an even number forms, it would set your date back to 'today' in DD/MM/YYYY format. If you use a US machine to test it, it will work fine, because you have to have a machine set up for a Europe location to make the error appear.

It took over three years to finally find and squash this bug. At first, no one believed the users, especially when they could not repeat the problem very often. Then when people finally believed there was a problem, no one could find the bug, which was hidden under five nested gosubs to other scripts, uncommented, and something that the eye would just pass over as 'just another string assignment'.

After I found the $DATE command in the help, I was then pretty sure I knew what the problem was. It took me two hours to pinpoint the problem. So, three years and two hours later, Europe could stop counting forms before printing, and always printing an even number of them per workstation (or failing that, rebooting after printing, which set the PC time to network time).

[Advertisement] Manage IT infrastructure as code across all environments with Puppet. Puppet Enterprise now offers more control and insight, with role-based access control, activity logging and all-new Puppet Apps. Start your free trial today!