If there is a preexisting value of the form "0x" in the day section of the DatePicker, typing a new two-digit value resets the day value and results in the wrong number.
For example, if the preexisting value is "01" and I go to type 23, after pressing 2, the value will be 12. Then if I hit 3, the value will reset to 03 instead of becoming 23.
Is there anyway to prevent this behavior?
For example, if the preexisting value is "01" and I go to type 23, after pressing 2, the value will be 12. Then if I hit 3, the value will reset to 03 instead of becoming 23.
Is there anyway to prevent this behavior?
Hello, Thomas.
Thank you for the provided details about the issue you are observing with the DatePicker component.
We tested the DatePicker in this StackBlitz example and the component seems to be working as expected.
Based on our research, I would assume that the value entered in the input of the component is the one associated with the month part of the date and thus as this value cannot be bigger than 12, the component is automatically handling it. In other words, the way the date value is separated by default is month/day/year.
Can you please check the above example and see if the DatePicker in it is behaving similarly to the DatePicker in the project you are working on? If the behavior is the same and you need to display the date in day/month/year format, then check this example that demonstrates how to implement the targeted functionality. In the provided example the format property of the DatePicker is set as follows:
<DatePicker value={value} onChange={handleChange} format={'d/M/y'} />More details about the formatting inside the DatePicker's input can be found in the Formats article in our documentation.
Please let me know if the above details help you implement what you need in your project.
Our DatePicker format was being set as "MM/dd/yyyy", but I've tried it with just "M/d/y" and still see the same behavior in the "day" input section. In my current implementation, I have leading zeros in the values (03/01/2024 vs 3/1/2024). I tried implementing without the leading zeros, and I still see the undesired behavior. But rest assured, I am typing into the day section and not the month.
In the StackBlitz example you provided, I saw the same behavior in the day section. I would type in the single digit of 1, arrow out of the day section, arrow back into the day section, type '23', and then end up with just the 3.
I assume this is the default/intended behavior, but if there's a way to override this behavior for the day section, it would really help out our QA automation team. It conflicts with their automation tests, and they're also concerned users will be frustrated over not seeing the value they directly typed in being displayed.
In case it helps, here's the exact steps I'm using in the StackBlitz:
1. Arrow into the day section where a single digit is the preexisting value
2. Type 2 (for 23)
3. Type 3 (for 23)
Value is now 3 instead of 23
Hi, Thomas,
Thank you for the screenshots and the information provided.
I have tested the scenario and it is a bug. We have started work to fix it and it also has been logged as an issue in our public repo where it can be tracked and monitored:
If any further inquiries arise let me know.