Convert an instant rather than an undated clock label
To convert a time across daylight saving changes, supply its calendar date, local clock reading and source time zone, then choose the destination zone. A city-to-city difference without a date can be wrong during transition weeks. If the source clock repeats, specify which occurrence is intended. If the clock reading was skipped, there is no instant to convert until the source time is corrected or clarified.
The Time Zone Converter treats the resolved source and destination readings as two representations of the same instant. It does not subtract them to measure travel time. This guide uses hypothetical appointments in America/Los_Angeles and Europe/London, with explicit dated examples under the applicable zone rules. Keep the actual appointment date in the input even when a familiar offset seems likely; today's difference does not establish every future date's difference.
Name both regions and retain the full source date
IANA location identifiers such as America/Los_Angeles describe regional time-zone histories. UTC is a fixed reference accepted by the tool. Abbreviations such as CST can mean different things in different places, and a numeric offset alone does not describe a region's seasonal rules. Select a suggested location or type an IANA identifier recognized by the runtime. A nearby city is useful only if it actually follows the same time-zone rules.
Enter the source's local date, not the date currently displayed on a device in another country. The supported source range is 2000–2100, with calendar dates and seconds validated before conversion. Source changes reset an earlier repeated-time choice so it cannot silently carry over to another appointment. The input is a wall clock in the named source zone; it is not automatically interpreted in your computer's current location.
Use UTC to follow the calculation in two steps
First subtract the source's dated UTC offset to identify the instant. Then add the destination's offset at that same instant. For January 20, 2026 at 09:15 in Los Angeles, the source offset is −08:00, so UTC is 17:15. London is at +00:00 on that date, making its corresponding local time 17:15 on January 20. Retaining the UTC result provides a common reference for checking the conversion.
On July 20, 2026, Los Angeles at 09:15 uses −07:00, so the instant is 16:15 UTC. London then uses +01:00, giving 17:15 locally. The destination hour matches the January example, but the underlying offsets differ. This distinction matters when recording a timestamp, comparing a third region or checking a calendar system. A matching displayed hour does not mean that daylight saving had no effect on either location.
Check weeks when regional transitions do not align
On March 20, 2026, Los Angeles has moved to −07:00 while London remains at +00:00. A 09:15 Los Angeles appointment therefore converts to 16:15 London, seven hours ahead rather than the eight-hour difference in the January and July examples. The table keeps the source clock reading fixed across those dates so the effect of nonaligned seasonal transitions can be inspected without changing the meeting's intended source time.
A recurring meeting needs a scheduling policy: keep one region's local clock fixed, keep a UTC instant pattern, or keep another region's clock fixed. Those choices can produce different local times elsewhere after a transition. This tool converts one dated occurrence at a time; it does not generate a recurring calendar series or decide which policy the participants intended. Check the dates around each region's transition when communicating a repeated appointment.
| Source date | UTC instant | Europe/London local time |
|---|---|---|
| January 20, 2026 | 2026-01-20 17:15 UTC | 2026-01-20 17:15, UTC+00:00 |
| March 20, 2026 | 2026-03-20 16:15 UTC | 2026-03-20 16:15, UTC+00:00 |
| July 20, 2026 | 2026-07-20 16:15 UTC | 2026-07-20 17:15, UTC+01:00 |
All source readings are 09:15 in America/Los_Angeles. Examples follow the applicable dated zone rules; a runtime with outdated or changed rules may differ.
Reject a skipped time instead of moving it silently
In America/Los_Angeles on March 8, 2026, 02:30 lies in the spring-forward gap. That local reading never occurs under the relevant rules, so the converter cannot associate it with a valid instant. It reports an error for every occurrence option. It does not silently change the appointment to 03:30 or reinterpret it as an earlier hour. Ask for an existing time when the source schedule falls in that skipped interval.
A gap is different from an ordinary conversion that crosses midnight in the destination. In the gap, the source itself is invalid. In a date crossing, the source identifies an instant normally and another region simply has a different calendar date. Political changes can also skip larger intervals, including a full local date, as occurred for Pacific/Apia on December 30, 2011. The validation checks whether the original source clock reading actually exists.
Resolve the two occurrences of a repeated time
In Los Angeles on November 1, 2026, 01:30 occurs twice. The first occurrence uses −07:00 and identifies 08:30 UTC. The second uses −08:00 and identifies 09:30 UTC. London is at +00:00 for both, so the two possible destination readings are 08:30 and 09:30. With no explicit occurrence choice, the tool stops and asks for one rather than selecting the first candidate by default.
First and second refer to chronological instants, not a worldwide definition of summer and winter. After selection, the interface shows both candidates with their offsets so the decision can be documented. Not every repeated interval lasts an hour: Australia/Lord_Howe has a thirty-minute seasonal change under its relevant rules. A repeated time there can identify two instants only thirty minutes apart, making a universal add-one-hour shortcut unsuitable.
Keep fractional offsets and calendar changes visible
UTC offsets are not restricted to whole hours. At the example dates, Asia/Kathmandu is +05:45 and Asia/Kolkata is +05:30. The converter keeps those minute components instead of rounding them to an hour. The displayed destination-minus-source offset difference compares the zones at the chosen instant; it is not elapsed meeting or flight duration. An offset with a plus sign means the local reading is ahead of UTC at that instant.
For a separate hypothetical conversion, January 20, 2026 at 18:30 in Los Angeles corresponds to January 21 at 02:30 UTC and January 21 at 11:30 in Asia/Tokyo. The destination calendar date is one day later. Saving only 11:30 would lose essential information, especially around the international date line. Keep the complete date and named zone with every converted clock time, then calculate elapsed duration separately if the question actually involves two different instants.
Record the chosen instant and check rule freshness
A useful appointment record contains the source local date-time, source IANA zone, selected occurrence if needed, UTC instant, destination local date-time and both UTC offsets. For the second Los Angeles 01:30 on November 1, save 09:30 UTC as well as −08:00. This makes the intended occurrence recoverable even if a later message drops the first-or-second description or someone views the event from a different device location.
This educational converter uses the time-zone database installed in the browser or runtime; it does not fetch live rule updates or guarantee that every device has the latest release. Political decisions can alter future offsets, and software versions can carry different rules. Keep software updated and reconfirm important future appointments with the authoritative schedule. Use the duration and countdown guides for their separate timing questions, and do not treat a dated conversion as a guarantee that future legislation is already known.