DevKit
Converter

Timezone Converter

Convert a time across major world timezones with DST support.

Last updated: August 2026

UTC14 Oct 2026, 00:21
America/New_York13 Oct 2026, 20:21
America/Los_Angeles13 Oct 2026, 17:21
America/Chicago13 Oct 2026, 19:21
Europe/London14 Oct 2026, 01:21
Europe/Paris14 Oct 2026, 02:21
Europe/Berlin14 Oct 2026, 02:21
Asia/Jakarta14 Oct 2026, 07:21
Asia/Singapore14 Oct 2026, 08:21
Asia/Tokyo14 Oct 2026, 09:21
Asia/Shanghai14 Oct 2026, 08:21
Asia/Kolkata14 Oct 2026, 05:51
Asia/Dubai14 Oct 2026, 04:21
Australia/Sydney14 Oct 2026, 11:21

Enter a time in the source timezone; the table shows the same instant across zones. DST is handled by your browser's Intl engine.

Share:

Was this tool helpful?

Converting a time across zones

A timezone converter takes a single moment and shows what clock time it is in several places at once, accounting for each region's offset from UTC and whether daylight saving is currently in effect. The same instant is 15:00 in London, 10:00 in New York, and 22:00 in Jakarta; the tool keeps them aligned to one real moment.

When you reach for it

Scheduling a call across continents, picking a deploy window that avoids peak hours everywhere, reading a log timestamp in your own time, or confirming when a daylight saving change will shift a recurring meeting by an hour.

Example

Base: 2024-07-01 09:00  America/New_York (EDT, UTC-4)

Europe/London     14:00  (BST, UTC+1)
Asia/Jakarta      20:00  (WIB, UTC+7, no DST)
Australia/Sydney  23:00  (AEST, UTC+10)

Jakarta stays on a fixed offset year round, while New York and London shift with daylight saving, which is why the gap between them is not constant.

Common pitfalls

The big one is daylight saving transitions. The offset between two cities is not fixed; it changes when one observes DST and the other does not, or when they switch on different dates. For a few weeks each spring and fall the usual gap is off by an hour, which is exactly when scheduled meetings mysteriously move. A related trap is naming: a zone like America/New_York encodes the DST rules, while a raw offset like UTC-5 does not, so always store the IANA zone name, not just the current offset. Some regions, like most of Indonesia, never observe DST at all, which can mask the problem until you convert to one that does.

FAQ

Why did my recurring meeting move by an hour? One of the regions crossed a daylight saving boundary, changing the offset between you and them.

Should I store UTC or local time? Store UTC (or an IANA zone name plus the instant) and convert only when displaying, which avoids DST ambiguity.

Is UTC the same as GMT? For everyday purposes they match, though UTC is the precise standard and GMT is a time zone that some regions use with DST on top.