Skip to content
seekvero
EN / KR

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

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]

Close-up of servers in a rack, representing database infrastructure
Concept photo: servers in a rack, standing for the database infrastructure this fix applies to. Photo by Abigor via Wikimedia Commons, cropped/resized by SeekVero. Licensed under CC BY-SA 3.0; that licence covers the photo only, not the article text. Photo: Abigor, CC BY-SA 3.0, via Wikimedia Commons. Photo source · License

SeekVero editorial · Published · Prepared with AI assistance; no hands-on testing claimed.

Prepared from cited sources. No hands-on testing claimed.

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]

Next step

It has the exact diagnostic SQL query and reindex command in Supabase's own words.

Read Supabase's knowledge base article

Product demos and reference material

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
Cite this SeekVero guide

Keep the source credit and original evidence links with your summary. This example does not grant additional reuse rights.

Markdown

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

HTML

Source: <a href="https://seekvero.com/en/guides/supabase-postgres-timezone-fix">SeekVero — Supabase Fixes a Postgres Timezone Bug for Vancouver, Edmonton and Casablanca</a>

Agent access and optional source-link measurement