mirror of
https://github.com/supabase/supabase.git
synced 2026-10-19 16:19:10 +03:00
Jordi Enric
5b8f504ce3
## Problem Changing the restore date resets the entered time, and the repeated hour at the end of daylight saving time can resolve to the wrong occurrence. Both can change the submitted recovery timestamp. ## Fix Store the recovery point as a Unix timestamp and preserve its occurrence when editing an ambiguous local time. Calendar edits carry the entered hours, minutes, and seconds onto the selected day, applying that day's timezone offset and retaining the existing backup-range clamping. This focuses on date edits and repeated-hour handling from #48903. It changes only the PITR form, its utilities, and regression tests. Related to [FE-4129](https://linear.app/supabase/issue/FE-4129/r2np-datetime-widget). ## How to test - In PITR or restore-to-new-project, enter a time and select another available calendar day. Expected result: the entered hours, minutes, and seconds remain selected, and the submitted timestamp matches the new date. - Run the PITRForm and PITR.utils Vitest suites. Their fixtures cover both occurrences of the repeated Madrid/New York hour, edits across DST, spring-forward normalization, fractional offsets, and backup boundaries. - Twelve focused regression cases passed under a Madrid browser timezone. Those cases plus the existing selector component test passed under Hong Kong, thirteen tests total. All CI checks passed, including Studio tests, all four Next.js/TanStack E2E shards, typecheck, lint ratchet, formatting, spelling, unused-code checks, and Docker build.