You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered that the UI crash was caused by #73887. My guess is that some of the setInConfiguredTimezone() functions added by #73887 create invalid date objects that don't exist, such as February 31st.
@aduth@tyxla, seems like one of the following processes should be added when the date overflows. What do you think?
Convert to an actual date that exists. For example, convert February 31st to March 3rd.
Truncate the overflowed date. For example, convert February 31st to February 28th.
There have been a couple related issues and pull requests around this in the past couple weeks which address some (but maybe not all) of these types of invalid date entries:
#75254 was fixed in #75343, though I think the behavior there is about year values fewer than 4 characters.
#75285 is likely to be the more holistic fix, likely also addressing this issue as well in how it guards against updating invalid dates. If I understand, the behavior there is to reset the value to the last good value when blurring if the new date would be invalid.
Yep, I agree with @t-hamano that the behavior should work similarly to how Date() works in JavaScript (it handles leap year and any other subtleties already):
@getdave was working on some improvements here, and we discovered some additional pre-existing issues while working on #75285. My understanding is @getdave will get back to this at some point as the more important work on 7.0 cools down. Let's make sure to create issues with those, so we don't lose track of them.
It appears that an unintended problem occurs when a day that does not exist in the month is specified.
Set the date to March 31st.
Change the month to February. The UI crashes.
Since this issue first occurred in 7.0, I think it should be fixed in the 7.0 release. What do you think about extracting only the invalid data guard processing from #75285 and merging it first? In other words, the code looks like this:
What do you think about extracting only the invalid data guard processing from #75285 and merging it first?
Yeah, I was mostly worried about the initial implementation of that, but the most recent one with newDate instanceof Date && ! Number.isFinite( newDate.getTime() ) should do the job.
@getdave@aduth is adding the guard, something we can do in the next few days, so it will be part of the release?
One potential downside of that simple solution is that it could prevent user interactions in ways that are confusing: For example, if I set the date as 31 March 2026 and then change the dropdown month from March to February, then the UI would appear to be unresponsive, as it disallows the change to 31 February 2026 since it's an invalid date.
I found a pretty simple solution to restore the date clamping to prevent invalid dates from being selected. Though it requires a bit more work to ensure that the input value is synced correctly to the clamped date.
Interestingly, this wasn't really working very well before either. For example, entering 30 February 2026 in WordPress 6.9 and then tabbing will cause the text field to show as 30 March 2026 but the actual selected date is 02 March 2026.
#76400 should be sufficient to address most of the problems:
Avoids crash when given date out of bounds
Correctly reflects bounded value in input field after blur
Prevents ArrowUp day increment beyond valid day for month
As part of this, I also discovered some fundamental issues with InputControl "draft" tracking that I am trying to address in #76399 and was originally targeted at the input value de-sync problem described in my previous comment. I think this is still an issue (the test case added there feels like something we should support), but it has some gnarly knock-on effects for components that depended on its broken behavior.
Activity
t-hamano commentedon Feb 14, 2026
Thanks for the report.
It appears that an unintended problem occurs when a day that does not exist in the month is specified.
0022d112383d1eee52d1d0b0140e3991.mp4
The UI crash is a particularly serious issue, so let's fix it in WordPress 7.0.
t-hamano commentedon Feb 14, 2026
I discovered that the UI crash was caused by #73887. My guess is that some of the
setInConfiguredTimezone()functions added by #73887 create invalid date objects that don't exist, such as February 31st.@aduth @tyxla, seems like one of the following processes should be added when the date overflows. What do you think?
aduth commentedon Feb 16, 2026
There have been a couple related issues and pull requests around this in the past couple weeks which address some (but maybe not all) of these types of invalid date entries:
#75254 was fixed in #75343, though I think the behavior there is about year values fewer than 4 characters.
#75285 is likely to be the more holistic fix, likely also addressing this issue as well in how it guards against updating invalid dates. If I understand, the behavior there is to reset the value to the last good value when blurring if the new date would be invalid.
cc @getdave
tyxla commentedon Feb 22, 2026
Yep, I agree with @t-hamano that the behavior should work similarly to how
Date()works in JavaScript (it handles leap year and any other subtleties already):@getdave was working on some improvements here, and we discovered some additional pre-existing issues while working on #75285. My understanding is @getdave will get back to this at some point as the more important work on 7.0 cools down. Let's make sure to create issues with those, so we don't lose track of them.
t-hamano commentedon Mar 11, 2026
Since this issue first occurred in 7.0, I think it should be fixed in the 7.0 release. What do you think about extracting only the invalid data guard processing from #75285 and merging it first? In other words, the code looks like this:
tyxla commentedon Mar 11, 2026
Yeah, I was mostly worried about the initial implementation of that, but the most recent one with
newDate instanceof Date && ! Number.isFinite( newDate.getTime() )should do the job.@getdave @aduth is adding the guard, something we can do in the next few days, so it will be part of the release?
aduth commentedon Mar 11, 2026
I'll look to get a pull request put together today 👍
aduth commentedon Mar 11, 2026
One potential downside of that simple solution is that it could prevent user interactions in ways that are confusing: For example, if I set the date as 31 March 2026 and then change the dropdown month from March to February, then the UI would appear to be unresponsive, as it disallows the change to 31 February 2026 since it's an invalid date.
aduth commentedon Mar 11, 2026
I found a pretty simple solution to restore the date clamping to prevent invalid dates from being selected. Though it requires a bit more work to ensure that the input value is synced correctly to the clamped date.
Interestingly, this wasn't really working very well before either. For example, entering 30 February 2026 in WordPress 6.9 and then tabbing will cause the text field to show as 30 March 2026 but the actual selected date is 02 March 2026.
calendar-6.9.mov
aduth commentedon Mar 11, 2026
#76400 should be sufficient to address most of the problems:
As part of this, I also discovered some fundamental issues with
InputControl"draft" tracking that I am trying to address in #76399 and was originally targeted at the input value de-sync problem described in my previous comment. I think this is still an issue (the test case added there feels like something we should support), but it has some gnarly knock-on effects for components that depended on its broken behavior.