DateTimePicker behaves oddly at the beginning of DST/Daylight Saving Time

[eberleant]

Description

Note: My laptop is set to use the America/New York timezone. If I set it to a timezone that does not observe DST, this issue does not occur.

When setting the value of a DateTimePicker to the hour when DST begins (ie, the hour that doesn't exist in the current system timezone, such as 03/10/2024 02:00), the internal value of the picker becomes 03/10/2024 03:00 instead, though the text displayed is still 03/10/2024 02:00. Interestingly, if I set the value to 03/10/2024 03:00, then change the time to 02:00, it works as expected.

Expected outcome

Because DateTimePicker deals with local date time, I would expect it to ignore the timezone of the system, so it should allow date-times that would be considered invalid using the system timezone. Validation of the date-time can then be done by the developer.

Minimal reproducible example

var valueText = new Text("");
var dateTimePicker = new DateTimePicker();
dateTimePicker.addValueChangeListener(event -> valueText.setText(event.getValue().toString()));
add(dateTimePicker, valueText);

Steps to reproduce

1. Change your system timezone to America/New York.
2. Add the snippet above to a view.
3. Set the date to 03/10/2024 and time to 02:00.

Environment

Vaadin version(s): 24.4.13
OS: MacOS 14.4.1

I think this may be an issue in the web component JS. In the browser console, if I run the following:

let x = new Date('03/10/2024');
x.setHours(2);
console.log(x);
// Sun Mar 10 2024 03:00:00 GMT-0400 (Eastern Daylight Time)

I didn't dig into the code too much, but maybe if the web component is just parsing the date-time section and ignoring timezone, that could explain why it's getting 03:00 instead of 02:00 for the local date-time value.

Browsers

Chrome, Firefox, Safari

[TatuLund]

Possibly related to: #1505

[TatuLund]

Also related to: vaadin/web-components#3942

[rolfsmeds]

Let's investigate to figure out the cause for this and determine whether it's a bug, a design flaw, and whether we should just change the default behavior or provide an API in case someone is relying on it.