mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 14:19:11 +03:00
## Problem Restore timezone labels use fixed UTC offsets from the timezone catalog. Madrid displays UTC+01:00 during daylight saving time even though the reported restore timestamp correctly uses UTC+02:00. ## Fix Calculate display offsets from the restore instant and the timezone's IANA identifier using Intl. Apply the same formatter to dropdown options, the selected timezone, and PITR confirmation while preserving existing restore calculations and timezone selection identity. Fixes https://linear.app/supabase/issue/FE-4612 ## How to test - Choose Madrid in restore-to-new-project or PITR and compare winter and summer restore dates. Expected result: UTC+01:00 in winter and UTC+02:00 during daylight saving time, including the confirmation label. - Check UTC, New York, Kolkata, and Kathmandu. Expected result: correct zero, negative, and fractional offsets. - Focused Vitest suite: 15 tests passed, including both Madrid DST boundaries and timestamp preservation. The component test verifies visible trigger and option labels update after a date change, Madrid search results, selection preserving the original timezone object, and popover closure. It also passes under UTC and Hong Kong browser timezones. Prettier and diff checks passed. - All CI checks passed for the latest commit, including Studio tests, all four Next.js/TanStack E2E shards, typecheck, lint ratchet, formatting, spelling, unused-code checks, and Docker build. Full local typecheck and ESLint validation were blocked by the shared dependency installation being out of sync with this checkout. Calculation audit confirmed the reported October 9 Madrid 05:12 to UTC 03:12 conversion. Separate existing date-control issues were found when browser and restore timezones differ and around the repeated autumn hour; those are outside this label fix and relevant to FE-4129. --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>