[DatePicker]: autocorrection of dates is inconsistent and provides no controls over its value

[davidicus]

What package(s) are you using?

• carbon-components
• carbon-components-react

Detailed description

When entering a value into the date picker that is not a valid date and then tabbing focus away from the input the incorrect date is replaced with another properly formatted but widely different and probably incorrect date.

Examples:
Typing in 33 will result in a date of 09/01/2031
Typing in 99/9 will result in a date of 03/09/2061

Additionally, this behavior is inconsistent. If you look at this first "range" story and type 33 into first input then tab to the second and do the same and then tab out of the second input you will see that the first one was replaced while the second one was not.

The "simple" story also seems to leave the date as entered.

Is this issue related to a specific component?

This issue is related to the DatePicker component.

What did you expect to happen? What happened instead? What would you like to
see changed?

I would expect either the value to be left alone and my own validation can handle the error state or there to be a prop that allows me to enter in a default date that can work instead. Ideally it would be for this to be opt in and applications can handle their own error handling.

What browser are you working in?

This issue appears in both latest Chrome and FF

What version of the Carbon Design System are you using?

This is the latest Carbon that is published to storybook. v7.36.0

What offering/product do you work on? Any pressing ship or release dates we
should be aware of?

This question was raised to AI Applications PAL repo

Steps to reproduce the issue

1. Go to this story
2. Type 33 into first input and tab to second
3. Type 33 into second input and tab away
4. Notice first input adds a questionable correction of 09/01/2031 and the second input leaves the number as was entered by user.

Additional information

[tw15egan]

Seems like this behavior is the default behavior by Flatpickr, which would add another reason to look into alternative external date picker libraries. I'm able to improve it slightly by using the parseDate function, but it's still not great.

parseDate: (datestr) => {
            return new Date(datestr);
},

https://github.com/carbon-design-system/carbon/blob/main/packages/react/src/components/DatePicker/DatePicker.js#L337-L393

Related Flatpickr issue: flatpickr/flatpickr#1551

[grahamharper]

+1 for this to be changed.

The user may not be aware their invalid input was autocorrected and submit a valid but incorrect date. The user hitting a validation would be preferable in this case so they can be aware of the issue and correct it.

For example if you type 13/1/2020 it will autocorrect to 01/01/2021, but it's more likely the user meant 1/31/2020 than 01/01/2021 which is a totally different date.

For conversation sake, an alternative way to approach this if keeping autocorrection is valuable, could be to consider that if the user enters an impossible month or day, assume the character that made it impossible is part of the next part fo the date e.g. given a date format of month/day/year, if the user types 1 then 3 assume they meant 01/3 and auto correct to that. Though I think part of the key ot autocorrection would be making it clear to the user when the autocorrection as taken place.

[davidicus]

Hi @tw15egan. Are there any updates on this issue? Thanks in advance!

[davidicus]

Bump for update 👋

[JordanWSmith15]

@joshblack any updates on this issue? It is affecting all date pickers in the Maximo Application Suite

[DesMcCann]

Hi, any updates on this issue? It would be great to get this fixed.

[JordanWSmith15]

@joshblack @tay1orjones FYI

[tay1orjones]

In catching up on this my understanding is that it's so far been blocked by flatpickr - the only remedy would've been reimplementing the entire component or refactoring to use a different date picker library. That's a large hunk of work and likely (assuming) why this hasn't been addressed.

I found this that is related, #3832

Good news though maybe - in looking at the flatpickr issue, there might be some way to address this now through the onBlur improvements they made. Flatpickr just released it and more in a new version last month after not having released anything for over 15 months, 6 months before this issue was created.

[tay1orjones]

Related: #8454 (comment)

[tay1orjones]

So far we've been unable to upgrade flatpickr due to hitting numerous roadblocks. Upgrading caused more bugs than it fixed which even further calls into question the usage of flatpickr. We're considering next steps in #11967.

[alisonjoseph]

Possibly fixed by #15918

[hollyos]

@davidicus @tay1orjones @sstrubberg It looks like this is now fixed. I tested the variants of the DatePicker, and it will clear the invalid input with a calendar and leave the value alone in the simple input.