Overview
Convert a date and time from one IANA timezone to any number of others with full daylight-saving awareness. Pick a source zone, enter a local date and time or leave live mode running, and read a table of converted times, one row per target zone, each with its UTC offset and the shift from the source. Handy for calls across continents, flight schedules and release windows, and it runs without sending anything anywhere.
How It Works
Choose the From timezone from the browser's complete IANA zone list, then either keep the Live: Now toggle on to watch the current moment in every selected zone tick by second, or turn it off and enter the date and time you care about - typed as wall-clock time in the source zone, not in your browser's zone. Add target zones with one click from a quick-add strip of major regions, or remove any row. Each row shows the converted date, time, weekday, the zone's exact UTC offset (such as UTC-04:00 or UTC+05:30) and the shift versus the source in hours. The first row repeats the source zone so the shifts have something to compare against.
Step-by-Step Usage Guide
- Pick the source zone, then set a date and time or keep Live: Now running.
- Add target zones from the quick-add strip; each appears as its own row.
- Read each row's converted time, weekday, UTC offset and shift from the source.
- Watch for the DST notice that appears when your input time sits in a transition.
Technical Specifications & Standards
Conversion is genuinely two-zone: your wall-clock input is interpreted in the source zone and re-rendered in each target zone by the browser's Intl engine, which carries the IANA tz database including historical and current DST rules. That is the correct engine to use: DST is not a fixed offset but a schedule that changes by country and occasionally by law, and a hand-rolled offset table goes stale the moment a legislature moves a DST date. The page shows each zone's numeric UTC offset so you can see the saving-time shift rather than trusting a zone name. Around DST transitions the tool is explicit about what happens: if the wall-clock time you typed falls inside the spring-forward gap (it does not exist locally) or the fall-back overlap (it occurs twice), the row is resolved to the earlier instant and a yellow notice says so, rather than silently picking one. The honest limits: the zone list depends on the browser rather than being bundled, a few very old historical dates predate reliable tz data, and leap seconds are ignored, as they are throughout civil timekeeping.
Targeted Use Cases
- Scheduling an international call where both ends are outside UTC, with every participant's zone visible at once.
- Converting a flight arrival time into the local time at the destination.
- Picking a product-release moment that lands in business hours for several regions at once.
- Checking whether a meeting crosses the daylight-saving change in either zone.
Notes & Gotchas
- Use the UTC offset column to confirm standard versus saving time - offsets are the ground truth.
- Prefer this over fixed UTC offsets around DST transitions - offsets lie twice a year.
- Pick zones by city (America/New_York), not by UTC offset, so DST follows the region's rules.
- For recurring meetings, re-check after each DST change in any participant's zone.
Frequently Asked Questions
Does it handle daylight saving time correctly?
Yes. Conversion goes through the browser's Intl engine and the IANA tz database, which tracks each zone's actual DST rules and their change dates, and the offset column shows the resulting UTC offset per zone.
Can I convert to more than one timezone at once?
Yes. Add as many target zones as you like; each is a row in the results table with its own time, date, weekday and offset, and the shift from the source zone is shown alongside.
What happens when I enter a time that does not exist because of DST?
Spring-forward gaps and fall-back overlaps are resolved to the earlier instant, and a notice appears explaining that the input sat inside a transition. Check the UTC offset column to confirm which occurrence you meant.
Why not just use a fixed UTC offset like GMT+5:30?
Fixed offsets break around DST. Zones named after cities apply the region's real rules, including the dates DST starts and ends.