Why is my database returning the wrong local time for America/Vancouver, America/Edmonton or Africa/Casablanca?

Queries that convert a timestamp to local time in America/Vancouver, America/Edmonton or Africa/Casablanca can return incorrect results on some Supabase Postgres versions. No error is raised. The database returns a local time that differs from the real local time in that zone.

Your stored data is not affected, and timestamps stay intact. Only the conversion to local time for the affected zones is wrong.

Overview

What is happening

Some older Supabase Postgres versions ship an outdated tzdata package. Postgres uses tzdata to decide the rules for each time zone. The following 2026 time zone changes are affected:

• British Columbia, Canada (America/Vancouver): changed on March 8, 2026.
• Morocco (Africa/Casablanca): changed on September 20, 2026.
• Alberta, Canada (America/Edmonton): changes on November 1, 2026.

On affected versions, local-time conversions for these zones, for example AT TIME ZONE 'America/Vancouver', return incorrect results until you upgrade. This includes the Alberta change on November 1, 2026.

Which projects are affected

Projects on a version lower than 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17). To check your version, open your project’s Service Version settings under Project Settings > General.

Diagnose the problem

Option 1: Check your project version

1. Open Project Settings > General in the Supabase Dashboard.
2. Look at Service Version.
3. If you are on a version earlier than 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17), and you use one of the affected time zones, your project is affected.

Option 2: Compare a conversion with the real local time

Run the following SQL using the SQL Editor in the Supabase Dashboard. Replace the time zone with one that you use.

1
select now() at time zone 'America/Vancouver' as database_local_time;

Compare the result with the actual current local time in that zone. If they differ, the project is returning incorrect local times for that zone.

Option 3: Contact support

If you are unsure whether your project is affected, open a support ticket and include your project reference.

Find indexes that may hold old values

Only indexes whose definition converts to one of the affected time zones are at risk. An example is ((col AT TIME ZONE 'America/Vancouver')::date). These indexes may hold values computed with the old rules. Indexes on plain columns, including plain timestamptz columns, are not affected, so you do not need to reindex everything.

To list candidates, run:

1
select schemaname, tablename, indexname, indexdef
2
from pg_indexes
3
where indexdef ilike '%at time zone%'
4
   or indexdef ilike '%America/Vancouver%'
5
   or indexdef ilike '%America/Edmonton%'
6
   or indexdef ilike '%Africa/Casablanca%';

If the query returns no rows, you have no indexes to rebuild.

Solve the problem

Step 1: Upgrade your project

If you use any of the zones above, upgrade your project to the latest version from Project Settings > General > Service Version. The new versions include the updated tzdata package.

The upgrade causes downtime, so plan it for a low-traffic window. See the upgrade guide for details.

Step 2: Rebuild affected indexes

After you upgrade, rebuild each index returned by the query above. This does not block reads or writes:

1
reindex index concurrently public.your_timezone_index;

If you skip this step, queries that use those indexes can return results based on the old rules until the indexes are rebuilt.

Confirm the problem is solved

1. In Project Settings > General, check that Service Version shows 15.19.0.003 (Postgres 15) or 17.11.0.003 (Postgres 17), or a later version.
2. Run the comparison query from Option 2 again and check that the result matches the actual local time.
3. Re-run the index query and confirm that every matching index has been rebuilt.

Related topics

• Upgrading