GeezerVison

What

getTimezoneAbbreviation decides between the standard and daylight label by comparing formatted strings:

const isDSTObserved = januaryFormatter.format(januaryDate) !== julyFormatter.format(julyDate)
...
const isDST = currentFormatter.format(date) !== januaryFormatter.format(januaryDate)

format() also renders the calendar date, which always differs between two dates, so for every zone in the map isDSTObserved was true and isDST was true too — the daylight label was returned all year:

getTimezoneAbbreviation('America/Los_Angeles', new Date('2026-01-15T12:00:00Z')) // 'PDT'
getTimezoneAbbreviation('Europe/London',        new Date('2026-01-15T12:00:00Z')) // 'BST'
getTimezoneAbbreviation('Australia/Sydney',     new Date('2026-07-15T12:00:00Z')) // 'AEDT'
formatDateTime(new Date('2026-01-15T12:00:00Z'), 'America/Los_Angeles')
// 'Jan 15, 2026, 4:00 AM PDT' — the local time is PST

Fix

Compare the zone's UTC offsets at the two ends of the year instead of formatted strings (getOffsetMinutes, derived from Intl.formatToParts, since Date has no timezone-aware offset accessor):

• equal offsets → the zone does not observe DST → the standard label;
• otherwise the smaller offset is standard time, and a larger offset on the target date means daylight time. Daylight time moves the clock forward in both hemispheres, so Sydney and Los Angeles are handled by the same rule.

How it was checked

• packages/utils/src/formatting.test.ts gains four cases: winter/summer for northern zones, the inverted seasons for Australia/Sydney, and zones without DST (Asia/Tokyo, Asia/Singapore).
• The same 13 zone/date expectations were executed on Node 22 against the patched logic: all hold (PST/PDT, GMT/BST, CET/CEST, EST/EDT, AEDT/AEST, JST, SGT).
• tsc --noEmit --skipLibCheck on the patched file passes.

Fixes #9831. Prepared with an AI coding assistant; I reviewed the diff and ran the checks above.