“9am tomorrow” is not a time
A Slack message that says 9am without a zone is how a Bangalore engineer joins at 9pm. I convert using IANA names the browser already knows: Asia/Kolkata, America/Los_Angeles, Europe/London. India Standard Time is UTC+5:30, not UTC+5. People type +5 because the half hour is annoying. The half hour is the whole point. US Pacific moves between UTC−8 and UTC−7 when daylight saving flips. India does not observe DST. A meeting that is comfortable in January can be cruel in July even if nobody changed the wall-clock label.
The short dropdown is not the full tz database. If your city is missing, picking “a city with the same offset” is already a smell: offsets are not zones. America/Phoenix does not do DST; America/Denver does. Same “Mountain” folklore, different winters. This page never asks to connect a calendar. Type the datetime, pick two zones. Your schedule stays in this tab. The world-clock strip uses the same Intl path.
Worked example: 10:00 Pacific to IST
Pick America/Los_Angeles → Asia/Kolkata. In January (PST, UTC−8), 10:00 PT is 18:00 UTC, which is 23:30 IST. In July (PDT, UTC−7), 10:00 PT is 17:00 UTC, which is 22:30 IST. Same “10am Pacific” is 11:30pm or 10:30pm in India depending on the date. If you booked the winter offset in July, someone is late by an hour and both of you will blame the other timezone.
Worked example: 15:00 IST toward Pacific
15:00 in Kolkata is 09:30 UTC. In a US winter that is 01:30 PT. In a US summer that is 02:30 PT. Do not send a 3pm IST invite to San Francisco and act surprised. Slide the IST time to 08:00 (21:30 or 22:30 PT the previous evening) or pick a slot both sides can survive. Confirm with this converter on the actual calendar date, not a weekday in the abstract.
Worked example: London is not UTC from late March
Europe/London tracks BST. From late March to late October, London is UTC+1. A “noon London / noon UTC” standup is wrong for most of the year. Convert a July noon London to UTC and you should see 11:00 UTC. If you got 12:00, you used the wrong zone or a date in winter. Australia/Sydney flips the other way around the calendar from the US, which is how “opposite DST” double-offsets happen in October.
What this will not catch
Historical rule changes (a country that dropped DST in 2011). Leap seconds. Aircraft and ships. Ambiguous local times in the autumn fall-back hour: 01:30 might exist twice. The datetime picker’s timezone is your device’s zone until you convert; if you type 15:00 meaning IST while sitting in UTC, you have already lied to the input. Set the from-zone explicitly. Seconds exist in the formatter; meetings are minute business. Pair with the timestamp converter when the artefact is a Unix epoch, not a wall clock.
Write the zone in the invite: 15:00 Asia/Kolkata, not “3pm IST-ish” and not “morning for US.” IST is a well-known abbreviation; CST is a trap (Central Standard Time vs China Standard Time). IANA names are ugly and unambiguous. If a recruiter in PT proposes “9am my time” in March, convert that March date, not a date in August, before you block a calendar. Recurring meetings that straddle a US DST transition will shift by an hour for one side unless the calendar product is zone-aware. This converter does one instant. Recurrence is the calendar’s problem.
Questions
Where do the zone rules come from?
The browser’s Intl / IANA timezone database. No calendar API. No Google connect.
Is IST UTC+5?
No. Asia/Kolkata is UTC+5:30 year-round. The missing 30 minutes is a real meeting bug.
Does DST change the answer?
Yes, for zones that observe it. Convert on the actual date. January Pacific is not July Pacific.
Why isn’t my city in the list?
The dropdown is a short IANA set (Kolkata, Los Angeles, London, Tokyo, Sydney, and a few more). Offsets are not a substitute for the right zone name.
Is my calendar uploaded?
There is no calendar field. You type one datetime. It stays in this tab.
London equals UTC?
Only when GMT is in force. For most of the year London is on BST (UTC+1). Convert a summer date and check.