fix: parse holiday date strings as local time to prevent timezone shift #6106
+38
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #6105
This PR fixes a bug where holidays specified as ISO date strings (e.g.,
"2025-01-01") would display on the wrong day in timezones west of UTC.The Problem
When holiday dates are provided as ISO date strings (
YYYY-MM-DD), the previous implementation usednew Date(string)to parse them. Per JavaScript specification, ISO date strings without a time component are parsed as UTC midnight.Later, when the date is formatted using
date-fns'sformat()function, it converts the date to the local timezone. This causes the date to shift backward by one day for users in timezones west of UTC.Example of the bug:
"2025-01-01"2025-01-01T00:00:00.000Z(UTC midnight)2024-12-31T16:00:00.000-08:00The Fix
The fix uses the existing
parseDateutility function with the"yyyy-MM-dd"format. This leveragesdate-fns'sparsefunction which treats the date string as local time rather than UTC, ensuring holidays display on the intended date regardless of timezone.Before:
After: