UTC to PST in SQL
Convert a UTC timestamp column to US Pacific Time at query time, in Redshift. All UTC stays the source of truth in the table — conversion happens only when you read it.
Use this live converter to sanity-check a single value before writing the query.
Example table
These examples assume a table storing timestamps in UTC, which is the recommended practice for any database.
| Cell | Contains |
|---|---|
| id | Order ID |
| created_at_utc | Timestamp stored in UTC |
| customer_name | Text |
Conversion query by engine
The keyword research shows real search demand for UTC to PST in SQL, but only Redshift specifically — not MySQL, SQL Server, Oracle or BigQuery. Rather than manufacture examples for engines nobody searched for, this page covers Redshift directly and applies the same IANA-timezone-name principle used on the IST and EST SQL pages, which carries over to any engine with named-timezone support.
Redshift
SELECT
order_id,
created_at_utc,
CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', created_at_utc) AS created_at_pst
FROM orders;
Automatically adjusts for PST/PDT because 'America/Los_Angeles' is a named IANA zone, not a fixed offset.
Daylight saving
2026 transition dates: US clocks move to daylight time on March 8, 2026 and back to standard time on November 1, 2026. A timestamp column spans both periods over a year, so a single fixed offset (e.g. always subtracting 5 or 8 hours) will be wrong for roughly half the calendar. Every engine above uses a named time zone specifically so it resolves the correct offset per row automatically — that's the recommended approach over manual offset arithmetic in SQL.
Worked example
PST, standard time:
| Cell | Contains |
|---|---|
| created_at_utc | 2026-01-15 23:00:00 |
| created_at_pst | 2026-01-15 15:00:00 |
PDT, daylight time:
| Cell | Contains |
|---|---|
| created_at_utc | 2026-07-15 23:00:00 |
| created_at_pst | 2026-07-15 16:00:00 |
Date rollover example
A conversion that crosses midnight correctly shows the new calendar date — every engine above operates on the full timestamp, not just the time portion.
| Cell | Contains |
|---|---|
| created_at_utc | 2026-01-16 03:00:00 (UTC) |
| created_at_pst | 2026-01-15 19:00:00 (PST) |
Filtering by local time — a common mistake
Converting the column inside a WHERE clause forces the database to evaluate every row before it can compare, which defeats any index on the UTC column. Convert the boundary value instead and filter the raw column.
SELECT * FROM orders
WHERE CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', created_at_utc) >= '2026-01-15 00:00:00';
SELECT * FROM orders
WHERE created_at_utc >= CONVERT_TIMEZONE('America/Los_Angeles', 'UTC', '2026-01-15 00:00:00');
Common mistakes
- Hardcoding a fixed -8-hour offset as if it applies year-round — it's only correct for part of the year; the other part needs -7 hours.
- Filtering directly on a converted expression (see below) instead of converting the comparison boundary — this prevents the database from using an index on the UTC column.
- Converting to PST before storing the value back in the table — store UTC as the single source of truth and convert only at query/display time.
UTC vs. local timestamps
Store every timestamp in UTC. It's unambiguous, sorts correctly, and never needs to be re-interpreted when daylight saving changes. Convert to PST only in the query that displays the value to a user — as shown above — never in the write path.
Related tools
Frequently asked questions
Use a timezone-aware function in your database engine — for example in Redshift: CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', created_at_utc) AS created_at_pst
It depends on your database engine — this page covers Redshift, each with verified syntax.
Only if you use a named IANA time zone (e.g. 'America/Los_Angeles') rather than a fixed offset. Every function shown on this page does this correctly; a hardcoded -8-hour subtraction does not.