One Reader, Seven Surfaces

Our schedule wizard had a silent-drop bug with dates typed day first. Type a date the way a lot of the world writes it, save, and the date you typed was not the date that got stored. Anyone whose browser or habits put the day first could hit it.

The first fix was the wrong size

The wizard got its own fix first. It normalized day-first input before the value reached the database, and it worked on the wizard. That was the mistake. I had treated the bug as a property of one screen, so I fixed one screen.

The cost showed up in the ticket queue. A follow-up sat in the tracker saying other admin forms could still drop a typed date without saying so. The wizard was patched, and every other admin form with a date box still had the same hole. Each one had its own way of reading a typed date, so each one failed in its own way.

Sweeping the admin screens for date inputs turned up three different failure modes:

• The field went blank. You typed a date, saved, and it was gone.
• An event moved to today. The reader couldn’t parse the value and fell back to the current date.
• The date saved as 2001. The value was accepted, then landed somewhere it obviously didn’t belong.

All three are silent. No error, no message, nothing to tell staff the date they typed was not the date stored. The wizard was only the first place we noticed it.

One reader instead of seven patches

Seven surfaces had this problem, and I did not write seven patches. The sweep produced a single shared date reader with a fixed contract:

1. Take what the person typed.
2. Normalize day-first dates into the form the database expects.
3. If the input can’t be read, refuse it and say so with a message.

The third rule is the whole point. The old readers each had a fallback, whether blank, today, or a default that turned out to be 2001. A fallback is a decision to write something the user didn’t type. The shared reader has no fallback. It either returns a date it understood or returns an error the form shows to the person who typed it.

Once all seven surfaces called the same function, the bug class stopped being a list of places to remember. A new admin form that needs a date box now has one obvious way to get it, and that way can’t quietly drop the input.

Checking it by hand

I checked it live, not just in tests, by typing day-first dates into each of the seven boxes and confirming the value stuck. I also typed unreadable text into each one and confirmed the refusal message appeared instead of a blank field or a moved event. The change was closed to staging on release 3.362.

The sweep also turned up two unrelated problems. I filed them as their own tickets and kept them out of this change, so the reader change stayed small enough to verify screen by screen. The whole sweep and fix took about an hour and eight minutes.

Search for the other callers before closing

When a bug shows up in one place, I now search for the other callers before I call the first fix done. If the same job is done by seven separate pieces of code, the bug is in the arrangement, and the arrangement is what has to change.

dxdev LESSON · paste into your AI coding agent
LESSON: Centralize Shared Date Parsing and Reject Unreadable Input
SOURCE: dxdev.com/blog/2026-09-26_centralize-date-format-readers
WHAT HAPPENED: The first fix normalized day first input only in the schedule wizard. A sweep then found that other admin date fields could silently blank a date, replace it with today, or save it as 2001. Instead of creating seven separate fixes, the author introduced one shared reader that normalizes accepted input and returns an error for unreadable input. All seven surfaces were changed to call it, then checked live with day first dates and invalid text. The reader change was kept separate from two unrelated issues so it could be verified screen by screen.
THE RULE: When several surfaces perform the same input parsing job, replace their separate readers with one shared contract. That contract must reject unreadable input visibly instead of storing a fallback value the user did not enter.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Every date input surface calls the same shared date reader rather than parsing typed dates independently.
      2. The shared reader normalizes supported day first input before it reaches database storage.
      3. Invalid date input produces a visible refusal message and never saves a blank, current date, or default date.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.