Umami version: 2.19.0
Node/Next/Prisma: Next 15.3.3, Prisma 6.7.0
Deployment: Dokploy on a VPS (Docker)
Database: PostgreSQL ⟮version: e.g., 14/15/16⟯, database name postgres
Timezone setting: Provided by UI as Asia/Calcutta

Steps to reproduce:

• Configure timezone in Umami to Asia/Calcutta.
• Open dashboards that run time-bucketed queries (pageviews/sessions).
• Check server logs.

Actual result (logs):

⨯ Error [PrismaClientKnownRequestError]:
Invalid `prisma.$queryRawUnsafe()` invocation:
Raw query failed. Code: `22023`. Message: `ERROR: time zone "Asia/Calcutta" not recognized`

STATEMENT:
select
to_char(date_trunc('hour', website_event.created_at at time zone 'Asia/Calcutta'), 'YYYY-MM-DD HH24:00:00') x,
count(*) y
from website_event
where website_event.website_id = $1::uuid
and website_event.created_at between $2 and $3
and event_type = $4
group by 1
order by 1

Expected result:
Queries should work with common legacy aliases (or Umami should canonicalize them), producing hourly buckets without errors.

Why this happens:

• Asia/Calcutta is a legacy alias; the canonical IANA zone is Asia/Kolkata.
• Postgres relies on the OS tzdata. Minimal Docker images often don’t include legacy links, so AT TIME ZONE 'Asia/Calcutta' raises 22023.
• Umami currently forwards the raw timezone string into SQL (via Prisma $queryRawUnsafe) without canonicalization.

Impact:

• Any tenant/user picking Asia/Calcutta causes repeated 500s on analytics API routes (pageviews, sessions, etc.).

Database

PostgreSQL