Hi,
I was investigating the issue in different UI library that uses the date-io to abstract the date/time functionality (vuetifyjs/vuetify#19803).
It seems, that authors uses the adapter.date(...) (where adapter 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:
- we have an input that allows to provide the date (as a string) in a specific format (depending of selected UI locale - en-us (mm/dd/yyyy) or polish (dd.mm.yyyy)
- some code will validate that value depending on the current locale
- if
adapter.date(...) is used for the validation, then everything is OK if en-us is selected, but if other locale is selected (like pl), then the value inputed for the adapter.date(...) method should be validated against the pl locale format, not en
I think, that it will be just enough to extend the date method with some additional checks. The following is an example of the new date method implemenation for the date-fns interface, that should fix the issue (at least in a very common scenario).
import DateFnsAdapter from '@date-io/date-fns';
import { isValid as dateFnsIsValid } from 'date-fns';
class BetterDateFnsAdapter extends DateFnsAdapter {
date(value) {
if (typeof value === "undefined") return new Date();
if (value === null) return null;
const defaultParsedValue = super.date(value);
if (dateFnsIsValid(defaultParsedValue)) return defaultParsedValue;
try {
let parseResult = this.parse(value, this.formats.keyboardDateTime24h);
if (dateFnsIsValid(parseResult)) return parseResult;
parseResult = this.parse(value, this.formats.keyboardDateTime);
if (dateFnsIsValid(parseResult)) return parseResult;
parseResult = this.parse(value, this.formats.keyboardDate);
if (dateFnsIsValid(parseResult)) return parseResult;
} catch {
// ignore
}
return defaultParsedValue;
}
}
Hi,
I was investigating the issue in different UI library that uses the date-io to abstract the date/time functionality (vuetifyjs/vuetify#19803).
It seems, that authors uses the
adapter.date(...)(whereadapteris 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-usis 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
datemethod with some additional checks. The following is an example of the newdatemethod implemenation for thedate-fnsinterface, that should fix the issue (at least in a very common scenario).