Laiko juostų keitiklis

Compare time zones on one live screen

This free time zone converter puts every city you care about on one screen. Each row shows the city's current (or selected) time, date, UTC offset and difference from your base city, plus an aligned 24-hour strip — every column represents the same moment across all rows, so reading across answers 'what time is it there when it's 3 PM here?' without any arithmetic.

Drag the slider or click any hour cell to move the moment; every row updates live. There are no page reloads, no forms to submit, and no account required. Add unlimited cities and your lineup is saved in your browser for next time — unlike World Time Buddy, which caps the free tier at 4 locations and requires sign-in.

A meeting planner that shows the overlap

Scheduling across time zones is an overlap problem, so the hour strips are colour-coded like a meeting planner: green for core working hours (9–17), amber for the edges (7–9 and 17–21), and muted for hours nobody wants. Columns where every row is green are safe slots; a column that's green in New York but midnight-grey in Mumbai tells you to keep looking.

Found the slot? Click it and hit Copy meeting times — you get a ready-to-paste announcement listing each participant's weekday, local time and UTC offset. Copy share link sends the whole lineup, frozen at your chosen moment, to anyone. Calendly and Google Calendar both handle scheduling but neither shows you the colour-coded overlap the way a side-by-side time grid does.

Daylight saving time handled automatically

Most manual conversion mistakes are DST mistakes: the US–India gap is 10.5 hours in January but 9.5 in July; the UK leaves GMT for BST each spring; and the US and Europe switch on different weeks. This converter computes every time from city + date using the IANA time zone database built into your browser, so offsets — including half-hour zones like IST (UTC+5:30) and Nepal's UTC+5:45 — are always correct for the date you select.

That's also why you should plan with cities, not abbreviations: 'EST' written in July is usually wrong by an hour, while 'New York' never is. Pick the date of the meeting — not today — and the strips reflect that day's offsets, not the current ones.

EST to IST, PST to EST, GMT to UTC — common pairs at a glance

Frequent pairs become one glance: EST to IST is +10:30 (9 AM New York = 7:30 PM Kolkata in winter), PST to EST is +3 (noon Los Angeles = 3 PM New York), London is +5 on New York for most of the year, and Tokyo is +13/+14 depending on US DST. Add any pair of cities and the strip lays the whole day side by side — including date-line crossings where a '+1 day' badge appears.

For remote teams, anchoring on UTC is the cleanest habit: state the meeting once in UTC, then let each person read their own row. Aim for at least ~4 hours of overlapping working time per day for close collaboration, and rotate the awkward slot when there's no clean window that suits everyone.

Free, unlimited and private — no upload, no account

Popular tools cap the free tier. World Time Buddy limits free users to 4 locations before asking for payment. Savvy Time requires an account to save your setup. Here everything is free and runs live: unlimited cities, slider scrubbing, click-to-set hours, share links and the meeting announcement copier.

The whole planner runs client-side — your city list never leaves your device, and once loaded it works offline too. There's nothing to sign up for and no data is sent to a server. For a freelancer quoting a call time to a client abroad, a remote engineering team on three continents, or anyone checking what time it is in Tokyo before calling — the answer is one glance.

How time zones actually work: UTC, offsets, and the IANA database

UTC (Coordinated Universal Time) is the global clock that every other time zone is measured against. It replaced GMT (Greenwich Mean Time) as the international standard in 1960, when the adoption of atomic clocks made it possible to keep time to within a few billionths of a second per day — far beyond what GMT's solar-noon definition could guarantee. GMT is still used as a time zone name in the UK during winter, but when engineers and standards bodies need an unambiguous reference, they say UTC.

Every named time zone is expressed as a UTC offset — a signed number of hours (and sometimes minutes) added to or subtracted from UTC to get local civil time. New York in winter is UTC−5; Tokyo is UTC+9. Offsets alone are not enough, however, because the same offset can apply to different regions with different daylight saving rules — and those rules change when governments decide to change them. That is why the IANA Time Zone Database (also called tzdata or the Olson database) was created. It assigns a unique identifier — such as America/New_York or Asia/Kolkata — to every combination of offset history and DST rule. Every major operating system, programming language runtime, and web browser ships a copy of this database and updates it whenever a government changes its clocks.

The practical consequence is that abbreviations like EST or IST are ambiguous. 'IST' refers to India Standard Time, Israel Standard Time, and Irish Standard Time — three zones with different offsets. 'EST' is Eastern Standard Time in the US, but also the winter time of several Caribbean nations that never shift for DST. Using the IANA identifier instead — America/New_York, Asia/Kolkata, Europe/Dublin — removes any ambiguity, because each identifier maps to exactly one set of historical and future rules.

Daylight saving time: history, politics, and the programmer's nightmare

Daylight saving time (DST) was first introduced during World War I, when Germany and Austria began advancing their clocks by one hour in April 1916 to reduce coal consumption for artificial lighting. Britain followed weeks later. The practice spread, fell out of use after the war, revived during World War II, and then became institutionalised in many countries during the energy crises of the 1970s. The core idea is to shift an hour of daylight from the early morning — when most people sleep — to the evening, when people are active and using electricity.

In the United States, clocks spring forward one hour on the second Sunday in March and fall back on the first Sunday in November, a schedule that has been in place since the Energy Policy Act of 2005. Arizona (except the Navajo Nation) and Hawaii do not observe DST at all — Arizona because its desert heat makes extended evening daylight an active burden rather than a benefit. In Europe, the last Sunday of March and the last Sunday of October are the transition dates. The EU voted in 2019 to abolish the biannual clock change, allowing each member state to choose a permanent standard or summer time, but as of mid-2026 the directive has still not been implemented due to coordination disagreements. The majority of the world — most of Asia, Africa, South America, and nearly all equatorial regions — does not observe DST at all, because the seasonal variation in sunrise and sunset is small near the equator.

For software developers, DST is a perennial source of bugs. The transition from standard to daylight time creates a gap: in New York on the second Sunday in March, clocks jump from 1:59 AM directly to 3:00 AM, so 2:30 AM does not exist. The autumn transition creates an overlap: clocks fall from 1:59 AM back to 1:00 AM, so 1:30 AM occurs twice. Scheduling software that stores times as local wall-clock strings instead of UTC will misfire during these windows — producing duplicate calendar alerts, double-billing on payment systems, or dropped jobs in cron schedulers. The universal fix is to store everything in UTC and convert to local time only at the moment of display.

Half-hour and 45-minute offsets: why some zones don't fall on the hour

Most people assume time zones change in whole-hour steps, but about 15% of the world's population lives in a zone with a fractional offset. The most populous example is India Standard Time (IST, UTC+5:30), which covers the entire subcontinent — roughly 1.4 billion people in a single zone offset by 30 minutes. A unified zone was introduced under British colonial administration in 1905 and retained after independence because splitting the country across two whole-hour zones would have placed the east–west midline through densely populated regions, creating unnecessary complexity. Sri Lanka (UTC+5:30), Iran (UTC+3:30), and Afghanistan (UTC+4:30) each use 30-minute offsets for similar geographic and political reasons.

Nepal Standard Time (NPT, UTC+5:45) is the only 45-minute offset zone in the world. It was set in 1986 to differentiate Nepal from both India (UTC+5:30) and China (UTC+8:00), emphasising national independence. The Chatham Islands, a territory of New Zealand, sit at UTC+12:45 (UTC+13:45 during their summer DST), making them the easternmost inhabited time zone on Earth. The Marquesas Islands (UTC−9:30) in French Polynesia are another 30-minute outlier in the Pacific.

For anyone doing arithmetic by hand, fractional zones are trap. Adding 5:30 to 09:30 UTC gives 15:00 IST — easy enough. But subtracting IST from EDT (UTC−4) means the gap is 9 hours and 30 minutes in summer, not a round number. Converters that compute from named IANA zones handle all of this invisibly, which is why using a tool rather than a lookup table is particularly valuable when one of the cities involved is Kolkata, Tehran, Kabul, or Kathmandu.

Programming with time zones: store UTC, display local

The single most important rule in software timekeeping is: store every timestamp in UTC, convert to local time only at the moment of display. Violating this rule is the root cause of the overwhelming majority of time zone bugs in production systems. JavaScript's new Date() constructor, when given a date string without an explicit offset, interprets it in the local time of the machine running the code — which means the same string produces a different instant in UTC depending on where the server is hosted. The safe alternative is to always use ISO 8601 format with an explicit UTC designator: 2024-06-20T14:30:00Z, where the trailing Z unambiguously signals UTC.

At the lowest level, most systems store time as a Unix timestamp: the number of seconds elapsed since 1970-01-01T00:00:00Z (the Unix epoch). Unix timestamps are always in UTC by definition and are safe to compare, sort, and do arithmetic on without any zone knowledge. The well-known Year 2038 problem arises because legacy systems store Unix timestamps as signed 32-bit integers, which overflow on 2038-01-19T03:14:07Z. Modern systems use 64-bit integers, which push the overflow date billions of years into the future.

Language ecosystems have evolved significantly to address these pitfalls. Java's original java.util.Date and Calendar classes had deeply confusing APIs — Date stored milliseconds since the epoch but its getYear() method returned years since 1900 — and were replaced in Java 8 by the java.time package, which provides distinct types for Instant (a UTC moment), LocalDateTime (a date-time with no zone), ZonedDateTime (a date-time with a full IANA zone), and ZoneOffset. In Python, the standard library's datetime.now() returns a naive datetime with no zone information; best practice is to call datetime.now(timezone.utc) or use the zoneinfo module (added in Python 3.9) instead of the third-party pytz, which has a subtly non-standard localize() API that confuses new users. Across all platforms, the lesson is the same: be explicit about zones at every boundary — when reading user input, when writing to a database, and when formatting for display.