# Supabase Fixes a Postgres Timezone Bug for Vancouver, Edmonton and Casablanca

Canonical: https://seekvero.com/en/guides/supabase-postgres-timezone-fix
Published: 2026-11-03T18:04:16.549Z
Updated: 2026-11-03T18:04:16.549Z
Article SHA-256: bfd60cf1f544d5b02f32d09450ed3c3ad7517ce8437f78d2d6487e9423a122e9

Supabase's Oct 30, 2026 changelog fixes wrong local-time conversions for three zones on older Postgres versions. Who is affected and how to fix it.

SeekVero guides on AI tools and market changes: source-cited, prepared with AI assistance, no hands-on testing claimed.

These machine-readable copies do not grant additional reuse rights. Preserve the canonical article URL, original source references and uncertainty labels. Third-party images, quotations and brand assets retain their own rights.

Source: [SeekVero — Supabase Fixes a Postgres Timezone Bug for Vancouver, Edmonton and Casablanca](https://seekvero.com/en/guides/supabase-postgres-timezone-fix)

Some older Supabase Postgres versions ship an outdated tzdata package, so local-time conversions for America/Vancouver, America/Edmonton and Africa/Casablanca return the wrong time. The bug affects projects on a version earlier than 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17); those two versions include the fix. Supabase announced the fix on October 30, 2026. Stored data and timestamps are not affected — only the local-time conversion for these three zones is wrong until you upgrade. [1] [2]

## What's wrong, and why

Some older Supabase Postgres versions ship an outdated tzdata package. As a result, local-time conversions such as AT TIME ZONE 'America/Vancouver' return incorrect results for three zones that changed their time zone rules in 2026. [1]

The three affected zones: America/Vancouver (British Columbia, Canada) changed on March 8, 2026; Africa/Casablanca (Morocco) changed on September 20, 2026; America/Edmonton (Alberta, Canada) changes on November 1, 2026. [1]

Your stored data and timestamps are not affected. Only the conversion to local time for these three zones is wrong. [1] [2]

## Is your project affected?

The bug affects projects that use one of the three zones and run a Postgres version earlier than 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17). Those two versions include the updated tzdata package. [1]

To check, open Project Settings > General in the Supabase Dashboard and look at Service Version. You can also run a comparison query in the SQL Editor: select now() at time zone 'America/Vancouver' as database_local_time; — then compare the result with the real local time in that zone. [1] [2]

## How to fix it

Only indexes whose definition converts to one of the affected zones are at risk, for example an index on ((col AT TIME ZONE 'America/Vancouver')::date). Indexes on plain columns, including plain timestamptz columns, are not affected. [2]

1. Upgrade your project from Project Settings > General > Service Version to a version that includes the fix. The upgrade causes downtime, so plan it for a low-traffic window. [1]
2. Find indexes that may hold old values by running: select schemaname, tablename, indexname, indexdef from pg_indexes where indexdef ilike '%at time zone%' or indexdef ilike '%America/Vancouver%' or indexdef ilike '%America/Edmonton%' or indexdef ilike '%Africa/Casablanca%'; — if it returns no rows, there is nothing to rebuild. [2]
3. Rebuild each matching index with reindex index concurrently public.your_timezone_index; — this does not block reads or writes. [2]

## Frequently asked questions

### Is my stored data affected by this bug?
No. Your stored data and timestamps are not affected. Only the conversion to local time for America/Vancouver, America/Edmonton and Africa/Casablanca is wrong until you upgrade. [1] [2]

### Which Postgres versions are affected?
Versions earlier than 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17). Those two versions include the updated tzdata package that fixes it. [1]

### How do I check if my project is affected?
Check Service Version under Project Settings > General in the Supabase Dashboard, or run select now() at time zone 'America/Vancouver' as database_local_time; in the SQL Editor and compare it with the real local time. [2]

### When did Supabase publish this fix?
Supabase published the changelog entry for this fix on October 30, 2026. [1]

## Sources

[1] https://supabase.com/changelog/tzdata-local-time-vancouver-edmonton-casablanca
[2] https://supabase.com/kb/troubleshooting/wrong-local-time-for-vancouver-edmonton-casablanca-time-zones