How it works
The converter resolves each zone's real UTC offset for the specific date you enter, using the browser's built-in timezone database — the same data your operating system uses. That means daylight saving is handled automatically: a date in summer and a date in winter for the same zone can resolve to different offsets, and the converter always uses the correct one for the date given, rather than assuming a fixed offset year-round.
UTC instant = source time, adjusted by the source zone's offset on that date
converted time = the same UTC instant, displayed in the target zone's local time
Worked example
9:00 AM Pacific Time on 17 August 2026, converted to Sydney.
- 17 August is within US daylight saving, so Pacific Time is PDT, UTC−7.
- 9:00 AM PDT = 9:00 + 7 hours = 4:00 PM UTC the same day.
- 17 August is outside Sydney's daylight saving window (October to April), so Sydney is on standard time, AEST, UTC+10.
- 4:00 PM UTC + 10 hours = 2:00 AM, and crossing midnight rolls the date forward to 18 August.
9:00 AM PDT on 17 August 2026 = 2:00 AM AEST on 18 August 2026 — a 17-hour offset difference.
Common questions
Does this handle daylight saving automatically?
Yes — the offset is resolved for the specific date you enter, using the browser's own timezone data, so it's correct whether that date falls before, during, or after a daylight saving transition in either zone.
Why do some zones show a half-hour or 45-minute offset?
A handful of regions — India, parts of Australia, and a few others worldwide — use offsets that aren't a round number of hours. The converter reads the real offset for each zone rather than assuming whole hours, so these are handled correctly too.