Skip to content

Conversation

@SHARMA1525
Copy link

@SHARMA1525 SHARMA1525 commented Nov 7, 2025

Fix issue where adding days/weeks/months/years to timezone-aware dayjs objects did not preserve timezone context correctly, causing incorrect valueOf() results when converting back to timezone.

The fix overrides the add() method for timezone-aware objects to:

  1. Format the date in timezone context
  2. Add calendar units without timezone conversion
  3. Convert back to timezone with keepLocalTime=true

This ensures all three approaches produce identical results:

  • dayjs.tz(time, tz).add(1, 'day')
  • dayjs.tz(dayjs.tz(time, tz).add(1, 'day').valueOf(), tz)
  • dayjs.tz(dayjs.tz(time, tz).add(1, 'day').startOf('millisecond').valueOf(), tz)

Fixes issue where valueOf() and format() results were inconsistent after adding calendar units to timezone-aware objects.

Linked Issue
#2957

Fix issue where adding days/weeks/months/years to timezone-aware dayjs objects
did not preserve timezone context correctly, causing incorrect valueOf() results
when converting back to timezone.

The fix overrides the add() method for timezone-aware objects to:
1. Format the date in timezone context
2. Add calendar units without timezone conversion
3. Convert back to timezone with keepLocalTime=true

This ensures all three approaches produce identical results:
- dayjs.tz(time, tz).add(1, 'day')
- dayjs.tz(dayjs.tz(time, tz).add(1, 'day').valueOf(), tz)
- dayjs.tz(dayjs.tz(time, tz).add(1, 'day').startOf('millisecond').valueOf(), tz)

Fixes issue where valueOf() and format() results were inconsistent after
adding calendar units to timezone-aware objects.
@Xiphoseer
Copy link

add is not the only function where this goes wrong and it's not the only DST bug as you can see from the issue tracker. set is another candidate. What does sort of work is to patch the private init function to recompute the offset. I've built a custom dst plugin that does that but not sure I can share it.

@SHARMA1525
Copy link
Author

I’ve raised a new PR that implements the suggested fix by patching the private init() function to recompute the timezone offset.

This ensures DST offsets remain consistent across all methods (.add(), .set(), .startOf(), etc.), not just .add().

All test suites (93/93) pass successfully.

Please take a look when you get a chance thank you again for your guidance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants