Does it handle daylight saving?

Yes, for both the source and the target zone, using the rules in effect on the date you pick rather than the rules in effect today.

Where can I plan a meeting across several zones?

This converter handles one pair at a time. For a multi-zone planner and Unix timestamp tools, use the sibling site TimeConvertor.net.

Why does the result show a different day from the one I typed?

Because the instant you named falls on a different calendar date in the To zone. 2026-06-15T18:00 in Los Angeles, United States is 11:00 AM on Tuesday, June 16, 2026 in Sydney, Australia. The subline carries the weekday and the date so this is visible without working it out.

Why is the gap between two cities not the same every month?

Because the converter looks up each zone's offset for the date you typed. Between New York, United States and London, United Kingdom the time-zone data gives a gap of 4 hours on 2026-03-10T09:00 and 5 hours on 2026-04-10T09:00; the page reports what the data returns for that date rather than a fixed difference.

What is the label after the time in the subline?

It is whatever short zone name the formatter supplies for the To zone at that instant, and it is there so you can see which side of a clock change the result landed on. The page shows the label as given; at build time it was GMT+5:45 for Kathmandu, Nepal in the example above.

No. The field takes a date, an hour and a minute, and the readout shows the hour and minute in the To zone; nothing on the stage is finer than a minute.

Which zones does it start on?

The From list starts on your browser's own zone when that zone is one of the listed cities, and otherwise on New York, United States; the To list starts on London, United Kingdom. The field starts on the current minute in your browser's zone. Nothing is remembered between visits, so a reload returns to this starting point.

What happens if I type a time the clocks skipped?

The converter still returns an instant. Converting 2026-03-08T02:30 from New York, United States back into New York, United States gives Sunday, March 8, 2026 at 3:30 AM EDT: the reading typed was 2:30 AM and the result reads 3:30 AM. That mismatch, and the zone label, are how the page shows that the reading was skipped. If the instant matters, check the label and choose a reading clearly on one side of the change.

Time Zone Converter · WRLD CLOCK

Matching local time

10:58PM

Monday, October 5, 2026 at 10:58 PM GMT+1

Europe/London

Date and timeFromTo

Choose a local date and time, then see the matching moment elsewhere.

What it converts

Choose a date and time, the zone it is written in, and the zone you want it in. The result is the matching instant in the target zone, formatted with its own abbreviation so there is no ambiguity about which side of a clock change you have landed on.

Why the answer can surprise you

Time zones are political, not geometric. Offsets change, daylight-saving rules differ by country and sometimes by year, and a meeting that is comfortable in March can be uncivilised in November. The conversion uses the IANA time-zone database shipped with your browser, which is the same source most operating systems use.

How a reading becomes an instant

The date-and-time field hands the page a wall-clock reading — a year, month, day, hour and minute — and nothing else. A reading on its own is not an instant: nine in the morning names a different moment in New York, United States than it does in London, United Kingdom. So the converter’s first job is to turn the reading plus the From zone into one instant, and it does that by refinement rather than by a table. It takes the reading as if it were already universal time, asks the time-zone data for the From zone’s offset at that estimate, subtracts the offset, and then asks again at the corrected estimate. For a reading that exists once in the From zone, the offset finally used is the one in force at the instant itself rather than the one in force when you opened the page; a reading that exists twice settles on one of the two, and a reading in a transition gap lands on one side of the change, as the examples further down show. The instant that falls out is what the rest of the stage formats. There is no arithmetic on a remembered difference between two cities; the page never holds a remembered difference at all, which is why it cannot be wrong in the way a remembered difference is wrong.

A worked example at a fixed date

Every figure in the examples that follow was computed when this page was built, with the same Intl formatting options and the same resolution steps the converter uses, from the fixed inputs each example states; nothing here reads the clock. Type 2026-06-15T09:00 with From set to New York, United States and To set to London, United Kingdom. Resolved in the From zone, that reading is 9:00 AM EDT on Monday, June 15, 2026, an offset of UTC−4. Formatted in the To zone, the same instant reads 2:00 PM, and the subline under the numerals shows it in full: Monday, June 15, 2026 at 2:00 PM GMT+1. The time-zone data places London, United Kingdom at UTC+1 for that instant, so the two readings are 5 hours apart, with London, United Kingdom ahead of New York, United States.

The same pair, one month apart

Change only the date and the gap can change. With From and To left as they were, 2026-03-10T09:00 resolves to 1:00 PM in London, United Kingdom (Tuesday, March 10, 2026 at 1:00 PM GMT), while 2026-04-10T09:00 resolves to 2:00 PM (Friday, April 10, 2026 at 2:00 PM GMT+1). The offsets the time-zone data reports account for the shift: on the March date New York, United States is at UTC−4 and London, United Kingdom at UTC, a gap of 4 hours; on the April date they are UTC−4 and UTC+1, a gap of 5 hours. This is the practical form of the warning above. The difference between two cities is a property of the date, not of the cities, and the converter looks it up for the date you typed rather than for today.

Offsets that are not whole hours

Not every zone sits a whole number of hours from the next. 2026-06-15T09:00 typed in London, United Kingdom and converted to Kathmandu, Nepal gives 1:45 PM; the subline reads Monday, June 15, 2026 at 1:45 PM GMT+5:45. The time-zone data places Kathmandu, Nepal at UTC+5:45 on that date, against UTC+1 for London, United Kingdom, so the minutes in the readout are part of the answer, not a rounding artefact; the gap is 4 hours 45 minutes. The zone label comes from the formatter too: it is whatever short zone name the formatter supplies for that zone at that instant. At build time that was GMT+5:45 for Kathmandu, Nepal and GMT+1 for London, United Kingdom, and the page shows the label as given.

When the date moves too

A conversion can cross midnight, and the numerals alone will not tell you. 2026-06-15T18:00 in Los Angeles, United States — Monday, June 15, 2026 at 6:00 PM PDT — is 11:00 AM in Sydney, Australia, but on Tuesday, June 16, 2026. The gap for that instant is 17 hours, with Sydney, Australia ahead of Los Angeles, United States, and a gap that large pushes an evening reading into the following day. The subline carries the weekday and the full date for exactly this reason: read the numerals first, then check the line beneath them before you write the time into a calendar.

The same pair in January and July

The two offsets behind a gap can move in opposite directions over a year. 2026-01-15T12:00 in London, United Kingdom is 11:00 PM in Sydney, Australia, with the data reporting UTC+11 against UTC, a gap of 11 hours. 2026-07-15T12:00 is 9:00 PM, with UTC+10 against UTC+1, a gap of 9 hours. Both offsets moved between the two dates, and they moved in opposite directions. The page states no rule for why; it asks the time-zone data for each date and shows what comes back, for every date and every pair in the list.

Readings that exist twice or not at all

The value the field hands the page carries no zone and no flag, so the page cannot tell which of two identical readings you mean on a night the clocks go back, or that a reading was skipped on a night they go forward. Such a reading still goes through the same refinement and lands on one instant, and the zone label in the subline is how you find out which. Converting 2026-11-01T01:30 from New York, United States back into New York, United States shows Sunday, November 1, 2026 at 1:30 AM EDT; one hour after that instant the same zone reads 1:30 AM EST — the same numerals under a different label, which is what makes the reading ambiguous — and the label on the stage is how you see which of the two the refinement settled on. Converting 2026-03-08T02:30 the same way shows Sunday, March 8, 2026 at 3:30 AM EDT: the reading typed was 2:30 AM, the result reads 3:30 AM, and that mismatch is the sign the reading was skipped and the instant you get is the one the refinement reached instead. If the instant matters, check the label and choose a reading clearly on one side of the change.

How to read the display

The large numerals are the hour and minute in the To zone, with AM or PM set smaller beside them the way the home clock sets them. They are never the time you typed; your own reading stays in the field. Under the numerals, the subline spells out the weekday, date, year, time and zone label for that instant, and the quieter line below it gives the zone’s identifier as the time-zone database names it, such as Asia/Kathmandu. The field has no seconds, so the readout has none either; a trailing :00 on numerals that size would be noise. Change any of the three inputs and the whole stage recomputes from the new instant. There is no Convert button because there is nothing to wait for.

What the converter does not do

It converts one reading between one pair of zones. The From and To lists hold 63 cities, each tied to the IANA zone identifier shown in brackets, and the identifier is what the conversion uses; it does not always carry the city’s name, as the entry New Delhi, India (Asia/Kolkata) shows. A city that is not in the list has no entry to pick; the question below names a sibling site with a multi-zone planner. The converter keeps no history. It opens on the current minute in your browser’s own zone with the seconds cleared, with From set to that zone when it is one of the listed cities and otherwise to New York, United States, and with To set to London, United Kingdom; a reload returns to that starting point. It knows nothing about events, so it cannot confirm a flight, a filing or a market open — verify any consequential time against the authoritative source. And it does not read or write Unix timestamps.

Common misreadings

Reading the numerals as the time you typed: the stage shows the To zone only. Reading the time without the date: an evening on one side is often the next morning on the other, as the Los Angeles, United States example shows. Carrying a remembered difference across the year: the New York, United States to London, United Kingdom gap is 4 hours on Tuesday, March 10, 2026 and 5 hours on Friday, April 10, 2026, and the converter never remembers a difference, which is the point. Reading a numeric label such as GMT+5:45 as an error: it is the label the formatter supplies for that zone at that instant. Swapping From and To: the direction matters, and the stage names the To zone but not the From zone, so check the From list before you trust the numerals.

Everything runs in your browser

The conversion happens on your own device, with the time-zone data your browser ships, and nothing you type in the field or pick in the lists is transmitted. The figures on this page were produced at build time with the same Intl formatting options and the same resolution steps the converter uses, at the fixed inputs each example states, so what you read here was produced by the steps the stage runs rather than typed in. The methodology page sets out how every tool on the site works, and the guide on counting down to a date across daylight saving covers how a wall-clock reading is read in your own zone and why a count that spans a clock change is short or long by exactly one hour.

Questions

Does it handle daylight saving?: Yes, for both the source and the target zone, using the rules in effect on the date you pick rather than the rules in effect today.
Where can I plan a meeting across several zones?: This converter handles one pair at a time. For a multi-zone planner and Unix timestamp tools, use the sibling site TimeConvertor.net.
Why does the result show a different day from the one I typed?: Because the instant you named falls on a different calendar date in the To zone. 2026-06-15T18:00 in Los Angeles, United States is 11:00 AM on Tuesday, June 16, 2026 in Sydney, Australia. The subline carries the weekday and the date so this is visible without working it out.
Why is the gap between two cities not the same every month?: Because the converter looks up each zone's offset for the date you typed. Between New York, United States and London, United Kingdom the time-zone data gives a gap of 4 hours on 2026-03-10T09:00 and 5 hours on 2026-04-10T09:00; the page reports what the data returns for that date rather than a fixed difference.
What is the label after the time in the subline?: It is whatever short zone name the formatter supplies for the To zone at that instant, and it is there so you can see which side of a clock change the result landed on. The page shows the label as given; at build time it was GMT+5:45 for Kathmandu, Nepal in the example above.
Can I enter seconds?: No. The field takes a date, an hour and a minute, and the readout shows the hour and minute in the To zone; nothing on the stage is finer than a minute.
Which zones does it start on?: The From list starts on your browser's own zone when that zone is one of the listed cities, and otherwise on New York, United States; the To list starts on London, United Kingdom. The field starts on the current minute in your browser's zone. Nothing is remembered between visits, so a reload returns to this starting point.
What happens if I type a time the clocks skipped?: The converter still returns an instant. Converting 2026-03-08T02:30 from New York, United States back into New York, United States gives Sunday, March 8, 2026 at 3:30 AM EDT: the reading typed was 2:30 AM and the result reads 3:30 AM. That mismatch, and the zone label, are how the page shows that the reading was skipped. If the instant matters, check the label and choose a reading clearly on one side of the change.