Description
Check that this is really a bug
- I confirm
Reproduction link
https://codesandbox.io/p/sandbox/react-big-calendar-example-forked-tlyfwm
Bug description
I'm assuming it's related to this PR:#2712
Since version 1.19.2 there is a time shift for different time zones
now with Day and Week view the time starts not from 12AM but shifts depending on the time zone
unfortunately the use of min or max prop. does not solve the issue.
The recent change in dayjsLocalizer where merge() uses utc(true) breaks local timezone support:
return dayjsLib(mergedDateTime).utc(true).toDate();
This forces all merged dates (including min, max, event bounds) into UTC, even though all inputs are Date objects in local time.
In timezones with offset, this causes visible shifts:
min={new Date(2025, 0, 1, 0, 0)} renders as 3:00 AM in +3
Previous version of merge() respected local time and worked correctly. Please consider reverting or adding a toggle.
Expected Behavior
When using min and max props in react-big-calendar (with dayjsLocalizer), the values passed as Date objects (e.g. new Date(2025, 0, 1, 0, 0)) should be interpreted in the local time zone, so that:
min={new Date(2025, 0, 1, 0, 0)} renders the start of the day at 12:00 AM local time
max={new Date(2025, 0, 1, 23, 59)} renders the end of the day at 11:59 PM local time
Actual Behavior
After the update that added .utc(true) to the merge() function of dayjsLocalizer, the min and max values are now interpreted as UTC, not local time. This leads to:
min={new Date(2025, 0, 1, 0, 0)} being displayed as 3:00 AM in a GMT+3 time zone
max and all event start/end times also shifting away from expected local positions
This breaks expected rendering in all views that depend on accurate local time (especially day and week views).
react-big-calendar version
1.19.2
React version
18.3.1
Platform/Target and Browser Versions
Ubuntu Chrome
Validations
- Read the docs.
- Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
- Make sure this is a react-big-calendar issue and not an implementation issue
Would you like to open a PR for this bug?
- I'm willing to open a PR