Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: DatePicker input seems to convert date if not given in the correct date format #15432

Closed
2 tasks done
Jthomp75 opened this issue Dec 20, 2023 · 8 comments · Fixed by #15918
Closed
2 tasks done

Comments

@Jthomp75
Copy link

Package

@carbon/react

Browser

Chrome

Package version

1.4.0

React version

18.2.0

Description

When using a single DatePicker with the calendar, if you enter in a date in a different format, the component ends up with a totally different date selected, almost like it's tried to correct the input to be in the correct date format.
If I have a DatePicker in mm/dd/yyyy format and I enter the following date, 19th December 2023, in dd/mm/yyyy format, the DatePicker updates it to be 7th December 2024 instead.

Reproduction/example

https://react.carbondesignsystem.com/?path=/story/components-datepicker--single-with-calendar

Steps to reproduce

  • click on the date picker so that the calendar appears
  • while the date picker is in mm/dd/yyyy format, type 19/12/2023
  • the date seems to convert to 07/12/2023

Suggested Severity

Severity 3 = User can complete task, and/or has a workaround within the user experience of a given component.

Application/PAL

No response

Code of Conduct

@raphyluke
Copy link
Contributor

raphyluke commented Dec 20, 2023

Hello @Jthomp75, isn't it because you tried to put a dd/mm/yyyy on a mm/dd/yyyy input ?

If you want to put 19 December 2023, you should do day/month/year (dd/mm/yyyy) and not month/day/year(mm/dd/yyyy) as you did 😄

Will try to see from where is it from and patch this but I don't know if it's a bug or a normal value from an input type date

@raphyluke
Copy link
Contributor

raphyluke commented Dec 20, 2023

What is suppose to be the good patch here actually ? Like what should be expected here ? I'm a bit confused 😅

@erin-hughes
Copy link

Hi @raphyluke - the weirdness here is around the validation. If I have a DatePicker with the dateFormat parameter as mm/dd/yyyy, I'd expect that anything I type into the DatePicker that isn't in that format to be invalid.

If I input a string, for example, the DatePicker knows that it's not valid and actually clears the input. But if I input a date in a different format to the one that I've provided to the dateFormat parameter, it doesn't clear, but instead sets the DatePicker to a seemingly random date instead.

The question really is: should we expect the component to validate that dates provided are in the format that I've provided the component? Or, is the approach that if a user enters the wrong format and gets an erroneous date set, it's on them?

@raphyluke
Copy link
Contributor

Hello @erin-hughes ! I agree on this, I was simply confused on the fact that a person try intentionally to put a dd/mm/yyyy on a mm/dd/yyyy.

Actually I don't think we have to patch this like : "Someone put mm/dd/yyyy" but if he write "dd/mm/yyyy" we will detect it" because the format wouldn't even make sense.

I think that the only patch possible would be the make the input invalid and clear the input.

@OleksandrDzindziura
Copy link

Hello! Folks I want to ask you if it is possible to resolve this problem.
@raphyluke @Jthomp75 @erin-hughes

@tay1orjones
Copy link
Member

This is issue is rooted in how flatpickr parses dates. When an invalid date is put into a basic flatpickr in jsfiddle, it parses the date to the same value as our component does.

flatpickr.date.parsing.mov

Flatpickr's parseDate() is quite complex. The bug lies in there. I'd suggest a fix be made upstream to flatpickr itself rather than us overriding parseDate.

In any case, the question remains, when given a date of 77/77/7777, what should happen? It technically matches the date format of m/d/Y, but is an invalid date. Based on this it feels to me like the input should clear, as it does when you put in something like "asdf".

@tay1orjones
Copy link
Member

@tay1orjones
Copy link
Member

tay1orjones commented Feb 27, 2024

After debugging this further, @riddhybansal and I identified the root cause. flatpickr is using the native date methods to format the given date - setFullYear(), setMonth(), etc. These methods behave a bit unexpectedly when given values outside the typical range - from the setMonth documentation:

If a parameter you specify is outside of the expected range, other parameters and the date information in the Date object are updated accordingly. For example, if you specify 15 for monthValue, the year is incremented by 1, and 3 is used for month.

So for the case of 34/34/3434, here's how flatpickr builds up the date according to the format:

  1. Flatpickr first sets a temporary placeholder date equal to Jan 1 of the current year (2024)
  2. Flatpickr calls setFullYear(3434), date is now Jan 1 3434
  3. Flatpickr calls setMonth(34 - 1) which increments the date by two years (24 months, to 3436) and uses the remaining months (10) for the month. The date is now Oct 1 3436
  4. Flatpickr calls setDate(34) which is greater than the 31 days in October so this too rolls over into November by 3 days. The date is Nov 3 3436

You can check this out yourself by pasting this snippet into the browser console

const date = new Date(new Date().getFullYear(), 0, 1, 0, 0, 0, 0)
date.setFullYear(3434)
date.setMonth(34 - 1)
date.setDate(34)

console.log(date); // Output: Thu Nov 03 3436 00:00:00 GMT-0500 (Central Daylight Time)

Based on this it's not parseDate that we need to override, it's formatDate as shown in the example at the bottom of this page in the flatpickr docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

7 participants