One of the sneakiest, hardest to explain bugs. The process works fine any day you test it, but occasionally - and only occasionally it's just... wrong. Test it again and it's fine, no matter what day you test it.
This particular issue stems from a habit of grabbing a datetime whenever you need it, but coding as if you were getting the same value each time. It's an easy to explain issue, but there's not a term for it (as far as I can tell), so, I coined one: Date Shear.
What is Date Shear?
Date Shear (noun): Insidiously difficult to reproduce bugs that occur due to code fetching the "current time" multiple times, while the logic expects the same value. The result can be catastrophically incorrect behavior if the code is executed across a day, month or year boundary.
A Common Example
Imagine building a Quarterly report based on the current day:
- Just before midnight, a GetDate() or similar method gets the current datetime, and uses that to determine the start date for the "current" quarter.
- (Clock ticks midnight)
- Just after midnight, a GetDate() or similar method gets the current datetime, again (but it's now in the next month) and uses that to determine the end date for the "current" quarter.
Now, you end up with the start of one quarter and - potentially - the end of the next quarter. This only happens if the request crosses into the next day, on the last day of the month, in the last month of a quarter.
Adding to the annoyance is that reports are often run by companies as part of an overnight batch process, increasing the likelihood of this occurring in a production environment... but testers are less likely to be testing functionality in the middle of the night - and daytime testing won't reproduce the issue.
Why Naming This Matters
They say that "naming something gives it power"... but I would say that naming something gives you power over it. When we name a specific type of bug, we make it easier to communicate during code reviews and architectural planning. Instead of saying, "We need to double check the date handling to see if there's something fishy in there," you can simply say, "We need to guard against Date Shear here."
The Solution for Date Shear
In simple single-script or single-method processes, the solution is simple. Grab a datetime at the beginning, store it in a variable and reuse it. In some cases, taking a parameter of the date in question is a good way to handle it.
For processes that call other processes (that may call further processes), taking the date in question in as a parameter allows them to all "be on the same page".
What do you think? Have you encountered "Date Shear" in your own projects? Is there a better name for this that I'm somehow missing?
SOCIAL SHARE CARD GENERATOR