supabase / supabase-swift / 37304631959

96%

Build Type

push

github

Committed by web-flow

Commit Message

fix(helpers): parse Postgres timestamp offsets instead of dropping them (#1427)

* fix(helpers): parse Postgres timestamp offsets instead of dropping them

`String.date` built its `Date.ISO8601FormatStyle` from `.year().month().day()...`
without ever calling `.timeZone(...)`, so a trailing UTC offset (`+02:00`, `Z`,
`+0200`, `+02`) was syntactically tolerated but never applied, silently
shifting every non-UTC `timestamptz` to UTC. Try an offset-aware format first
(accepts all of those offset spellings), falling back to the existing
zone-less format (read as UTC) for `timestamp` columns.

* fix(helpers): parse the timestamptz offset manually instead of via ISO8601FormatStyle

ISO8601FormatStyle's offset parsing (+02:00/+0200/+02/Z) is lenient on some
Foundation versions and not others. CI's legacy Xcode 26.0 job rejected one of
the offset spellings that newer toolchains (26.4) accept, failing the
DateFormatterTests.parsesOffset parameterized test added in the parent commit.

Parse the offset ourselves with plain string slicing instead, which behaves
identically across Foundation versions, and apply it arithmetically after
parsing the offset-less timestamp body.

* fix(helpers): normalize the offset spelling instead of hand-computing it

The previous fix parsed the UTC offset manually and applied it with
addingTimeInterval, duplicating what Date.ISO8601FormatStyle already does.
Narrow it down to what's actually version-sensitive: only the abbreviated
offset spellings (+0200, +02, Z) are parsed leniently on some Foundation
versions and not others (SDK-2090's CI caught this on the legacy Xcode 26.0
toolchain); the canonical +HH:MM colon form parses, and has its offset
applied, consistently everywhere, including in the PR's own first test case.

So rewrite the offset text into that canonical form and hand the whole
timestamp back to Date.ISO8601FormatStyle(timeZone: .colon) — Foundation
still does all the actual date parsing and offset arithmetic.

Coverage Stats

21 of 22 new or added lines in 1 file covered. (95.45%)

3 existing lines in 1 file now uncovered.

10537 of 11728 relevant lines covered (89.84%)

114.15 hits per line