DateField: onChange not called on blur when date is invalid or incomplete

[pudek357]

Provide a general summary of the issue here

According to #9510, invalid or incomplete date values should not be emitted via onChange while typing, but should be emitted when the user blurs the field.
However, when the user blurs the field with an invalid or incomplete date, onChange is not called at all.

🤔 Expected Behavior?

• User enters valid date.
• User removes one of the segment (date become invalid)
• User blurs from the field
• onChange is called.

😯 Current Behavior

• User enters valid date.
• User removes one of the segment (date become invalid)
• User blurs from the field
• onChange is not called.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

Add console log to onChange to TimeField example in https://react-aria.adobe.com/TimeField and test repro steps above, or use this link: https://stackblitz.com/edit/hazsexms-xrw2sxau?file=src%2FExample.tsx

Screen.Recording.2026-02-09.at.14.31.09.mov

[LFDanLu]

There is a bit of ambiguity in the description of that PR, but the intention was to emit onChange on blur of an invalid field if said invalid value would end up being coerced to a valid value (e.g. if a user entered Feb 29 in a year that isn't a leap year). However, if we cannot reasonably infer/clamp/coerce the provided value, such as in your reproduction where part of a time segment is deleted, then we don't fire onChange.

I could see an argument for firing null in that case instead, but then how would an app differentiate this incomplete blur case from the case where the user has fully cleared their field? If we were to clear all the segments on blur of a incomplete field, I could see that being poor UX for the end user if they intended to come back to the field and only wanted it to be incomplete temporarily.

Do you have a use case you can share where the current behavior is problematic?

[crazko]

Hi, we encountered this problem as well. In our case, we have two DateRangePickers which values are part of the filter and a change in values triggers API request.

When user clears part of one field, its value is still used in the filter when they change the value of the other field. Selected values are not displayed anywhere, as we depend on the fields themselves. Therefore user has no way to know the filter criteria.

Old behavior - once any segment is empty, onChange returns null. We set the field state to error and do not trigger API request.

dfch1.mp4

New behavior - onChange is not triggered, but value is still present in the fitler - API request is possible.

dfch2.mp4

---

but then how would an app differentiate this incomplete blur case from the case where the user has fully cleared their field?

I think it is not needed to differentiate between incomplete and fully cleared field. Or at least in this case.
The new behavior to fire onChage on blur is indeed better. Just return null for incomplete values as it was before.

[crazko]

Similar use case - a form with a date field with pre-populated value. User removes part of the value and continue to other fields. Date field is not considered as invalid and user can still submit the form potentially with a different value of date field than was intended, but there was no way to let them know.

[devongovett]

Just return null for incomplete values as it was before

This would mean that if you make the field controlled, set state in onChange and passed back null as the value prop the field would entirely clear when it should only clear a single segment. That's why we don't call onChange is the value is partial or invalid.

I think we could mark the field as invalid when it is partially entered though so that forms couldn't submit.

[crazko]

This would mean that if you make the field controlled, set state in onChange and passed back null as the value prop the field would entirely clear

Before recent changes, it was allowed to send null and the incomplete value stayed - in the first video above, in the first DateRangePicker the value is null but other segments still have their values.
That's why it was possible to display error message and set validation state to invalid (by reading the current state - it is a controlled component).

I think we could mark the field as invalid when it is partially entered though so that forms couldn't submit.

Would it work for controlled components? How should we read the invalid state?

[mryechkin]

the intention was to emit onChange on blur of an invalid field if said invalid value would end up being coerced to a valid value (e.g. if a user entered Feb 29 in a year that isn't a leap year)

Hi @LFDanLu - I'd like to ask some clarification on this specifically. My team maintains a component library built using React Aria, and we just had our users raise a concern that there is no way to tell when an invalid date has been coerced to a valid value (ie. user entered 2026-02-31 and it auto-corrected to 2026-02-28). As far as I can tell in my testing, the onChange does not fire in this scenario - was this a decision that's been reversed? If so, is there any way to indicate an error in this use case?

I'm having a hard time figuring out how one would do this with the React Aria DatePicker. At least if the onChange fired with null then our users could handle that on their end. Do you have any recommendations for how to handle this?

[LFDanLu]

@mryechkin seems to fire for me here: https://stackblitz.com/edit/r9raaag9?file=src%2FExample.tsx, if I type 2/31/2026 and blur it fires onChange with 2/28/2026. What version are you on?

[mryechkin]

@mryechkin seems to fire for me here: https://stackblitz.com/edit/r9raaag9?file=src%2FExample.tsx, if I type 2/31/2026 and blur it fires onChange with 2/28/2026. What version are you on?

It does fire, but my issue is precisely with the fact that the returned date is 2/28/2026 - I have no way of indicating to the user that they had selected an invalid date originally. We have a problem that when users are used to quickly entering long forms with lots of fields, they can accidentally enter this wrong date and there is no way to inform them of that - which can lead to problems.