What "today" means in a clinic, and why software keeps getting it wrong

Dates look like the easy part of clinic software. They are the part that quietly produces the worst bugs, because a wrong date almost never looks wrong. It looks like a date.

Three of these come up constantly. Orla has an opinion on each, and the opinions are house rules rather than preferences — a change that breaks one looks wrong next to its neighbours.

1. 03/04/1978 is not a date

It is two dates. In Ireland it is the third of April. To a spreadsheet that has decided the file is American, it is the fourth of March.

This matters most during a migration, which is exactly when nobody is looking. A CSV of two thousand patients comes out of the old system, goes into the new one, and roughly a third of the dates of birth are silently wrong — the third where the day happens to be twelve or less, which is the only third that can be misread without producing an obviously invalid date.

Orla writes dates dd.mm.yyyy everywhere a person reads one. Not yyyy-mm-dd, not mm/dd/yyyy, and never a format that changes between screens. There is one deliberate exception: <input type="date"> and day-scoped query keys require ISO, so those stay yyyy-mm-dd — a machine format in a machine's place.

And the import asks. When a column is ambiguous, the dry run stops and says "row 214 reads 03/04/1978 — day first or month first?" rather than guessing and being right two thirds of the time.

2. "Today" belongs to the clinic, not the viewer

A practice owner checks tomorrow's diary from a hotel in New York. It is eight in the evening there and one in the morning in Dublin. Which day should the diary open on?

The clinic's. Always. The appointments are in Dublin, the practitioners are in Dublin, and the only useful meaning of "tomorrow" is the clinic's tomorrow. Software that renders times in the viewer's timezone will show that owner a diary shifted by five hours and a "today" that is actually tomorrow, and it will do it without any indication that anything has been converted.

So: every time in Orla renders in the clinic's timezone, never the viewer's.

The subtler half is calendar dates. A date of birth, a care plan's start date, the day a consent was given — these are date columns, not timestamps. They have no time and no zone. Putting one through a timezone conversion cannot improve it; it can only move it to the wrong day. So calendar dates are read in UTC and rendered as-is, and the rule is written down because it is exactly the kind of thing a well-meaning "let's be consistent about timezones" refactor breaks.

3. Two days a year are not 24 hours long

On the last Sunday in March, Irish clocks go forward and a day is 23 hours long. On the last Sunday in October they go back, and a day is 25 hours long with one hour occurring twice.

Everything that reasons about a working day has to survive both:

• A working pattern that says "Tuesdays, 09:00 to 17:00" must still mean 09:00 to 17:00 local on the Tuesday after a clock change, not 08:00 to 16:00.
• A recurring block — a weekly supervision at 14:00 — must not drift.
• A shift that crosses midnight is one window, not two half-days.
• A waitlist entry whose last valid date has passed retires itself using the clinic's calendar day rather than UTC, because an entry that expires at one in the morning local time expires on the wrong day for everyone.

The availability engine that decides whether a slot can be offered is checked in both directions across both changes. Not because it is glamorous work, but because the failure mode is a patient turning up an hour early to a clinic that is shut.

Why write any of this down

Because none of it is visible in a demo. Every system looks correct on a Tuesday in June.

The reason it is worth caring about is that a date format that flips between screens is not a style inconsistency in a clinical record — it is a clinical risk. And the reason it is worth publishing is that it is checkable. Ask any vendor, us included, what happens to 03/04/1978 in their import, and what timezone the diary renders in when you open it abroad.

Those are two of the eleven questions worth asking before you move anything.