🐛 Poll times saved an hour off around daylight saving changes
The bug. When adding times to a poll, the time saved could be an hour later than the one you picked. It happened in two cases:
- The week contained a daylight saving change. For example, in a Chicago week starting on the Nov 1 2026 clock change, clicking the 10:00 AM row on Tue Nov 3 created an 11:00 AM option.
- Your browser's time zone was different from the poll's, and one of them changed its clocks on that day. You could pick a time that doesn't exist in the poll's time zone (such as 2:30 AM on Mar 14 2027 in Chicago), and it was saved an hour later. Times that do exist in the poll's time zone could also be missing from the month view.
The cause. The week and month views worked out times using your browser's time zone instead of the poll's, so daylight saving changes were applied from the wrong place.
The fix. Both views now work out times in the poll's time zone, so the time you pick is the time that's saved, whatever your browser's time zone. (#3615, #3618)
- In the week view, the hour skipped when clocks go forward is shown as a hatched "Clocks go forward" band, and a slot can't start inside it.
- In the month view, the start time dropdown lists exactly the times that exist in the poll's time zone.
Options you already saved are not changed. If you created a poll with times close to a daylight saving change, check its options.
Full Changelog: v4.16.2...v4.16.3