UtilToolkits2025-12-26
TL;DR — The Timezone Converter shows side-by-side time across any cities, with a draggable slider to find the overlap window. Pair with the Date Calculator for "how many business days away."
If your team is spread across SF, Berlin, Bangalore, and Tokyo, you have at most a 1-hour overlap where everyone is in working hours. Daylight Saving Time changes that gap by an hour for a few weeks each spring and fall — and not on the same dates. The result: a calendar full of misaligned invites, missed meetings, and the eternal "is that EST or EDT?" thread.
| IANA (always use this) | Common abbreviation | UTC offset |
|---|---|---|
America/Los_Angeles | PT (PST/PDT) | −8 / −7 |
America/New_York | ET (EST/EDT) | −5 / −4 |
Europe/London | GMT / BST | 0 / +1 |
Europe/Berlin | CET / CEST | +1 / +2 |
Asia/Kolkata | IST | +5:30 |
Asia/Tokyo | JST | +9 |
Abbreviations are ambiguous (IST = India Standard Time or Israel Standard Time?). IANA names are unambiguous and DST-aware. Stick to IANA in code, configs, and calendar invites.
The US and EU shift DST on different dates — the gap between London and New York is "usually 5 hours" but is briefly 4 hours in mid-March and again in late October/early November. The Timezone Converter handles this automatically as long as you’re entering future dates rather than abstract "10 AM PT".
For Americas–Europe overlap: 14:00–16:00 UTC. For Europe–India: 13:00–16:00 UTC. For a true global call (Americas + EMEA + APAC), you almost always have to inconvenience one region — rotate it.
Daylight Saving Time. The US, Europe, and Australia all start/end DST on different dates, so the gap shifts during transitions.
Because abbreviations aren’t standardized. Use IANA names (Asia/Kolkata vs Asia/Jerusalem) in any context where ambiguity matters.
The converter generates a shareable URL that encodes the time — recipients see it in their local zone automatically.