One hour added to time when selecting date in DST with a fixed timezone.

[aostijn]

Hi! First of all, thanks a lot for the work on this tool, it's great! I ran into an issue that somewhat resembles #991 but doesn't seem to be entirely the same (#991 occurred in 9.0.3 and should be fixed with 10.0.0 but for my problem, it's the opposite), so I created this bug report.

Describe the bug
I provide a fixed timezone with the timezone string prop (in my case: 'Europe/Brussels'). At the time of writing (December), we're in winter time, so outside of DST. When I choose a date and time outside of DST (for example in January), everything works as expected. But when I choose a date and time inside of DST (for example in June), when I confirm, one hour is added to the time I chose.

Some notes that might be useful:

• This problem doesn't happen when I don't provide a timezone and I let the datepicker use the local timezone (which also happens to be Europe/Brussels).
• The problem occurs the other way around too: when I'm inside DST (for example in June) and I pick a date outside DST (for example in January), one hour is subtracted from the time I chose.
• This problem only started occurring in version 10.0.0. I didn't have the problem with version 9.0.3.
  • See this example in 9.0.3 without the problem
  • See this example in 10.0.0 with the problem

To Reproduce
Steps to reproduce the behavior:

1. Go to this example in 10.0.0 with the problem
2. Click on the datepicker.
3. Choose a date and time in June if you're currently in winter time (or vice versa: pick a date in January if you're currently in summer time).
4. Confirm the date and time.
5. Notice how the resulting time is one hour later than the one chosen (or one hour before if you're currently in summer time).

Expected behavior
The time should be the same as selected.

Screenshots

Desktop & mobile (please complete the following information):

• Browser: Chrome Version 131.0.6778.140 (Official Build) (64-bit)
• Library version: 10.0.0

[RickSchijvenaars]

@aostijn is this bug solved for you now?

@Jasenkoo I am still having this exact issue for timezone America/New_York, even after updating to ^11.0.1. Right now it's Mar 7 (outside DST), but when selecting a date from Mar 9 (in DST) it adds 1 hour. And when I select an other date it adds another hour to the already added hour.
Also, when I selected an other date (in DST) and I want to decrement the selected hours I have to click twice for the input value to update, it is not in sync anymore.

[aostijn]

Hi @RickSchijvenaars

Yes, it's solved for me. The problem you're facing is probably another one, which I ran into as well a couple of days ago. It doesn't seem to be a DST/non-DST problem (because Mar 9 is still outside of DST).

I've created a new issue: #1091. Take a look and see if this is actually the issue you're facing.

Cheers :)

[adamreisnz]

This should have been marked as a breaking change tbh, as this fix caused our specs to fail when upgrading from v9 to v11. The emitted Date value is now 1 hour less, and this can result in a whole day difference when converting between timezones.

Don't get me wrong, good to have the bug fixed if it was an actual issue, but a bit of a head scratcher to figure out why the output suddenly changed by an hour.

[adamreisnz]

Actually I think this change introduced a bug, I will raise a new ticket for it.