How to Calculate Time Difference Between Cities

I've been burned too many times by timezone math. You know that moment when you're sure it's a good time to call someone, only to wake them up at 3 AM? Yeah. Let me show you how the math actually works—not because you'll do it by hand every time, but because understanding it stops those painful mistakes.

Here's what I've learned after years of coordinating across continents: UTC offsets aren't scary, DST is the real villain, and sometimes just pulling up a converter is the smart move. Let's break it down.

UTC Offsets Are Your Friend

Think of UTC as the world's neutral meeting point. Every timezone defines itself by how many hours it's ahead or behind UTC—that's the offset. London sits at UTC+0 (well, when it's not doing the daylight saving dance). New York? UTC-5 in winter. Tokyo's chilling at UTC+9 year-round because Japan said no thanks to DST.

Here's what you're working with:

| City | Time Zone | Standard Offset | DST Offset |

|------|-----------|-----------------|------------|

| London | GMT/BST | UTC+0 | UTC+1 |

| New York | EST/EDT | UTC-5 | UTC-4 |

| Los Angeles | PST/PDT | UTC-8 | UTC-7 |

| Tokyo | JST | UTC+9 | None |

| Sydney | AEST/AEDT | UTC+10 | UTC+11 |

| Dubai | GST | UTC+4 | None |

| Mumbai | IST | UTC+5:30 | None |

Once you know two cities' offsets, the math is just subtraction. That's it. Well, mostly.

The Math (It's Easier Than You Think)

Ready for the formula? Offset of City B minus Offset of City A. That's all.

Let me show you with real cities I actually need to coordinate with:

New York to London in January:

• New York's at UTC-5
• London's at UTC+0
• Do the math: 0 - (-5) = 5 hours
• London's 5 hours ahead

Los Angeles to Tokyo:

• LA sits at UTC-8
• Tokyo at UTC+9
• Calculate: 9 - (-8) = 17 hours
• Tokyo's almost a full day ahead

Sydney to Dubai:

• Sydney: UTC+10
• Dubai: UTC+4
• Work it out: 4 - 10 = -6 hours
• Dubai's 6 hours behind

See how negative numbers flip when you subtract them? That's where people mess up.

When Timezones Get Weird

Some places don't play by whole-hour rules. India's at UTC+5:30. Nepal decided UTC+5:45 was the perfect spot. Parts of Australia use UTC+9:30. Why? Good question. I don't make the rules.

New York to Mumbai:

• New York: UTC-5 (that's -5.0 if you're doing decimals)
• Mumbai: UTC+5:30 (or 5.5)
• Math time: 5.5 - (-5) = 10.5 hours
• Mumbai's 10 and a half hours ahead

Converting those half-hours into decimals (30 minutes = 0.5) makes the subtraction cleaner.

DST: The Thing That Ruins Everything

Okay, so you've got the basic math down. Now let me ruin your day: Daylight Saving Time exists, and it's chaos incarnate.

The US and Europe do DST. Japan doesn't. India doesn't. China gave up on it decades ago. So the time difference between, say, New York and Tokyo actually changes depending on what month it is.

New York to London throughout the year:

| When | New York | London | Difference |

|------|----------|--------|------------|

| Winter (Nov-Mar) | EST (UTC-5) | GMT (UTC+0) | 5 hours |

| March gap | EDT (UTC-4) | GMT (UTC+0) | 4 hours |

| Summer (Mar-Oct) | EDT (UTC-4) | BST (UTC+1) | 5 hours |

| Oct-Nov gap | EDT (UTC-4) | GMT (UTC+0) | 4 hours |

See those gaps? That's when one place has switched and the other hasn't yet. It's a scheduling nightmare.

Why DST Makes Me Want to Scream

Nobody switches on the same day. The US does the second Sunday in March and first Sunday in November. Europe waits until the last Sunday in March and last Sunday in October. Australia's on the opposite schedule because, you know, southern hemisphere.

Those weeks when the dates don't align? Pure confusion. I've scheduled meetings that were supposed to be at 2 PM and ended up at 1 PM or 3 PM because I forgot one location had already switched.

Then there's the hemisphere flip. When New York springs forward in March, Sydney's falling back. They're moving in opposite directions. Try coordinating a quarterly meeting across both and tell me how it goes.

How I Deal With DST

Look, I don't do mental math for DST anymore. Here's my actual process:

• Check what date it is (obviously)
• Look up the current offset for both cities—not the standard one, the one that's active *right now*
• If it's March, April, October, or November, I double-check everything
• When it actually matters, I just use a tool like Time Zone Converter because I've been wrong too many times

The IANA timezone database has the authoritative DST schedules if you really want to dig in, but honestly? Life's too short.

Should You Even Do This By Hand?

Short answer: usually no.

I know the math. I just explained it to you. But when I'm actually scheduling something that matters—a client call, a team standup, literally anything where getting it wrong would be embarrassing—I pull up a tool. Here's why:

Tools handle DST automatically. They know which cities have switched and which haven't. They account for those weird transition weeks. They save you from looking like an idiot when you schedule a meeting at 4 AM someone's time.

Future planning works. Need to schedule something for October 2026? The tool already knows when DST ends that year. You don't have to research it.

Multiple cities get complicated fast. Try doing mental math for New York, London, Mumbai, and Tokyo at once. Have fun with that.

Weird offsets are built in. Nobody's memorizing that Nepal is UTC+5:45.

When I Actually Do The Math

I still do manual calculations when:

• I'm offline and need a rough estimate
• I'm in a conversation and want to quickly double-check something
• I'm verifying that a tool's answer makes sense (rare, but I've seen bugs)
• I'm explaining timezones to someone and want to show how it works

That's about it.

Tools I Actually Use

| Tool | What I Use It For |

|------|-------------------|

| Whenest Time Zone Converter | Quick "what time is it there?" checks |

| Whenest Meeting Planner | Finding a time that works across 4+ cities |

| Whenest Overlap Finder | Team scheduling with specific working hours |

timeanddate.com is also solid if you need a second opinion or want to check historical DST dates.

How to Actually Do This (Step-by-Step)

Alright, let's say you really do need to calculate it by hand. Maybe you're on a plane with no wifi, or you just want to understand what's happening under the hood. Here's how I break it down.

Start With the Basics

Figure out what you're working with. Let's use a real example: I need to call my colleague in Berlin, and I'm in Chicago. It's July 15, 2026. What time works?

Write down:

• Chicago (where I am)
• Berlin (where they are)
• July 15, 2026 (the date that matters)

Look Up the Offsets

Now I need the UTC offsets for both cities on that specific date. July 15 is summer in the northern hemisphere, so both cities are observing DST.

• Chicago: CDT (Central Daylight Time) = UTC-5
• Berlin: CEST (Central European Summer Time) = UTC+2

Pro tip: Time.is will show you the current UTC offset for any city. Just search the city name.

Do the Subtraction

Formula time: Berlin offset minus Chicago offset

• Berlin: +2
• Chicago: -5
• Math: 2 - (-5) = 7 hours

Positive result means Berlin is ahead.

Figure Out the Actual Time

If it's 9:00 AM in Chicago, what time is it in Berlin?

Berlin's ahead, so I add: 9:00 AM + 7 hours = 4:00 PM in Berlin

Perfect. They're still at work. I can call.

If Berlin were behind, I'd subtract instead. The sign of your result tells you which way to go.

Double-Check It

Here's the thing: I still verify with Time Zone Converter before making the actual call. I've seen too many weird edge cases—DST transitions I forgot about, cities that randomly decided to change their timezone rules, you name it.

The math is solid, but reality has bugs.

Where People Screw Up (Including Me)

Let me tell you about the mistakes I've made so you don't have to.

Using Winter Offsets in Summer

Classic error. I'll look up "New York timezone" and see UTC-5, then forget that it's currently April and they're on UTC-4. Always check if DST is active on the date you care about, not just the standard offset.

Forgetting About Tomorrow

When you add hours and blow past midnight, the date changes. Sounds obvious, but it's easy to miss.

Example: It's 8:00 PM in LA on July 15. What time is it in Sydney?

• LA: UTC-7 (PDT)
• Sydney: UTC+10 (AEST, because it's winter there and no DST)
• Difference: 10 - (-7) = 17 hours
• 8:00 PM + 17 hours = 25:00 = 1:00 PM on July 16 in Sydney

You need to wrap around. 25:00 minus 24 hours puts you at 1:00 PM the next day.

Getting the Sign Wrong

East of UTC is positive. West of UTC is negative. I still sometimes mix these up when I'm tired.

Americas: negative offsets. Europe, Asia, Australia: positive offsets. If you get the sign backwards, your whole answer's wrong.

Those Cursed Transition Weeks

I scheduled a recurring meeting in October once. Worked perfectly for months. Then DST ended in Europe but not the US yet, and suddenly our meeting was an hour off. Nobody showed up on time for two weeks until we figured it out.

If you're planning something during March, April, October, or November, just use a tool. Don't trust your mental math. The timeanddate.com DST calendar has all the dates if you want to check manually.

Cheat Sheet: Common City Pairs

Bookmark this table. These are the routes I calculate most often:

| From | To | Winter | Summer |

|------|----|--------|--------|

| New York | London | 5 hours | 5 hours |

| New York | Tokyo | 14 hours | 13 hours |

| London | Sydney | 11 hours | 9 hours |

| Los Angeles | Berlin | 9 hours | 9 hours |

| Dubai | New York | 9 hours | 8 hours |

Remember: during those DST transition weeks in March, April, October, and November, these can shift by an hour. Always double-check.

What I Actually Do Now

Look, I taught you the math. I've shown you how UTC offsets work, how to handle DST, how to catch the common mistakes. But here's what I actually do in real life:

I use Time Zone Converter.

Why? Because the calculator doesn't forget about DST transitions. It doesn't mix up positive and negative offsets when I'm tired. It doesn't accidentally schedule a meeting at 3 AM because I forgot Sydney's in winter.

Understanding the math matters—it lets me sanity-check results, do quick mental estimates when I'm offline, and know why timezones sometimes seem to behave weirdly. But when I'm actually coordinating something that matters, I let the computer do the arithmetic.

If you're scheduling across multiple cities at once, check out Meeting Planner. It'll show you the overlap hours visually, which beats doing four separate timezone calculations by hand. And if you want to dive deeper into the abbreviations (what's the difference between EST and EDT, anyway?), I've written about time zone abbreviations and GMT vs UTC.

Bottom line: know how it works, but use tools. Your future self will thank you.