Timezone Converter

What it does

Timezone Converter takes a clock time in one zone and tells you what that same moment reads on the clock in another zone. You type a time in 24-hour HH:MM format, pick a From zone and a To zone, and the result updates as soon as the inputs are valid. There is no submit button and no date field. The math is pure offset arithmetic, so the answer comes out instantly and the page never talks to a server.

It is a quick lookup, not a full scheduling app. The thirteen zones in the dropdown cover the offsets most people actually need: UTC, the four US zones (EST, CST, MST, PST), the two European zones (CET, EET), Moscow (MSK), India (IST, UTC+5:30), China and Singapore (UTC+8), Japan (JST), eastern Australia (AEST), and New Zealand (NZST).

Who actually needs it

The people I see reach for a tool like this are usually doing one of four things:

• Working out when a meeting falls in their own clock time after someone proposes it in theirs.
• Reading a timestamp on a log line, an order confirmation, or a social-media post and wanting to know what that meant locally.
• Catching a live event (a stream, a game, a market open, a product launch) that was announced in a different zone.
• Sanity-checking a calendar invite that someone created on a laptop set to the wrong region.

For all of those, a fixed-offset converter is enough. If you need to schedule recurring meetings, share a clickable calendar link, or pick a slot that works for a whole team, the Meeting Time Planner is the right tool. If you only want to know how far apart two zones are right now, use Time Zone Difference.

How to use it

Three fields, no save step:

• Time (HH:MM) — type the source time in 24-hour format. 14:30 is 2:30 PM. 00:00 is midnight. There has to be a colon between the hours and the minutes, or nothing happens.
• From Timezone — the zone the time you just typed is currently in.
• To Timezone — the zone you want the answer in.

The Result card appears as soon as both numbers parse. It shows two things: the Converted Time in the same HH:MM format, with a (+1 day) or (-1 day) tag if the conversion crossed midnight, and a Time Difference badge that says how big the jump was — for example +17h, or -5h 30m for half-hour zones.

If you leave a dropdown alone without picking anything, it is treated as UTC+0. That is fine if you actually want UTC, but it is the most common cause of a surprising-looking result, so glance at both selects before you trust the number.

How the math actually works

The whole calculation is one line of arithmetic. The tool reads the source hour and minute, computes the difference between the two UTC offsets (diff = targetOffset − sourceOffset), and adds that difference to the source time. Everything is converted to minutes first:

totalMin = round(hours × 60 + minutes + diff × 60)

The reason it works in minutes is India. IST is UTC+5:30, so the offset is 5.5 hours. If you naively added 5.5 to the hour field and 0.5 × 60 = 30 to the minutes field, you would double-count the half hour and end up an hour off in one direction. By multiplying the offset by sixty up front and rolling everything into a single minute count, half-hour zones convert correctly going both ways. Math.round mops up any floating-point drift from multiplying 5.5 × 60.

Once it has a total minute count, the tool wraps it into the 0–1439 range for a 24-hour clock:

• If the total is 1440 or more, it subtracts 1440 and tags the result (+1 day).
• If it goes below zero, it adds 1440 and tags the result (-1 day).

The supported offsets span −8 to +12, so the largest possible jump is 20 hours, which is less than a full day. That means a conversion can cross at most one calendar boundary, and the single-day tag is always enough. There is no case where the tool would need to say (+2 days).

A worked example

Say a launch stream is announced for 14:30 PST and you live in Tokyo. Type 14:30 into the time field, set From to UTC-8 (PST), and set To to UTC+9 (JST).

• diff = 9 − (−8) = +17 hours.
• totalMin = 14 × 60 + 30 + 17 × 60 = 870 + 1020 = 1890.
• 1890 ≥ 1440, so subtract 1440 → 450, and tag (+1 day).
• 450 / 60 = 7 hours, remainder 30 → 07:30.

Result: 07:30 (+1 day), with a +17h difference badge. In plain English: 2:30 PM Pacific on a Tuesday is 7:30 AM Wednesday in Tokyo.

The big caveat: no Daylight Saving Time

The dropdown values are fixed standard-time offsets. There is no date input, and no logic that switches a region into summer time. For about half the year, that is fine. For the other half, you have to think for a second.

When a region is on DST its clocks usually run one hour ahead of the listed offset. A few practical examples:

• New York in summer is UTC-4 (EDT), not UTC-5 (EST). There is no UTC-4 entry in the dropdown. The honest workaround is to convert with EST (UTC-5) and then add one hour to the result.
• London in summer is UTC+1 (BST), not UTC+0. Pick the CET (UTC+1) entry for those months.
• India does not observe DST at all, so IST is always UTC+5:30 — that one is easy.
• Japan, China, and Singapore also do not observe DST.
• Australia is messy: AEST (UTC+10) becomes AEDT (UTC+11) in the southeastern states during their summer, while Queensland stays on UTC+10 year round.

DST start and end dates also vary by country and shift slightly from year to year. If a conversion lands within a week or two of a clock change, double-check the offset for that specific date before you book anything.

Common pitfalls

• AM/PM input. The parser only reads 24-hour time. Typing 2:30 PM will not work — type 14:30.
• Missing the colon. The input is split on : and discarded if there are fewer than two parts. 1430 on its own produces no result.
• Leaving a zone unchanged. A dropdown you haven't touched is treated as UTC+0. If your result looks like it is hours off in a suspiciously round way, that is usually why.
• Reading the day tag as part of the time. 07:30 (+1 day) is half-past seven the next morning, not seven thirty plus a day's worth of hours.
• Forgetting DST on the receiving end. The DST rule applies to both zones independently. If you are converting from a region on summer time to one on winter time, you have to account for both, not just the one you live in.

When not to use it

Reach for something else when:

• You need the answer for a specific calendar date and DST is in play. A tool with a date picker — or the time-zone support built into your calendar app — is safer.
• You are coordinating a meeting across three or more zones. The Meeting Time Planner shows everyone's working hours side by side, which is what you actually want.
• You are working with historical timestamps from before a country's current offset rules. Several countries have shifted offset within the last decade (Samoa, Russia, Turkey), and a fixed-offset tool won't reflect those changes.
• You need a clickable, shareable result. There is no permalink — the inputs live in component state, not the URL.

If the result looks wrong

Run through this checklist before you blame the tool:

• Is the From zone really the zone the source time is in, or did you set it to your own zone by reflex?
• Are either of the regions on DST today? If yes, add or subtract an hour to match the seasonal offset.
• Is the source time written in 24-hour form? 3:00 for a 3 PM meeting will be read as 3 AM.
• Does the day tag make sense for the direction of travel? Going east (positive difference) can push you into tomorrow; going west far enough can pull you back to yesterday.

If all four check out and the answer still feels off, do a quick mental sanity check: count the raw hour gap between the two zones, add it to the source time, and see if you land on the same minute. If yes, the tool is right and your intuition was off; if no, recheck the From/To selects.

Adjacent concepts worth knowing

• UTC vs GMT. For everyday use they are interchangeable. UTC is the modern technical standard; GMT is the older civil name. The tool lists them together under UTC+0.
• Standard time vs daylight time. Every region has a baseline (standard) offset and, optionally, a seasonal (daylight or summer) offset that is one hour ahead. The dropdown shows standard offsets.
• Half-hour and quarter-hour zones. India (+5:30), parts of Australia (+9:30, +10:30), Newfoundland (−3:30), Iran (+3:30), and Nepal (+5:45) all use non-integer offsets. Only IST is in this tool's dropdown; the others would need a more comprehensive zone list.
• IANA time zone IDs. Names like America/New_York or Asia/Kolkata are the canonical identifiers used by operating systems and programming languages. They encode the full history of DST and offset changes for each region, which is why date-aware libraries can give exact answers where a fixed-offset tool cannot.