Supabase Postgres fixes wrong local time for three timezones
An outdated tzdata package meant AT TIME ZONE conversions for Vancouver, Edmonton and Casablanca were wrong on older Postgres builds. Stored data is fine, only the conversion was off.
Supabase shipped a fix on 30 October for Postgres builds carrying an outdated tzdata package. Queries converting to local time with AT TIME ZONE for three zones, America/Vancouver, America/Edmonton and Africa/Casablanca, returned the wrong result on affected versions, because the underlying rules for those zones changed during 2026 and the bundled tzdata never caught up.
The fix lands in Postgres 15.19.0.003 and Postgres 17.11.0.003. Anything below those versions is affected if it uses one of the three zones; you can check your version under Project Settings > General > Service Version in the dashboard. Stored timestamps are untouched, only the local-time conversion was wrong, but Edmonton’s own rule change takes effect on 1 November, so projects still on an old version will start showing the wrong local time there from tomorrow if they haven’t upgraded. Supabase’s note warns the upgrade needs a low-traffic window, and any index built on a timezone conversion expression needs a REINDEX INDEX CONCURRENTLY afterwards.
Why it matters: this is the kind of bug that doesn’t throw an error, it just quietly shows the wrong time to anyone in one of those three zones. If you’re on Supabase and store or display times for users in Vancouver, Edmonton or Casablanca, this is worth checking today rather than after a support ticket.
The caveat: it only affects those three zones on the two specific version ranges above. If you’re already past 15.19.0.003 or 17.11.0.003, there’s nothing to do.