Time zone converter for dates, UTC and local time

A call at 9 AM, a flight arrival or a server log entry only makes sense when you know its time zone. Convert a date and time between cities to find the matching local hour, check whether the calendar date changes, and avoid confusion around daylight saving time.

Why time-zone conversion needs a date

An instant is one moment shared everywhere. Local time is how a place’s clock and calendar describe that moment. When it is late evening in New York, it may already be tomorrow in Tokyo. Converting the hour without the date can put an appointment on the wrong day.

The date also determines which time-zone rules apply. Paris and New York are usually six hours apart, but their daylight-saving changes happen on different dates. At noon UTC on January 15, 2026, their local times are 13:00 and 07:00. On March 15, 2026, they are 13:00 and 08:00: a five-hour difference.

This matters when scheduling international calls, comparing departure and arrival times, announcing a livestream, or matching an error report to a server log. A birthday or other date-only value is different: it is a calendar date, not an instant that should shift when viewed from another country.

UTC offsets, GMT and named time zones

UTC is the common reference for expressing an instant. An offset such as UTC+05:45 means the local clock is five hours and 45 minutes ahead of UTC. Offsets are not always whole hours.

A named time zone, such as Europe/Paris or America/New_York, supplies rules for finding the offset on a particular date. A fixed offset such as +01:00 does not describe future clock changes. Prefer named zones for appointments tied to a place; abbreviations such as CST can refer to different regions. The IANA Time Zone Database  maintains the rules used by many operating systems and programming languages.

For ordinary civil-time conversion, GMT and UTC both indicate a zero offset. That does not mean London uses a zero offset all year: use Europe/London when you mean local London time, including its summer changes.

The same instant can have different calendar dates

These readings all represent January 15, 2026 at 23:30 UTC:

In a 12-hour clock, midnight is 12 AM and noon is 12 PM. In a 24-hour clock, they are 00:00 and 12:00. Changing the display format does not change the instant or time zone.

Daylight saving: missing and repeated hours

When clocks move forward, some local times never happen. In America/New_York, March 8, 2026 at 02:30 is skipped. When clocks move back, an hour can occur twice: November 1, 2026 at 01:30 in the same zone can mean either 05:30 UTC or 06:30 UTC. A local date, time and zone therefore do not always identify exactly one instant.

For a repeated time, specify which occurrence you mean or include its UTC offset. For a skipped time, choose a valid local time. Adding 24 elapsed hours can also produce a different clock time tomorrow; a recurring 9 AM appointment should retain its local time and named zone. Keep time-zone data updated, since governments can change future rules.

Convert time zones in JavaScript

Start with an unambiguous timestamp containing Z for UTC or an explicit offset. A JavaScript Date represents the instant; Intl.DateTimeFormat displays it in a chosen zone without changing it:

const instant = new Date("2026-01-15T23:30:00Z");
const formatter = new Intl.DateTimeFormat("en-GB", {
  timeZone: "Asia/Tokyo",
  year: "numeric", month: "2-digit", day: "2-digit",
  hour: "2-digit", minute: "2-digit", second: "2-digit",
  hourCycle: "h23"
});

console.log(formatter.format(instant)); // 16/01/2026, 08:30:00
console.log(instant.toISOString());     // 2026-01-15T23:30:00.000Z
console.log(instant.getTime());         // Unix milliseconds: 1768519800000
console.log(instant.getTime() / 1000);  // Unix seconds: 1768519800

Do not manually add Tokyo’s offset to the timestamp: that changes the instant. Do not parse a localized display string back into a Date either. A date-time string without an offset can use the runtime’s local zone, and Intl.DateTimeFormat formats instants rather than resolving arbitrary local date/time input. See the MDN references for Date  and Intl.DateTimeFormat .

Convert time zones in Python

Python 3.9 and later includes zoneinfo. Use a timezone-aware datetime, then call astimezone() to express the same instant elsewhere:

from datetime import datetime
from zoneinfo import ZoneInfo

instant = datetime.fromisoformat("2026-01-15T23:30:00+00:00")
tokyo = instant.astimezone(ZoneInfo("Asia/Tokyo"))
new_york = instant.astimezone(ZoneInfo("America/New_York"))

print(tokyo.isoformat())     # 2026-01-16T08:30:00+09:00
print(new_york.isoformat())  # 2026-01-15T18:30:00-05:00

zoneinfo needs system time-zone data or the tzdata package, which is particularly relevant on Windows. When accepting local input, validate skipped times and resolve repeated ones explicitly; attaching a zone alone does not validate a nonexistent local time. Python’s fold attribute distinguishes the two occurrences of a repeated time. The official zoneinfo documentation  explains these behaviors and data requirements.

Store timestamps without losing their meaning

For logs and completed events, keep an unambiguous instant, commonly in UTC, and convert it for display. For future local schedules, also keep the named zone and intended local date/time. An offset alone cannot preserve a recurring local schedule when the rules change.

Use an explicit interchange format such as 2026-01-15T23:30:00Z, rather than a locale-dependent string such as 01/02/2026 09:00. RFC 3339  defines an Internet timestamp format based on ISO 8601. If an API uses Unix timestamps, check whether it expects seconds or milliseconds; JavaScript’s getTime() returns milliseconds.

To measure how long code takes, use an elapsed-time clock instead of converting calendar dates. Our explanation of JavaScript performance timing covers that distinction.