Date Picker

When a date arrives as free text, the same day shows up in a different shape from every person. One writes 2026-09-16, another writes 2026/9/16, another writes September 16. Whatever receives it has to interpret all of them, and when interpretation fails the field answers with "that date format isn't valid." The person on the other side has no idea which part was wrong and types into the same box again.

Some values parse cleanly and still mean two things. 03/04/2026 is the fourth of March in most of Europe and the third of April in the United States. Nothing looks broken on screen while the stored value sits a month away from what was meant, and that kind of gap tends to surface long after the fact.

Dates that don't exist get through as well. February 30 and the first of the thirteenth month both look fine as strings, so they survive until something tries to save them.

Half the support tickets Noa saw on Pagedeck's document expiry field came from those three cases. A fourth problem sat underneath them: working out what date "two weeks from now" lands on was left to the person filling in the form, who had to picture a calendar to answer it.

A date picker removes all four at once. Turn writing into choosing and there is no room left for a bad format, an impossible day, or arithmetic done in someone's head.

Only the field shows by default, and pressing it opens a calendar anchored underneath. The interaction has five parts.

1. Opening. Pressing the field, or the calendar icon beside it, raises a popover — a small layer attached to the element that was pressed, which takes only as much room as it needs and leaves the page behind it visible.
2. Moving. Arrows step one month at a time, and pressing the title in the middle switches to a view for jumping straight to a year and month. Without that second route, someone headed twenty years back has to press an arrow 240 times.
3. Choosing. Pressing a day fills the field and closes the calendar. Today and the selected day carry different marks, so nobody has to reopen the calendar to confirm what they picked.
4. Blocking. Days that can't be chosen are dimmed and stop responding to presses. For a booking that covers past dates and closed days. Refusing a choice before it happens generates far fewer support tickets than accepting it and objecting afterward.
5. Separating. The value shown and the value stored are two different things. A Korean reader sees one arrangement of the day, month and year, an English reader sees Sep 16, 2026, and storage uses a single format underneath. Adjusting presentation to language and region this way is called localization.

Two variants come up often. Range selection takes a start and an end pressed in sequence and shades the span between them. The date-and-time form continues inside the same popover with a list of times once the day is settled.

Adding a calendar doesn't mean locking the field. Leave typing open and reflect what gets typed back into the calendar. For someone who can't use a mouse this path is the only way in, which is why keyboard navigation — moving through the calendar grid with arrow keys — belongs to the same piece of work.

Any field that takes a date can carry one, but four places account for most of them, and each wants a different shape.

1. Bookings and scheduling — only future dates. Block everything before today and a plain calendar covers it.
2. Due dates and expiry — usually within a few weeks of today. Buttons for "tomorrow" and "next week" next to the calendar put the common values in with one press.
3. Range filters — the control that sets the period a dashboard reports on. Range selection is the base, with shortcuts like "last 7 days" alongside it. Without those, anyone who checks the same window daily opens the calendar twice a day, every day.
4. Date of birth — the one case where a calendar loses. The trip back thirty years is long, so three select fields for year, month and day, or plain typing, gets there faster.

One question separates the four: is the date the person wants anywhere near the month currently on screen. Close, and the calendar wins. Far, and typing wins.

Touch screens add one more constraint. Thirty day cells crowded into a narrow screen leave each cell too small to hit. Meeting the touch target standard — the minimum area a finger can reliably press — usually means swapping the calendar for a wider panel that slides up from the bottom of the screen on mobile.

"Let's take that date with a picker. Typed in, the formats come in all over the place."

Choosing the input method is the same decision as choosing the quality of the values that arrive.

"Can we add a 'last 30 days' button to the range filter? I'm opening that calendar twice a day."

Range selection exists but the shortcuts don't, so the same motion keeps repeating.

"On the end date calendar, please block anything before the start date."

A request to enforce the order of two dates at the moment of choosing.

When Noa rebuilt Pagedeck's document expiry screen, the first version was a calendar and nothing else. Mia looked at the data and found the expiry dates people actually chose clustered on three values: seven days out, thirty days out, ninety days out. The three went up as buttons with the calendar underneath them.

After the change, the only people opening the calendar were the ones who wanted a date outside those three.

The common assumption is that every date field should carry a picker, because a calendar looks easier than typing in every case. The further the target date sits from today, the worse that holds. A user born in March 1992 either presses an arrow hundreds of times or hunts for the year selector. Left alone, this costs signups, and nobody traces the drop-off back to the date of birth field.

The second assumption is that a calendar makes bad values impossible. Impossible days do get blocked, and that is where the blocking stops. An end date earlier than the start date, or a range wider than the report allows, gets past a calendar on its own. Without separate validation, someone picks a value the interface offered and then receives an error message about it, which lands worse than most errors because the interface could have prevented it.