UTC to IST in SQL
Convert a UTC timestamp column to India Standard Time at query time, in MySQL / BigQuery / Oracle / 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
MySQL
SELECT
order_id,
created_at_utc,
CONVERT_TZ(created_at_utc, '+00:00', '+05:30') AS created_at_ist
FROM orders;
The fixed-offset form works with no setup. A named-zone form, CONVERT_TZ(created_at_utc, 'UTC', 'Asia/Kolkata'), also works once MySQL's time zone tables are loaded (mysql_tzinfo_to_sql) — with IST there's no daylight saving, so both forms always agree.
BigQuery
SELECT
order_id,
created_at_utc,
DATETIME(created_at_utc, 'Asia/Kolkata') AS created_at_ist
FROM `project.dataset.orders`;
DATETIME() takes an IANA zone name directly and needs no setup.
Oracle
SELECT
order_id,
created_at_utc,
FROM_TZ(CAST(created_at_utc AS TIMESTAMP), 'UTC') AT TIME ZONE 'Asia/Kolkata' AS created_at_ist
FROM orders;
FROM_TZ first labels the value as UTC; AT TIME ZONE then converts it — skipping the label step is the most common mistake with this function.
Redshift
SELECT
order_id,
created_at_utc,
CONVERT_TIMEZONE('UTC', 'Asia/Kolkata', created_at_utc) AS created_at_ist
FROM orders;
Source zone defaults to UTC if omitted; it's included here for clarity.
Daylight saving
India Standard Time does not observe daylight saving, so every query above returns a consistent offset year-round — there's no standard/daylight distinction to manage.
Worked example
| Cell | Contains |
|---|---|
| created_at_utc | 2026-09-17 12:00:00 |
| created_at_ist | 2026-09-17 17:30: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-09-17 23:00:00 (UTC) |
| created_at_ist | 2026-09-18 04:30:00 (IST) |
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_TZ(created_at_utc, '+00:00', '+05:30') >= '2026-09-17 00:00:00';
SELECT * FROM orders
WHERE created_at_utc >= CONVERT_TZ('2026-09-17 00:00:00', '+05:30', '+00:00');
Common mistakes
- Assuming IST observes daylight saving like the US time zones do — it never has, so any DST-handling logic applied to an IST column is unnecessary and can introduce bugs.
- 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 IST 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 IST 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 MySQL: CONVERT_TZ(created_at_utc, '+00:00', '+05:30') AS created_at_ist
It depends on your database engine — this page covers MySQL / BigQuery / Oracle / Redshift, each with verified syntax.
No — India Standard Time has a fixed UTC+5:30 offset year-round, so the queries above return a consistent result on every date.