[BUG] Timezone formatter labels winter dates with daylight-time abbreviations #9831

Describe the bug

The shared timezone formatter labels winter dates with daylight-time abbreviations. This reaches formatDateTime(), producing internally inconsistent timestamps such as Jan 15, 2026, 4:00 AM PDT for Los Angeles (which is on PST).

To reproduce

At staging commit 61843fe8d15a504a734125706c97c91db975cd29, run with Bun:

import { getTimezoneAbbreviation, formatDateTime } from './packages/utils/src/formatting.ts'

const winter = new Date('2026-01-15T12:00:00Z')
console.log(getTimezoneAbbreviation('America/Los_Angeles', winter))
console.log(formatDateTime(winter, 'America/Los_Angeles'))
console.log(getTimezoneAbbreviation('Europe/London', winter))
console.log(getTimezoneAbbreviation('Australia/Sydney', new Date('2026-07-15T12:00:00Z')))

Actual output: PDT, Jan 15, 2026, 4:00 AM PDT, BST, AEDT.

Expected abbreviations: PST, PST in the formatted timestamp, GMT, and AEST, respectively.

Cause

In packages/utils/src/formatting.ts, isDSTObserved and isDST compare the entire result of Intl.DateTimeFormat.format(), including the calendar date. January 15 differs from January 1 even when their timezone offsets are identical. A January baseline also needs special care for southern-hemisphere zones.

Validation

Ran the real exported functions with Bun 1.3.14 on Windows, covering January and July for Los Angeles, London, Sydney, and Tokyo. The numeric local time is correct; the appended abbreviation is wrong in the cases above. No model/API credentials or running app are needed.

Searched existing issues and open PRs for getTimezoneAbbreviation, timezone abbreviations and DST before filing. Suggested label: bug.

AI assistance: this source investigation and local reproduction were prepared with an AI coding assistant.