How to Convert UTC to Local Time in Excel, Google Sheets, JavaScript, and SQL

UTC timestamps are common in logs, APIs, databases, monitoring tools, CSV exports, and cloud dashboards. They are also common in the tiny moment of despair when someone asks, “What time was that locally?”

The short answer: if the target zone is a fixed offset like Japan Standard Time, add the offset. If the target zone has daylight saving time, use a real time zone name and a tool or API that knows the date rules.

First, decide whether an offset is enough

There are two different problems hiding behind “convert UTC to local time.”

Use the Time Zone Converter when you want to confirm a specific date, especially around daylight saving time changes.

Excel: convert UTC to JST

If cell A2 contains a real Excel date-time value in UTC, Japan time is:

=A2 + 9/24

You can also write it more explicitly:

=A2 + TIME(9,0,0)

Format the result cell as a date-time value. The formula works for JST because JST is a fixed UTC+9 offset.

Google Sheets: convert UTC to JST

Google Sheets uses the same basic date arithmetic:

=A2 + 9/24

For a visible label:

=TEXT(A2 + 9/24, "yyyy-mm-dd hh:mm")

That is fine for UTC to Japan time. Do not reuse the same pattern for New York, London, or Los Angeles unless you are deliberately using a fixed offset and accepting daylight saving mistakes.

Spreadsheet warning: fixed offsets are not cities

UTC-5 and America/New_York are not the same thing. New York uses UTC-5 during standard time and UTC-4 during daylight time. A spreadsheet formula like =A2-5/24 will be wrong for many dates.

For messy real-world zones, either use a trusted converter for individual timestamps or move the conversion into code or a database that supports named time zones. Calendars, like bureaucracy, punish optimism.

JavaScript: use Intl for display

For display, JavaScript’s Intl.DateTimeFormat can format a UTC instant in a named IANA time zone:

const utcInstant = new Date("2026-05-17T15:00:00Z");

const formatter = new Intl.DateTimeFormat("en-US", {
  timeZone: "Asia/Tokyo",
  dateStyle: "medium",
  timeStyle: "short",
});

console.log(formatter.format(utcInstant));

To show New York time, change the time zone:

const formatter = new Intl.DateTimeFormat("en-US", {
  timeZone: "America/New_York",
  dateStyle: "medium",
  timeStyle: "short",
});

This is better than manually subtracting 4 or 5 hours because the offset depends on the date.

JavaScript warning: Date does not store a time zone

A JavaScript Date represents an instant in time. It does not store America/New_York, Asia/Tokyo, or any other named zone inside the object.

This means:

• Parse UTC with an explicit Z, such as 2026-05-17T15:00:00Z.
• Use Intl.DateTimeFormat to display that instant in a target zone.
• Avoid parsing vague strings like 2026-05-17 15:00 unless you know which local time zone the runtime will assume.

SQL: use named zones when the database supports them

SQL syntax varies by database. The principle is the same: store or parse the value as UTC, then convert it for display.

PostgreSQL example:

SELECT TIMESTAMPTZ '2026-05-17 15:00:00+00'
  AT TIME ZONE 'Asia/Tokyo';

MySQL fixed-offset example:

SELECT CONVERT_TZ('2026-05-17 15:00:00', '+00:00', '+09:00');

MySQL can also use named time zones, but only when the server’s time zone tables are loaded and maintained. That is exactly the sort of operational footnote that turns “just convert the time” into a small systems design meeting.

SQL Server example:

SELECT CONVERT(datetime2, '2026-05-17T15:00:00Z')
  AT TIME ZONE 'UTC'
  AT TIME ZONE 'Tokyo Standard Time';

SQL Server uses Windows time zone names, not IANA names.

Snowflake and data warehouses

Snowflake has CONVERT_TIMEZONE:

SELECT CONVERT_TIMEZONE(
  'UTC',
  'Asia/Tokyo',
  '2026-05-17 15:00:00'::timestamp_ntz
);

For BigQuery, keep the value as a TIMESTAMP and format it in the target zone:

SELECT FORMAT_TIMESTAMP(
  '%F %R',
  TIMESTAMP '2026-05-17 15:00:00+00',
  'Asia/Tokyo'
);

The exact function differs, but the boring rule survives: use named time zones when daylight saving time matters.

UTC to JST quick reference

JST is UTC+9, so:

For a full 24-hour table, use the compact UTC ↔ JST chart in the Time Zone Converter.

Common mistakes

• Adding a fixed offset for a daylight-saving region.
• Treating PST as current Pacific Time. PST is fixed UTC-8; Pacific local time may be PDT.
• Treating EST as current Eastern Time. EST is fixed UTC-5; Eastern local time may be EDT.
• Forgetting the next-day or previous-day marker.
• Parsing a timestamp without Z and accidentally using the computer’s local time zone.
• Mixing display conversion with storage. Store UTC; convert for humans.

A practical workflow

1. Store timestamps in UTC.
2. Decide whether the target is a fixed offset or a real location.
3. For fixed offsets like JST, simple addition is usually enough.
4. For cities with daylight saving time, use IANA time zones or a database-supported equivalent.
5. Check edge cases with the Time Zone Converter, especially around March and November for US zones and March and October for many European zones.

FAQ

Is UTC the same as GMT?

For everyday conversion, UTC and GMT often produce the same clock time. Technically they are not the same standard, and software systems usually use UTC.

Can I convert UTC to JST by adding 9 hours?

Yes, for current Japan time rules. Japan uses JST, which is UTC+9 year-round.

Can I convert UTC to New York by subtracting 5 hours?

Only for dates when New York is on standard time. During daylight saving time, New York is UTC-4. Use America/New_York when the date matters.

What does 1500Z mean?

1500Z means 15:00 UTC. The Z stands for Zulu time, a common operational way to write UTC.

Should I store local time or UTC?

For most logs, APIs, events, and database records, store UTC and convert to local time only for display. Local time is what humans read; UTC is what systems survive on.