fix(timezone): compute instance .tz() offset without host DST

[Moumouls]

Summary

Fixes incorrect timezone offsets when converting an instant with instance .tz() on a host that observes DST.

This is the minimal follow-up to #3169, as requested by @iamkun: only the original tzOffset() change in proto.tz, no wall-clock / set / add / startOf refactor.

Bug: America/Guadeloupe is a fixed UTC−4 zone (no DST). On hosts such as Europe/Paris or Europe/London, around the EU spring-forward Sunday, dayjs(instant).tz('America/Guadeloupe') could report −03:00 instead of −04:00. Adding one day and converting again could then land on the same calendar day. The same host-DST leak also affects DST-observing target zones when their calendar is out of sync with the host (US vs EU mid-March / late October, southern-hemisphere summer).

Root cause: proto.tz derived the offset from:

const target = date.toLocaleString('en-US', { timeZone })
const diff = Math.round((date - new Date(target)) / 1000 / 60)
const offset = (-Math.round(date.getTimezoneOffset() / 15) * 15) - diff

Both new Date(target) and getTimezoneOffset() depend on the host timezone.

The static helper dayjs.tz(string, zone) already used tzOffset via Intl.DateTimeFormat#formatToParts (host-independent). Instance .tz() did not.

Fix: reuse the existing tzOffset(+date, timezone) helper in proto.tz for the offset. Keep wall-clock construction via toLocaleString and the rest of the method unchanged (utcOffset, keepLocalTime, $timezone). No changes to the utc plugin or core parse/$set.

Related: #1260
Follow-up: #3169 (calendar arithmetic set / add / startOf on zoned instances)

Tests added

• Fixed-offset America/Guadeloupe around EU spring DST (offset −240, moment parity, +1 calendar day)
• DST-observing target zones across host DST (NY/Paris mid-March and late-October desync, Sydney southern summer)
• keepLocalTime between DST-desynced zones (NY → Paris)
• Conversion/parse cases that pass without the later refactor: fall-back overlap, distinct 01:30 instants, host fall-back conversion, Lord Howe 30-minute DST, London winter UTC+0, host-local keepLocalTime, quarter-hour / date-line offsets, diff across target DST

Host matrix for test-tz-plugin: Europe/Paris, Europe/London, America/New_York, Pacific/Auckland.

Calendar-arithmetic DST cases (startOf / set / add / host spring-forward gap via instance .tz()) stay in #3169.

Test plan

• TZ=Europe/Paris npm run test-tz-plugin
• TZ=Europe/London npm run test-tz-plugin
• TZ=America/New_York npm run test-tz-plugin
• TZ=Pacific/Auckland npm run test-tz-plugin

Credits

This PR was prepared with Cursor and assistance from Grok 4.5 High.

[Moumouls]

@iamkun we should be good to go so here

[Moumouls]

One test from #3169 is intentionally not in this PR: keepLocalTime when converting UTC → America/Guadeloupe around the EU spring-forward Sunday (2050-03-27).

That case still fails without the later refactor. proto.tz now uses tzOffset() for the offset, but the wall-clock string still comes from toLocaleString and is then parsed as host local time. On Europe/Paris / Europe/London, that hour is skipped, so keepLocalTime: true lands on 05:00 instead of 04:00.

[iamkun]

LGTM, THX

[github-actions]

🎉 This PR is included in version 1.11.22 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀