But thanks for raising the issue - I learned something today
@vital-koala , which is why I want as much as possible to happen on the server side. For instance, it would be fun to extend a DatePicker on the server-side, so that appending “+7” to add 7 days to the value. When the server-side only gets access to the validated and converted value, I lose that ability. Not sure I want it, but it would be nice to have the option.
@vital-koala, I’ll put this aside for now and check out setDefaultValidatorEnabled when 24.4 is released
Regarding that “+7”, you should be able to do that. Normally when DatePicker is not able to convert the value to date, its value will be null, the internal validator will turn it red. There is also the original string sent to server, e.g. “+7”. You can override the internal validator with custom logic and give what ever treatment with the “+7” you want. These are fairly new additions to Vaadin 24 brought in in different minor versions.
Are you sure? As far as I know the wrong value isn’t available on the server because the event does not contain it; https://github.com/vaadin/web-components/blob/2ab4f8efed5a8705683616fe085a76764065857e/packages/time-picker/src/vaadin-time-picker.js#L550 I remember the initial PR where the event was added and my wish that it should contain the value was dismissed 
Oh, bugger, I thought it would be there … But anyways you can listen to that event via Element API and fetch the input value asynchronously.
@yummy-rhino, it was more of a general observation. It was more important earlier when you couldn’t expand dates. Now that I can do this I’m happy: .setDateFormats(“dd.MM.yyyy”, “dd”, “ddMM”, “ddMMyy”, “ddMMyyyy”)
But, just to be clear: When I write “x” into a DatePicker, I want it to show “x” and be invalid, like it is now. I do not want it to be reset to the previous valid value
For a UI framework for Java developers, it would be rather important to get the access for the non-parseable input 
And for the value to be null if it can’t be parsed.
Looks like I was too quick when I said that DatePicker could expand dates now. It used to work, but when I tested it just now it didn’t 
someDate.setI18n(new DatePickerI18n().setDateFormats("dd.MM.yyyy", "dd", "ddMM", "ddMMyy", "ddMMyyyy", "yyyy-MM-dd", "MM/dd/yyyy"));
someDate.setAutoOpen(false);
add(someDate);
Well it’s not red, meaning the server side should have gotten the correct value, or?
@quirky-zebra, you’d think, but no
https://github.com/vaadin/platform/issues/5073
Registered that issue with this test-case:
.setDateFormats
( "dd.MM.yyyy"
, "dd"
, "ddMM"
, "ddMMyy"
, "ddMMyyyy"
, "yyyy-MM-dd"
, "MM/dd/yyyy"
);
someDate.setI18n(i18n);
someDate.setAutoOpen(false);
someDate.addValueChangeListener(event -> {
Notification.show("Date changed: " + event.getValue());
});
add(someDate);```If I write “0101” nothing happens. No valuechanged. No red.
If I write “x” I get red validation error
If I replace “x” with “0101” nothing happens. The red remains.
Even with addInvalidChangeListener I get nothing for “0101”
Maybe this browser console error can explain it:
Uncaught RangeError: Format string contains an unescaped latin alphabet character
n
v http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6732
D6 http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6732
c http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6732
u http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6732
__parseDate http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6668
_onInput http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:6668
__onInput http://localhost:8080/traveller/app/VAADIN/build/generated-flow-imports-foCJs4LJ.js:3463
Confirmed regression since 24.3.0 : https://github.com/vaadin/flow-components/issues/6065