Update date picker to allow typing in dates

[melvin-bot]

Problem
Date fields in New Expensify are picker-only. You have to select a date from the calendar and can't type one in. A partner reported this as friction, and the behavior is consistent across the app.

Background
Typing into date fields was originally disabled on purpose, for validation reasons. Design and engineering are now aligned on revisiting that decision.

Proposed solution
Allow typing into date fields using a guided (masked) input that enforces the expected format as you type, while keeping the calendar picker available for selection. Validation should stay intact.

References for the guided-input behavior only — not the visual design:

• MUI date picker
• HeroUI date picker

Next steps

• Design to spec the guided input: format, placeholder behavior, error states, and locale handling.
• Apply the pattern consistently to all date fields in the app, not just one surface.

Reported in Slack.

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

Triggered auto assignment to @dubielzyk-expensify (Design), see these Stack Overflow questions for more details.

[chuckdries]

A useful implementation reference might be react-aria's DateField, which implements masked date input behavior without showing a picker

[dubielzyk-expensify]

Added the prototype in Slack here.

I think we'd just disable the typing interaction on mobile.

cc @Expensify/design

[shawnborton]

I think we'd just disable the typing interaction on mobile.

What is the reasoning for that? Not saying we shouldn't, but just want to make sure I understand. Is it mostly just to keep the keyboard from popping open so we have space to see the calendars?

Proto is feeling NICE! Just left a comment in Slack about how we might validate the year part, since you get can yourself into a weird half-entered state there.

[JmillsExpensify]

Going to prioritize this as part of #convert and we can work with @Krishna2323 on it.

[dubielzyk-expensify]

What is the reasoning for that? Not saying we shouldn't, but just want to make sure I understand. Is it mostly just to keep the keyboard from popping open so we have space to see the calendars?

Yeah that was my thinking. That'd we'd either have to have it so that we show the keyboard and not calendar dropdown and then add a way to override it so you can show the calendar picker and it'd hide the keyboard. We could do both, I just think it'd be safe to start without it? Happy to be challenged here!

Just left a comment in Slack about how we might validate the year part, since you get can yourself into a weird half-entered state there.

Good q. I think we'd validate on submit of the form to avoid having errors while you type. That's what MUI does and it doesn't feel great imo:

CleanShot.2026-09-16.at.9.50.57.AM.mp4

And with ours the error is even more in-your-face so I suspect it'd feel even worse.

[dubielzyk-expensify]

Here's the prototype and the mocks are posted above. Is that enough for you to start @Krishna2323 ? I assume there'll be questions as we go so we can deal with them as they pop up :)

[shawnborton]

We could do both, I just think it'd be safe to start without it? Happy to be challenged here!

Down to start without it!

[JmillsExpensify]

Same! Prototype looks great.