Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dayjs.add() behaves incorrect with timezones #2624

Open
helmut-jacob opened this issue Apr 8, 2024 · 4 comments
Open

dayjs.add() behaves incorrect with timezones #2624

helmut-jacob opened this issue Apr 8, 2024 · 4 comments

Comments

@helmut-jacob
Copy link

helmut-jacob commented Apr 8, 2024

Describe the bug
Adding a delta to timezone-aware dayjs objects results in a different result compared to adding to utc dayjs object.

Can be reproduced with the following piece of code:

// create a dayjs object representing a timestamp just before the DST switch in Europe/Berlin
const t = dayjs('2023-10-29T00:00:00+02:00').tz('Europe/Berlin')
// delta is 4h in seconds
const delta_s = 4 * 60 * 60;
// add delta without converting timezones
const t1 = t.add(delta_s, 's')
// convert to utc, add delta and convert back to local timezone
const t2 = t.utc().add(delta_s, "s").tz('Europe/Berlin')
// now we expect t1 == t2
expect(t1.unix()).toBe(t2.unix())

Expected behavior
add() should properly work with timezone-aware dayjs objects.

Information

  • Day.js 1.11.10
  • OS: Linux
  • Browser: vitest
  • Time zone: Europe/Berlin
@klm-lab
Copy link

klm-lab commented Apr 17, 2024

HI @helmut-jacob , I'm trying to reproduce the issue but the test is passed on my side.
Screenshot from 2024-04-17 16-08-15

@helmut-jacob
Copy link
Author

helmut-jacob commented Apr 17, 2024

Thanks @klm-lab for trying! Could this issue depend on the environment (browser, Node?) ...

I've noticed the issue in application code and worked around it by converting to UTC before adding. The code above was the smallest reproducer I could come up with (for now) which fails in my environment.

@klm-lab
Copy link

klm-lab commented Apr 17, 2024

@helmut-jacob Maybe this issue depend on the environment.
I used latest node LTS version for the test. Happy you find a workaround

@alwyntan
Copy link

alwyntan commented May 6, 2024

Having the same problem here :(

I'm working with recurrences so using local time is important, and it messes up in daylight savings.

Here's some code to illustrate:

const startLocal = dayjs.tz('2020-03-04 05:00:00', 'America/New_York')

console.log(startLocal.format('ddd, DD MMM YYYY, h:mma z'))
console.log(startLocal.add(1, 'week').format('ddd, DD MMM YYYY, h:mma z'))
console.log(startLocal.add(1, 'week').utc().format('ddd, DD MMM YYYY, h:mma z')) // wrong
console.log(startLocal.add(1, 'week').toISOString()) // wrong

These print out the following:

Wed, 04 Mar 2020, 5:00am EST
Wed, 11 Mar 2020, 5:00am EDT
Wed, 11 Mar 2020, 10:00am GMT
2020-03-11T10:00:00.000Z

The first two print statements are correct, which 5am is expected when adding 1 week in local time, changing EST to EDT. (Daylight savings occur on March 8 in 2020)

However, the last two statements are incorrect. 5:00am EDT should convert to 9:00am GMT, not 10:00am. The toISOString() for the EDT time also prints out incorrectly, where the EDT offset is -4, not -5.

But, when add is not used (eg. manually setting the times). It works as expected.

console.log(
  dayjs
    .tz('2020-03-09 05:00:00', 'America/New_York')
    .utc()
    .format('ddd, DD MMM YYYY, h:mma z')
)

// Mon, 09 Mar 2020, 9:00am GMT

Appreciate any pointers if anyone is facing the same problem.

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

No branches or pull requests

3 participants