Time Zone Calculator
Time Zone Converter
The Earth is divided into 24 primary longitudinal time zones, each spanning approximately 15 degrees of longitude. All time zones are defined relative to Coordinated Universal Time (UTC), the international time standard maintained by the International Bureau of Weights and Measures (BIPM). Time zone offsets are expressed as differences from UTC — for example, UTC+3 for Moscow, or UTC-5 for New York during standard time. [timeanddate-tz]
Some regions use fractional offsets such as UTC+5:30 (India) or UTC+9:30 (central Australia). Additionally, many countries observe Daylight Saving Time (DST), shifting clocks forward by one hour during summer months. DST rules vary by country — some start on different dates, some do not observe it at all, and a few have abandoned it entirely.
This calculator converts any given date and time from one time zone to another. It uses the IANA Time Zone Database to determine correct UTC offsets and automatically adjusts for DST when a specific date is provided. Typical use cases include scheduling international conference calls, planning travel itineraries, and coordinating remote team workflows.
Time zone management has become increasingly critical in the era of global remote work and distributed teams. A company with offices in New York, London, and Tokyo needs to find meeting times that are reasonable for all participants — typically requiring someone to start early or stay late. The global shift to remote work has accelerated this challenge, with teams often spanning 6-12 time zones. Misunderstandings about time zone differences are one of the most common sources of missed meetings and scheduling conflicts in international business, making reliable time zone conversion tools essential infrastructure for modern organizations.
The IANA Time Zone Database, also known as the Olson database, is the global standard for time zone information. Maintained by volunteers and coordinated by the Internet Assigned Numbers Authority (IANA), this database contains the history of time zone changes for every region of the world, including DST start and end dates, offset changes, and even historical variations before standardized time zones were adopted. Governments periodically change their DST rules or time zone boundaries — for example, Russia, Turkey, and Brazil have all made recent changes. Using the IANA database ensures that this calculator reflects the most current information available at the time of its release.
While the Earth is nominally divided into 24 time zones, there are actually more than 40 distinct time zone offsets in use today. This is because some regions use quarter-hour or half-hour offsets — Nepal uses UTC+5:45, and the Chatham Islands use UTC+12:45 during standard time and UTC+13:45 during DST. Additionally, DST effectively creates temporary time zones that exist only during summer months. When all current DST and non-DST offsets are counted, the total number of unique time zone representations exceeds 50. This complexity is precisely why a dedicated conversion tool is far more reliable than attempting to memorize offsets or relying on mental math for critical international coordination.
- Select source time zone — choose from a searchable list of major cities and IANA identifiers.
- Enter the date and time — including the date is essential for correct DST application.
- Select target time zone — the calculator shows the time difference between the two zones.
- View the result — equivalent date and time in the target zone, along with the time difference.
- Meeting planner (optional) — shows overlapping business hours across selected zones.
Including the Date is Critical: DST status depends on the specific date, not just the time of day. A meeting scheduled at 10:00 AM in New York on March 10 may be at 15:00 UTC, while the same 10:00 AM meeting on March 20 may be at 14:00 UTC due to DST transitions. Always enter the full date for accurate conversion results. The calculator cannot determine DST correctly from a time-only entry and will assume standard time in that case.
Using the Meeting Planner Feature: Select the time zones of all participants and review the overlapping business hours chart. The ideal meeting time falls within the 9:00 AM to 5:00 PM window for as many participants as possible. For teams spanning more than 5 time zones, finding any overlap may be challenging, and rotating meeting times or alternating between early and late slots can distribute the inconvenience more equitably among team members.
Step 1: Convert source local time to UTC
t_UTC = t_local - O_source, where O_source is the UTC offset of the source zone.
Step 2: Convert UTC to target local time
t_target = t_UTC + O_target
Daylight Saving Time adjustment
When a date is provided, the offset O equals O_standard if outside DST, or O_standard + 1h if within DST period.
UTC vs GMT — Key Differences
Coordinated Universal Time (UTC) and Greenwich Mean Time (GMT) are often used interchangeably, but they are not identical. GMT is a time zone, observed in the United Kingdom and some West African countries during standard time. UTC is a time standard — the primary reference by which all other time zones are defined. The key practical difference is that GMT observes DST (becoming BST, British Summer Time, UTC+1), while UTC never changes. UTC has no DST and remains constant year-round.
In contexts where GMT is referenced purely as UTC+0 without DST transitions — such as Iceland or parts of West Africa — GMT and UTC are effectively equivalent. However, referring to "GMT" during the UK summer is technically incorrect; the UK observes BST (UTC+1) from late March to late October. When scheduling meetings that involve the United Kingdom, be aware that the offset changes twice a year, and using the term "GMT" for a July meeting will introduce confusion.
For aviation, maritime, and scientific purposes, UTC is the universal standard. The military and aviation designation for UTC is "Zulu time," indicated by the suffix Z. When you see a notation like "14:00Z" in flight schedules or weather reports, it means 14:00 UTC. This convention eliminates ambiguity when coordinating across multiple time zones and is particularly critical for air traffic control, where a single reference time prevents scheduling conflicts across international borders.
Time Zone Abbreviations — A Deeper Look
Time zone abbreviations are widely used but surprisingly ambiguous. The same three-letter abbreviation can refer to completely different time zones in different parts of the world. The table below illustrates some of the most commonly confused abbreviations:
| Abbreviation | Full Name | Location | UTC Offset |
|---|---|---|---|
| EST | Eastern Standard Time | North America | UTC-5 |
| EST | Eastern Standard Time | Australia | UTC+10 |
| CST | Central Standard Time | North America | UTC-6 |
| CST | China Standard Time | China | UTC+8 |
| IST | India Standard Time | India | UTC+5:30 |
| IST | Israel Standard Time | Israel | UTC+2 |
| IST | Irish Standard Time | Ireland | UTC+1 |
| PST | Pacific Standard Time | North America | UTC-8 |
| PST | Philippine Standard Time | Philippines | UTC+8 |
The IANA database identifiers used by this calculator avoid this ambiguity entirely. For example, America/New_York uniquely identifies the Eastern time zone as observed in New York, including its specific DST transition rules and historical changes. Similarly, America/Los_Angeles and Australia/Sydney are unambiguous even though all three could be loosely referred to as "Pacific time" in different contexts. When scheduling international meetings, prefer IANA identifiers or explicit UTC offsets over three-letter abbreviations. A meeting invitation that specifies "14:00 UTC (America/New_York: 10:00 EST, Australia/Sydney: 01:00 AEDT next day)" is fully unambiguous — every participant knows the exact time regardless of which time zone conventions they are familiar with.
Major City Time Zone Offsets
| City | Time Zone | Standard UTC Offset | Observes DST |
|---|---|---|---|
| London (UK) | GMT/BST | UTC+0 | Yes (+1h summer) |
| New York (USA) | EST/EDT | UTC-5 | Yes (+1h summer) |
| Los Angeles (USA) | PST/PDT | UTC-8 | Yes (+1h summer) |
| Berlin (Germany) | CET/CEST | UTC+1 | Yes (+1h summer) |
| Moscow (Russia) | MSK | UTC+3 | No |
| Dubai (UAE) | GST | UTC+4 | No |
| New Delhi (India) | IST | UTC+5:30 | No |
| Beijing (China) | CST | UTC+8 | No |
| Tokyo (Japan) | JST | UTC+9 | No |
| Sydney (Australia) | AEST/AEDT | UTC+10 | Yes (+1h summer) |
| Auckland (NZ) | NZST/NZDT | UTC+12 | Yes (+1h summer) |
| São Paulo (Brazil) | BRT/BRST | UTC-3 | Yes (+1h summer) | | Istanbul (Turkey) | TRT | UTC+3 | No | | Seoul (South Korea) | KST | UTC+9 | No |
DST Transition Dates for Major Regions
| Region | DST Start (Spring Forward) | DST End (Fall Back) |
|---|---|---|
| European Union | Last Sunday of March | Last Sunday of October |
| United States | Second Sunday of March | First Sunday of November |
| United Kingdom | Last Sunday of March | Last Sunday of October |
| Australia (most states) | First Sunday of October | First Sunday of April |
| New Zealand | Last Sunday of September | First Sunday of April |
These transition dates are the general rules as of 2026, but individual countries within each region may deviate. Always verify the specific DST rules for the exact location and year you are converting, as governments occasionally modify their DST schedules with relatively short notice.
Double-Check DST Status: During transition periods, the time difference may differ by one hour from what you expect because not all regions switch on the same date.
Use UTC for Scheduling: For recurring international events, schedule in UTC and let each participant calculate their local time.
Account for DST Transition Effects: Be aware that during spring-forward DST transitions (typically March), the day is only 23 hours long, and during fall-back (November), the day is 25 hours long. This affects scheduling in the week before and after transitions when different regions may switch on different dates. When scheduling a recurring meeting across DST transitions, double-check that the scheduled time remains correct for all participants, as the UTC offset difference may change by one hour compared to the previous month.
Use Time Zone Abbreviations with Caution: Time zone abbreviations like EST, PST, and CET are ambiguous. For example, EST can mean Eastern Standard Time in North America (UTC-5) or Eastern Standard Time in Australia (UTC+10). Similarly, IST can mean India Standard Time (UTC+5:30), Israel Standard Time (UTC+2), or Irish Standard Time (UTC+1). This calculator uses IANA time zone identifiers (like America/New_York, Asia/Kolkata) which are unambiguous and always associated with the correct geographic location and its specific DST rules.
Be Aware of Hemisphere Differences in DST: In the Northern Hemisphere, DST typically runs from March to October or November. In the Southern Hemisphere, DST runs from October to March. This means that when it is summer in Australia, it is winter in the United Kingdom, and the DST periods are six months out of phase. The time difference between Sydney and London varies by two hours over the course of the year because each region enters and exits DST at opposite times. Always verify DST status for both hemispheres when converting between a location in the Northern Hemisphere and one in the Southern Hemisphere.
Scheduling Across Multiple Time Zones
When coordinating meetings across four or more time zones, the overlap of standard business hours (9:00 AM to 5:00 PM local time) often shrinks to two or three hours. To maximize participation, start by identifying the business hours overlap of all required time zones. For example, a team spanning San Francisco (UTC-8), New York (UTC-5), London (UTC+0), and Sydney (UTC+10) has only a narrow window — Sydney's evening overlaps with New York's early morning and London's afternoon. In practice, the best meeting time might be 12:00 UTC, which falls at 4:00 AM in San Francisco (too early) but at 10:00 PM in Sydney (too late). There is rarely a perfect time that suits every participant, which is why rotating meeting times or alternating between early and late slots distributes the inconvenience equitably.
For asynchronous collaboration across time zones, establish clear response time expectations. Common approaches include the 24-hour rule (respond within one business day regardless of time zone differences) or the follow-the-sun model (hand off work to the next time zone at the end of each shift). Documenting each team member's working hours expressed as UTC offsets in a shared reference helps everyone plan when to expect responses and when synchronous discussion is necessary.
Programming Best Practices for Time Zone Handling
Software developers face unique challenges when working with time zones. The single most important rule is to store all timestamps in UTC and convert to local time only for display. Storing timestamps with local time offsets is fragile because DST changes and government policy decisions can retroactively alter the meaning of historical offsets — a timestamp stored as "2026-01-15 14:00:00 EST" becomes ambiguous if the region later changes its DST rules or time zone boundaries.
When choosing a programming library for time zone operations, prefer established solutions built on the IANA Time Zone Database. In JavaScript, the Temporal API provides proper time zone support in modern environments, and the Luxon library offers a robust alternative to the legacy Date object. Python developers should use zoneinfo (Python 3.9+) or pytz. Java includes java.time with ZoneId and ZonedDateTime since Java 8. In databases, PostgreSQL's TIMESTAMP WITH TIME ZONE type stores timestamps in UTC internally and converts to the session time zone for display, making it the recommended choice for applications serving users across multiple time zones.
Always test time zone logic around DST transition dates, particularly the spring-forward gap (the missing hour) and fall-back overlap (the repeated hour). These edge cases are where most time zone bugs occur in production systems. Write unit tests that explicitly verify behavior on DST transition dates for all time zones your application supports.
- DST rule changes: Governments occasionally change DST rules. May not reflect very recent policy changes.
- Historical data: Time zone rules before 1970 are incompletely recorded.
- Fractional offsets: Some less common offsets may require manual verification.
- Date dependency: Correct result depends on providing a specific date for DST lookup.
Why Time Zone Conversions Are Not Always Precise
Several factors can affect the accuracy of time zone conversions beyond the control of any calculator tool. Political decisions about DST observance can change with little notice — for example, in 2022, Mexico abolished DST for most of the country, and several US states have proposed legislation to adopt permanent DST or permanent standard time. These changes require updates to the IANA database, and the calculator may not reflect very recent or unannounced changes. Always verify critical time conversions against official sources, particularly for dates near DST transition boundaries.
Historical time zone conversions before the standardization of time zones in the late 19th and early 20th centuries are inherently approximate. Before standard time zones were adopted, cities set their clocks based on local solar time, which could vary by several minutes between neighboring towns. Railroads drove the adoption of standard time zones in the 1880s, but many regions did not adopt them until much later. The IANA database includes historical time zone data from 1970 onward with reasonable completeness, but earlier dates may be incomplete or based on interpolation. For genealogical and historical research, specialized tools with more comprehensive historical data may be more appropriate.
Common Time Zone Conversion Mistakes
One of the most frequent errors in time zone conversion is confusing the direction of the offset sign. A positive UTC offset (UTC+3) means the local time is ahead of UTC, so when it is 12:00 UTC, it is 15:00 in Moscow. A negative offset (UTC-5) means local time is behind UTC, so when it is 12:00 UTC, it is 07:00 in New York. The formula is: local time = UTC + offset. Many people invert this relationship and end up with a result that is off by twice the actual offset.
Another common mistake is assuming that the time difference between two zones remains constant throughout the year. For example, during winter, London (UTC+0) and New York (UTC-5) differ by 5 hours. During summer, London shifts to BST (UTC+1) while New York shifts to EDT (UTC-4), reducing the difference to 4 hours. The difference changes by one hour because both regions observe DST but their transition dates may not align. If you remember the difference from one season and apply it in another without checking DST status, your conversion will be off by one hour.
A third common mistake is forgetting that dates can change when crossing time zones. A flight departing Tokyo at 10:00 PM JST (UTC+9) on a Monday and flying east to Los Angeles arrives at 4:00 PM PST (UTC-8) on the same Monday — the flight effectively "arrives before it departed" in local time due to crossing the International Date Line. Always verify that the date in the converted time zone is correct and not just the time.
- Why does the time difference between two zones sometimes change?
- It changes when one region observes DST and the other does not, or when they switch on different dates.
- How do time zones work for China and India?
- China uses a single time zone (UTC+8) nationwide despite spanning five geographic zones. India uses UTC+5:30.
- What is the International Date Line?
- An imaginary line at the 180th meridian where the date changes by one day when crossed.
- How do I convert times during DST transition periods?
- During spring-forward, the hour from 2:00 AM to 3:00 AM does not exist. During fall-back, the hour from 1:00 AM to 2:00 AM occurs twice.
- Which countries have recently changed their time zone or DST policies?
- In 2022, Mexico abolished DST nationwide except for border municipalities. In 2023, Egypt reinstated DST after a 10-year hiatus. Ukraine suspended DST in 2024. Jordan, Syria, and Iran have made multiple changes to their DST schedules in recent years. These ongoing changes highlight the importance of using a time zone database that is regularly updated, as well as verifying critical time conversions through official government sources.
- How do I handle time zones in software development?
- Store all timestamps in UTC and convert to local time only for display. Never store timestamps with local time offsets because DST changes and political decisions can make historical data ambiguous. Use established time zone libraries like Luxon (JavaScript), pytz (Python), or Joda-Time (Java) that are built on the IANA database rather than writing custom time zone logic. Always include the date when recording or processing time zone conversions, as the offset from UTC depends on the date.
- What is the difference between UTC and GMT?
- UTC is a time standard, not a time zone; GMT is a time zone used in the UK and parts of Africa. UTC never observes DST and does not change, while GMT is subject to DST in the UK (becoming BST). In practice, GMT during winter is equivalent to UTC+0, but the two terms are not interchangeable during summer months when the UK switches to BST.
- How do I schedule a recurring meeting across multiple time zones?
- Schedule the meeting in UTC and include a link to a time zone converter in every calendar invitation. Use meeting planner tools that show the business hour overlap between time zones. For teams spanning more than four time zones, rotate meeting times weekly or use a follow-the-sun handoff model instead of synchronous meetings whenever possible.
- What are the most common mistakes when converting time zones?
- The three most common mistakes are: confusing the direction of the UTC offset — a positive offset means local time is ahead, not behind; assuming the time difference between two zones stays constant year-round, which fails when one region observes DST and the other does not; and forgetting that crossing the International Date Line changes the date, not just the time.
- How does the International Date Line affect travel?
- When crossing the International Date Line from east to west, you advance one day forward (losing a calendar day). When crossing from west to east, you go back one day (repeating a calendar day). The line is not straight along the 180th meridian — it deviates in several places to keep island nations on the same calendar day as their primary trading partners. Kiribati shifted the line in 1995 to ensure all its islands observed the same date.
- How should I handle time zones in databases?
- Always store timestamps in UTC using a column type that supports time zone awareness, such as PostgreSQL's TIMESTAMP WITH TIME ZONE. Convert to local time in the application layer at display time, not in the database. Never store timestamps as strings with time zone abbreviations like 'EST', as these become ambiguous when DST rules change. Store the IANA time zone identifier (e.g., 'America/New_York') alongside the UTC timestamp if the original time zone context must be preserved.
- [1]IANA Time Zone Database (tzdata). (n.d.). Retrieved from https://www.iana.org/time-zones.
- [2]ISO 8601:2004 — Data elements and interchange formats
- [3]NIST Time and Frequency Division. (n.d.). Retrieved from https://www.nist.gov/time-frequency.
- [4]BIPM. (n.d.). International Bureau of Weights and Measures.
- [5]Time and Date AS. (n.d.). Time Zones.
Last updated: July 10, 2026
UnByte — Independent Software Engineering
Every calculator references authoritative sources — Editorial policy