How this calculation works
Enter a wall-clock date and time in the source zone, resolve the corresponding instant, then display that same instant in the destination zone. The date matters because some zone offsets change seasonally or historically. Named zones are used instead of assuming one fixed offset for a city all year.
Worked example
This example uses illustrative inputs. Your current result is shown above.
For 1 January 2024 at 12:00 in Asia/Kolkata, subtract 5 hours 30 minutes to obtain 06:30 UTC on 1 January 2024. With destination UTC, the instant is 2024-01-01T06:30:00.000Z.
Assumptions and limits
- Use the selected source zone rather than assuming that the input belongs to the device’s zone.
- Results use the browser/runtime time-zone database; an outdated device can have outdated rules.
- A source time skipped by a clock change, or repeated twice when clocks move back, is rejected rather than silently selecting an instant.
Questions people ask
Why must I enter a date as well as a time?
The source and destination offsets can depend on the date. Daylight-saving changes mean the same clock time can convert differently in different seasons.
Why is a time rejected around a clock change?
A forward jump can skip a local time entirely, while a backward jump can make it occur twice. These fields do not include an earlier/later occurrence choice, so select an unambiguous time.