Representative Line: A Date Next Month

We all know the perils of bad date handling, and Claus was handed an annoying down bug in some date handling. The end users of Claus's application do a lot of work in January. It's the busiest time of the year for them. Late last year, one of the veteran users raised a warning: "Things stop working right in January, and it creates a lot of problems." Unfortunately, that was hardly a bug report. "Things stop working?" What does that even mean. Claus's team made a note of it, but no one thought too much about it, until January. That's when a flood of tickets came in, all relating to setting a date. Now, this particular date picker didn't default to having dates, but let the users pick values like "Start of last month", or "Same day last year", or "Same day next month". And the trick to the whole thing was that sometimes setting dates worked just fine, sometimes it blew up, and it seemed to vary based on when you were setting the dates and what dates you were setting. And let's take a look at one example of how this was implemented, which highlights why January was such a problem: startDate = startDateString == "Start of last month" ? new DateTime(today.Year, today.Month-1, 1) : startDate; They construct a new date out of the current date, by subtracting one from the Month of the current date. Which would never work for January. And this pattern was used for all of their date handling. So "Same Day Next Month" worked fine- unless the current date was near the end of January, since they just added one to the month. Of course, "Same day next year" blows up on February 29th. And "Same day next/last week" works by adding or subtracting 7 from the day, which does not play nicely with month boundaries. The fix was obvious: rewrite all of the code to do proper date arithmetic. The nuisance to the whole thing was that there were just a lot of "default" date arrangements that the software supported, so it was a surprising amount of effort to fix. And, given the axiom that "every change breaks somebody's workflow", there were definitely a few users who objected to the fixes- they were using the broken behavior as part of their workflow (and perhaps an excuse for why certain scheduling arrangements were "forbidden"). As a bonus complaint, I will say, I don't love the use of string literals to represent the different kinds of operations. It's certainly not the WTF here, but I am going to complain about it anyway. [Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.

twrlz

Oct 16, 2025 - 13:00

0 0

We all know the perils of bad date handling, and Claus was handed an annoying down bug in some date handling.

The end users of Claus's application do a lot of work in January. It's the busiest time of the year for them. Late last year, one of the veteran users raised a warning: "Things stop working right in January, and it creates a lot of problems."

Unfortunately, that was hardly a bug report. "Things stop working?" What does that even mean. Claus's team made a note of it, but no one thought too much about it, until January. That's when a flood of tickets came in, all relating to setting a date.

Now, this particular date picker didn't default to having dates, but let the users pick values like "Start of last month", or "Same day last year", or "Same day next month". And the trick to the whole thing was that sometimes setting dates worked just fine, sometimes it blew up, and it seemed to vary based on when you were setting the dates and what dates you were setting.

And let's take a look at one example of how this was implemented, which highlights why January was such a problem:

startDate = startDateString == "Start of last month" ? new DateTime(today.Year, today.Month-1, 1) : startDate;

They construct a new date out of the current date, by subtracting one from the Month of the current date. Which would never work for January.

And this pattern was used for all of their date handling. So "Same Day Next Month" worked fine- unless the current date was near the end of January, since they just added one to the month. Of course, "Same day next year" blows up on February 29th. And "Same day next/last week" works by adding or subtracting 7 from the day, which does not play nicely with month boundaries.

The fix was obvious: rewrite all of the code to do proper date arithmetic. The nuisance to the whole thing was that there were just a lot of "default" date arrangements that the software supported, so it was a surprising amount of effort to fix. And, given the axiom that "every change breaks somebody's workflow", there were definitely a few users who objected to the fixes- they were using the broken behavior as part of their workflow (and perhaps an excuse for why certain scheduling arrangements were "forbidden").

As a bonus complaint, I will say, I don't love the use of string literals to represent the different kinds of operations. It's certainly not the WTF here, but I am going to complain about it anyway.