dayjs: `dayjs.tz()` is building dates with incorrect timezone for many cases

On version 1.11.7, specifying timezone has no effect. I’m only getting the local time.

I was about to file a bug regarding dayjs.tz and found this one which seems related. The issue is that the function is not converting correctly between timezones. Simplest case to see is when converting to the same timezone is leading to the time to be changed!

Example:

dayjs.tz('2022-02-21 22:00', 'YYYY-MM-DD HH:mm', 'Europe/Paris').toISOString()
=> '2022-02-21T21:00:00.000Z'
dayjs.tz('2022-02-21 22:00', 'YYYY-MM-DD HH:mm', 'Europe/Paris').tz('Europe/Paris').toISOString()
=> '2022-02-21T22:00:00.000Z'

It seems to be applying the offset of the target timezone without taking into consideration the timezone of the original date!

It seems that dayjs can not handle the timezone with the format of Etc/GMT+8, you can get a barely correct result using this timezone format, but a correct result using the format Asia/Shanghai.

Here is my test case:

const originalDate = dayjs('2024-01-18T12:34:56');

// GMT-8 is actually GMT+8, 2024-01-18 12:34:56
console.log(originalDate.utc().tz('Etc/GMT-8').format('YYYY-MM-DD HH:mm:ss'));

// UTC standard time, correct
console.log(originalDate.utc().tz('Etc/GMT+0').format('YYYY-MM-DD HH:mm:ss')); 

// 2024-01-17 20:34:56, I have no idea what is going on here
console.log(originalDate.utc().tz('Etc/GMT+8').format('YYYY-MM-DD HH:mm:ss'));

It turns out that the Etc/ prefix would make the meaning of the whole timezone to be completely opposite than the original meaning.

For example, the Etc/GMT-8 is identical to GMT+8, and Etc/GMT+2 is the same as GMT-2 alone.

So the problem is not with dayjs, but my misunderstanding of the IANA timezone standard, although it’s a little counter intuitive.

Leaving a message here in case of people may run into the same problem like me.

To date, I get the same result 2022-02-21T21:00:00.000Z in both cases dayjs: 1.11.5 macOS NodeJS: 16.13.1

I’ve got the same.

In my case, release 1.11.2 solved my problem.

This is a sandbox that reproduces the timezone not affecting the date: https://codesandbox.io/s/dayjs-business-time-forked-b7opew

It seems to be related to the extra offset created by Summer Time.

The switch to summer time occurred March 27th at 2AM in Paris and I got these results on an instance based in Paris:

console.log(dayjs("2022-03-27T20:00:00.000Z").tz("Europe/Paris").toISOString())
> 2022-03-27T20:00:00.000Z
console.log(dayjs("2022-03-25T20:00:00.000Z").tz("Europe/Paris").toISOString())
> 2022-03-25T21:00:00.000Z

It looks like the lib is using the current offset of the instance timezone (UTC+2 at the execution time) instead of the real one at this date.

Let me contribute my tests:

console.log(
  [
    // ✔️ "2022-10-30T02:00:00+02:00"
    dayjs.utc("2022-10-30 00:00").tz("Europe/Berlin"),

    // ❌ "2022-10-30T02:00:00Z"
    // ➡️ "2022-10-30T02:00:00+01:00" would be correct (duplicate local hour because of DST).
    dayjs.utc("2022-10-30 01:00").tz("Europe/Berlin"),
    dayjs.utc("2022-10-30 00:00").add(1, "h").tz("Europe/Berlin"),

    // ✔️ "2022-10-30T03:00:00+01:00"
    dayjs.utc("2022-10-30 02:00").tz("Europe/Berlin"),
    dayjs.utc("2022-10-30 00:00").add(2, "h").tz("Europe/Berlin"),

    // With add()/subtract() on IANA object, you never get out of the wrong timezone.
    // ❌ "2022-11-03T05:00:00+02:00" (add())
    // ❌ "2022-10-26T04:00:00+01:00" (subtract())
    dayjs.utc("2022-10-30 00:00").tz("Europe/Berlin").add(100, "h"),
    dayjs.utc("2022-10-30 06:00").tz("Europe/Berlin").subtract(100, "h"),

    // BTW: When add(), subtract() etc. are patched, this should return "2022-03-27T03:00:00+02:00" (missing local hour because of DST).
    dayjs.tz("2022-03-27 01:00", "Europe/Berlin").add(1, "h"),
  ].map((d) => d.format())
);

This also touches #1816.