Recently a developer spottted a regex in our code base to detect if a string is a date, but noticed it was wrong. It was something like:

^20[0-9][0-9]-[0-9]+-[0-9]+$

which means dates like "2000-0000000-0000000" would be accepted, which is useless. I also mention how our unit tests that run against the function with this regex follows the happy path, but never really checks for the bad paths (including this one).

He then went to fix the regex, but then started to take into account things like days ending in 30/31, February ending in day 28, etc. TBH, it was very much overkill for what was needed (this was to effectively check if the string matched the "shape" of a date) but I was like "sure, why not".

He then turns around and says he has factored in leap years. At this point, I'm getting a little bit worried as he seems to be getting side-tracked. But whatever, it is done, he has got a little webpage that shows how the regex works, I say if you can export that as an image and annotate it, that would be great for future devs.

So I think that is pretty much the end of it, right? No more.

He then comes back later in the day and tells me he wants the regex to consider ROMAN FUCKING NUMERALS.

I-

SERIOUSLY.

WHO PUTS DATES INTO COMPUTERS IN THE FUCKING ROMAN NUMERAL FORMAT?!?!?!?

I try my best to kindly state that you can do that for fun and personal reasons, but I doubt our system will accept or even
present dates in roman numerals.

He seems incredibly sad about this.

I then ask him has he updated the unit tests to test for all these cases.

"What unit tests?"

@rootfs hahahahahahahaha

I'm sorry, that's very rude of me. That's genuinely dreadful.

@fishidwardrobe It's fine, I've recovered from the developers self-imposed scope creep.
@rootfs Rolled back the change because no tests? I mean, in a perfect world yes, but we don't live in one.
@fishidwardrobe Oh no no no. I think the code is still in development so it hasn't even been rolled out.