An interesting bug.

One of our programs has a 90-day limit on passwords, and for passwords set on October 2, that limit would be reached on December 31. For some reason, passwords switched on this day were getting marked as expiring in 12-31-09, which violated the 90-day limit, and blew up the user’s account. This caused something of a panic amongst the sysAdmins.

I had a hunch, as I am paid to do after working 2 years on a program, and correctly determined the cause related to our 90-day rule and the new year, and the fact that the bug was effectively only a bug on this one day. Some further digging by one of our developers revealed the bug to be due to the usage of Gregorian time rather than “regular time”. The perl documentation describes the differences like:

%G – The ISO 8601 year with century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %y, except that if the ISO week number belongs to the previous or next year, that year is used instead. (TZ).
%Y – The year as a decimal number including the century.

I never understood why a program would support different algorithms for calculating time. then again, I majored in philosophy and not computer science. You would think if anyone could find uses for different versions of time, it would be a philosophy major and not someone trained to think in 0s and 1s, but i digress… Much discussion, relaying and allaying of concerns and messages ad nausea up and down the food chain ensued, ending in a decision to change the constant we use for time management in this program. Its no small thing when you alter time.

The pressure was on QA to make sure this change was safe. After 10 years and an inflated title, i took this in stride, and showed why its worth having me instead of two junior engineers. Rather than use a shotgun and splatter an entire work-week across my monitor like a Robert Rodriguez film, testing the entire program and numerous date combinations, I searched the codebase and found this change affected 14 different features. At a unit level, the time calculation would be the same for every one of them, meaning I only had to test the specific piece of code once. It worked as planned on new years, which I was able to test by hacking the code base to check for a 68-day-old password. Next was to determine the risk in the event my testing was wrong. I found two uses of the time constant to be for a different program using the same library code and now the happy recipient of a free enhancement request, three occurrences that were informational only and would have no impact if wrong, eight that were straight expiration dates which at worst would be simple edits, and the one bug due to the application of the 90-day business rule which i provided steps to work around.

The analysis of the fix and risk took about an hour and a half for me, it took about 10 hours at least of various other people’s time, more if you included all the email. The code change was 1 character.

Before: STRFTIME_NLS_DATE_TO_CHAR_FMT => ‘%G:%m:%d:%H:%M:%S’;

After: STRFTIME_NLS_DATE_TO_CHAR_FMT => ‘%Y:%m:%d:%H:%M:%S’;