Translate one moment across zones

Choose the city in the From panel, then enter the date and time as they would appear on a clock there. Add destination cities to the To panel. All results describe the same moment, even when the displayed dates differ. The source city can be different from your device's time zone.

For example, a London call at 18:00 on 15 January 2026 is at 13:00 that day in New York and 03:00 on 16 January in Tokyo. Share the full local date and city with each participant, rather than sending only “three o'clock.” Use the current-time button to replace an edited appointment with the time now in the source city.

Neither table below is live. Each one takes a single fixed moment and runs it through the same code the panels above use, worked out when this version of the page was built. The source is Lisbon and the destinations are the four cities the converter starts with, so typing either date and time into the From panel should reproduce these rows exactly.

Two things in that table are easy to miss. Tokyo and Sydney have already turned over to Wednesday, so an invitation quoting the hour on its own would put half of these destinations on the wrong day. And London reads the same figure as Lisbon while sitting in a different country and a different zone; that is a property of those two places, not a rule about neighbours, and it holds all year only because Portugal and the United Kingdom happen to keep the same offset throughout.

The second table takes the same five cities five months earlier, and the right-hand column has moved. Tokyo sits nine hours ahead of Lisbon in January and eight in June, although nothing at all changed in Japan: Lisbon put its clocks forward and Tokyo, which never moves its own, stayed where it was. Sydney swings further, from nine hours ahead to eleven, because Australia is on summer time exactly when Europe is not. New York is the instructive one. Its gap from Lisbon is five hours in both tables even though its offset from UTC differs between them, because the two cities change their clocks in the same season and the distance between them survives the change. Which pairs hold steady is not something to guess at, which is the argument for converting a date rather than carrying a number around in your head.

The converter calculates offsets for the date you enter using the time-zone rules available in your browser. A difference of five hours today may become four hours for part of March if the two countries start daylight saving on different dates. For a recurring meeting, check dates on both sides of each change.

Some local times do not exist when clocks move forward; others happen twice when clocks move back. This tool resolves the input to one instant but does not offer a choice between repeated hours or flag every skipped hour. Avoid scheduling in that transition window, or confirm the exact UTC time with the organiser. Keep system time-zone data updated, especially when planning far ahead after a rule change.

The large figure on the right of a row is the clock time in that city at the converted moment, in 24-hour form. Directly beneath it sits the weekday and date in that same city, and an amber +1d or −1d appears whenever that date is not the date you typed in the From panel. Under the city name you get the country, a short zone label and the city's offset from UTC at that moment.

The short zone label is produced by your own browser, which explains why it is not always the abbreviation you expected. The same city can be labelled EDT on one date and GMT+1 on another, depending on the zone and what names the browser holds for it. The offset beside it is the reliable part: it is a number derived from the conversion rather than a name looked up in a list.

The accent-coloured figure at the end of the row is the distance between that city and the source city. It reads “same” when the two clocks agree, and otherwise carries a sign and an hour count, with the minutes added for a zone that needs them: +5h 30m, −7h. It belongs to the converted moment, not to the present one, so the same pair of cities can show different gaps for two dates in the same year. In the From panel the pills do the same job for the source: its offset, its weekday, and an amber pill when that date falls inside the city's daylight-saving period. That pill is decided by comparing the offset on your date against the smallest offset the zone uses anywhere in that year, so a country that never moves its clocks never shows it.

There is no time-zone table inside this site. Every figure comes from asking your browser to format one instant for a named IANA zone, such as Europe/Lisbon or America/New_York, and reading the offset back out of the answer. The practical consequence is that results are exactly as current as the zone rules shipped with your browser and operating system. A country that announces a change gets picked up once your device has an update carrying it, and a device left unpatched for years can be confidently wrong about a date far ahead.

The picker covers a fixed list of 182 cities and matches on city name, country or zone name, offering up to eight suggestions at a time. Cities are stand-ins for zones, so any listed city sharing a zone with yours produces identical results: if your town is missing, pick the nearest one on the same rules rather than the nearest one on the map. Going the other way, your entered date and time are resolved to an instant by guessing the offset and correcting it until the two agree, which settles in a couple of passes for every real zone but has nothing sensible to return for an hour that a clock change deleted.

Nothing here reaches a server. The conversion runs in the page, the source city and the destination list are kept in this browser and return when you come back, and the date and time you typed are not among them. Closing the tab clears the appointment, and no one is told about it: this is a calculator, not a calendar, and it sends nothing to the people you are converting for.