Open RafalOsieka opened 6 months ago
The intention of the date method is not to parse the input but to create the date object from the most basic values like js date and iso string.
There are separate methods implemented with locale specific and format specific parsing.
In that case, the only option is to use the parse
method like it was used in the example I provided.
Unfortunately, it requires to provide a format string, so it will be the job of the consumers of this library to make correct implementation for that.
Maybe it would be better to provide a new method in this library for that use case? For example, a new parse
method that doesn't need an format string, but just tries to parse the provided value using the current locale?
It is by design restriction to avoid consumers of the library from the parsing of arbitary date strings. The date string that you are parsing must be always strictly formatted and provided for the users (thats why we exposer getFormatHelperText method)
Hi,
I was investigating the issue in different UI library that uses the date-io to abstract the date/time functionality (https://github.com/vuetifyjs/vuetify/issues/19803).
It seems, that authors uses the
adapter.date(...)
(whereadapter
is the selected implementation of the time management lib).Unfortunatelly, that method seems, to only care for the date provided in the format
mm/dd/yyyy
.Let's assume the following example:
adapter.date(...)
is used for the validation, then everything is OK ifen-us
is selected, but if other locale is selected (likepl
), then the value inputed for theadapter.date(...)
method should be validated against the pl locale format, not enI think, that it will be just enough to extend the
date
method with some additional checks. The following is an example of the newdate
method implemenation for thedate-fns
interface, that should fix the issue (at least in a very common scenario).