मुफ़्त टाइमज़ोन कनवर्टर
दुनिया भर के टाइम ज़ोन के बीच समय कनवर्ट करें।
कैसे उपयोग करें
- ड्रॉप-डाउन से दो या अधिक टाइमज़ोन चुनें।
- किसी भी टाइमज़ोन कॉलम में तारीख़ और समय दर्ज करें।
- समय अन्य सभी टाइमज़ोन में स्वचालित रूप से अपडेट हो जाता है, UTC ऑफ़सेट दिखाए जाते हैं।
- एक साथ कई टाइमज़ोन की तुलना करने के लिए "+ टाइमज़ोन जोड़ें" पर क्लिक करें।
अक्सर पूछे जाने वाले प्रश्न
UTC ऑफ़सेट क्या है?
UTC ऑफ़सेट बताता है कि कोई टाइमज़ोन UTC से कितने घंटे आगे (पॉज़िटिव) या पीछे (निगेटिव) है।
यदि मैं एक टाइमज़ोन में समय दर्ज करूँ तो क्या होगा?
कन्वर्टर स्वचालित रूप से अन्य सभी टाइमज़ोन में समतुल्य समय गणना और प्रदर्शित करता है।
क्या डेलाइट सेविंग टाइम का ध्यान रखा जाता है?
हाँ। कन्वर्टर आपके ब्राउज़र के टाइमज़ोन डेटाबेस का उपयोग करता है, जिसमें DST नियम शामिल हैं।
UTC, GMT, and Why You Want IANA Names
UTC (Coordinated Universal Time) is the global time standard, defined relative to International Atomic Time with periodic leap-second adjustments. GMT (Greenwich Mean Time) is technically a time zone (UTC+00:00) historically tied to the Royal Observatory in Greenwich, London. The two are casually used interchangeably; technically UTC is the standard everyone synchronises to.
For unambiguous time-zone identification, the standard is the IANA Time Zone Database (TZDB), originally created by Arthur David Olson at the US National Institutes of Health in 1986 and now maintained by the IANA. Its naming format is Region/City: America/New_York, Europe/Paris, Asia/Tokyo, Australia/Sydney. The city is the largest city in the zone or a distinctive locality. The TZDB updates several times per year as countries change DST rules, and every modern operating system, programming language, and major web browser bundles a recent copy.
This converter uses the IANA database baked into your browser via the JavaScript Intl.DateTimeFormat API, so DST transitions, regional rule changes, and historical edge cases are handled correctly without you having to think about them.
Time-Zone Abbreviations Are Ambiguous
Three-letter abbreviations like "CST" and "IST" look unambiguous but aren't:
- CST can mean US Central Standard Time (UTC−06:00), China Standard Time (UTC+08:00), or Cuba Standard Time (UTC−05:00).
- IST can mean India Standard Time (UTC+05:30), Israel Standard Time, or Irish Standard Time.
- EST usually means US Eastern Standard Time (UTC−05:00), but Australian Eastern Standard Time (UTC+10:00) shares the abbreviation.
When you really need to communicate a time precisely, use the IANA name (America/Chicago vs Asia/Shanghai vs Asia/Kolkata) or include both the offset and the city. The converter labels each column with the IANA zone so the meeting time is unambiguous.
Common Time Zones at a Glance
| UTC offset | Common name | Major cities |
|---|---|---|
| UTC−10:00 | HST | Honolulu (no DST) |
| UTC−08:00 / −07:00 | PST / PDT | Los Angeles, San Francisco, Vancouver, Seattle, Tijuana |
| UTC−05:00 / −04:00 | EST / EDT | New York, Toronto, Atlanta, Miami, Bogotá (no DST), Lima |
| UTC−03:00 | BRT / ART | São Paulo, Buenos Aires, Santiago (varies) |
| UTC+00:00 / +01:00 | GMT / BST | London, Lisbon, Dublin, Reykjavík (no DST) |
| UTC+01:00 / +02:00 | CET / CEST | Paris, Berlin, Madrid, Rome, Amsterdam, Warsaw |
| UTC+03:00 | MSK / AST | Moscow (no DST), Riyadh, Doha, Nairobi |
| UTC+05:30 | IST | Mumbai, New Delhi, Bangalore, Colombo (no DST, half-hour offset) |
| UTC+08:00 | CST / HKT / SGT | Beijing, Shanghai, Hong Kong, Singapore, Manila, Perth |
| UTC+09:00 | JST / KST | Tokyo, Seoul (no DST) |
| UTC+10:00 / +11:00 | AEST / AEDT | Sydney, Melbourne, Brisbane (no DST in QLD) |
| UTC+12:00 / +13:00 | NZST / NZDT | Auckland, Wellington |
Half-Hour and Quarter-Hour Offsets
Not every time zone is a whole number of hours from UTC. India, Sri Lanka (UTC+05:30), Iran (UTC+03:30 / +04:30), Afghanistan (UTC+04:30), and Myanmar (UTC+06:30) all use half-hour offsets. Nepal sits at UTC+05:45, and the Chatham Islands of New Zealand at UTC+12:45 / +13:45. These half- and quarter-hour offsets matter mostly for software developers, many older systems assumed whole-hour offsets and silently break on Indian or Nepali times. The IANA database handles them all correctly; the converter inherits that.
Daylight Saving Time
Daylight Saving Time (DST) was first proposed by William Willett's 1907 pamphlet "The Waste of Daylight" and first formally adopted by Germany in 1916 to save coal during World War I. Today it varies wildly by jurisdiction:
- United States: DST runs from the second Sunday of March to the first Sunday of November (Energy Policy Act of 2005). Hawaii and most of Arizona do not observe it.
- European Union: DST runs from the last Sunday of March to the last Sunday of October. The EU Parliament voted in 2019 to abolish seasonal clock changes EU-wide; implementation has been indefinitely delayed and most member states still observe DST.
- Doesn't observe DST: most of Africa, most of Asia, most of South America (Brazil scrapped it in 2019), Russia (since 2014), Iceland, Hawaii, most of Arizona, India, China, Japan, South Korea, Turkey.
The converter accounts for the DST rules of each IANA zone, so a meeting set for 9 AM in America/New_York on a January date converts as EST (UTC−05:00); the same 9 AM in July converts as EDT (UTC−04:00).
DST Gotchas in Software
- "Spring forward": local clocks jump from 02:00 to 03:00, so the hour 02:00–02:59 doesn't exist locally. Cron jobs scheduled in that window run immediately after the jump on Linux Vixie cron, but are skipped entirely by AWS EventBridge.
- "Fall back": 02:00 to 01:00 happens twice. Events in the duplicated hour can fire twice or not at all depending on the scheduler. Linux Vixie does not re-run; AWS EventBridge runs only once.
- Calendar invites that span a DST boundary need the time-zone explicitly attached, not just the local time. ICS files include a
TZIDfor this reason; sending plain "9 AM ET" via email when the recipient's calendar straddles a DST flip will silently shift by an hour.
Common Use Cases
- Scheduling meetings across continents: when does 9 AM PST become for someone in Tokyo or Berlin? When is everyone in office hours simultaneously?
- Coordinating product launches that should "go live at midnight everywhere" or "9 AM in your local time."
- Reading server logs in your local time when the server is set to UTC (the modern best practice for cloud servers).
- Travel planning: what time will I land local? When does my flight depart in the destination's time?
- Coordinating with international clients without making time-zone math mistakes via mental arithmetic.
- Live-event scheduling: game streams, webinars, sports broadcasts that need a single "is this on now?" answer for a global audience.
Common Mistakes
- Confusing "EST" with "EDT" (or any standard / daylight pair). The same meeting on March 1 vs March 31 in New York is at a different UTC offset.
- Using "GMT" to mean "UK time". The UK observes British Summer Time (BST, UTC+01:00) from late March to late October; only winter is GMT.
- Assuming a city has a fixed UTC offset. Russia, Samoa, Egypt, and others have all changed their offsets in the last 15 years. The IANA database tracks history; lookups by city name and date stay correct.
- Sending invites in three-letter abbreviations. "9 AM CST" is genuinely ambiguous between Chicago (UTC−06:00) and Shanghai (UTC+08:00), a 14-hour difference. Use IANA names or include the offset.
- Forgetting Arizona, Hawaii, Saskatchewan, Indiana. These places either don't observe DST or do so partially. Generic "Mountain Time" or "Central Time" mappings break for half the year.
- Picking a meeting in a hour that doesn't exist. An invite for 02:30 local time on the spring-forward date is in a non-existent hour. The calendar usually shifts it silently; some systems error.
More Frequently Asked Questions
Why are some offsets in half hours?
Historical and political reasons. India settled on UTC+05:30 partly to compromise between the country's east and west extents; Iran, Afghanistan, Myanmar, and a handful of others use similar half-hour offsets. Nepal goes one further and uses UTC+05:45. There's no rule that time zones have to be on whole-hour boundaries, they're whatever each jurisdiction has chosen.
How does the converter handle DST transitions?
Automatically. The browser's IANA database includes every region's DST rules, including historical ones. A time set in Europe/Berlin on a date in summer correctly converts using CEST (UTC+02:00); the same local time in winter converts using CET (UTC+01:00).
Which time zones can I add?
All IANA time zones the browser knows about, typically 400+ zones covering every populated region. The dropdown is populated from the browser's Intl.supportedValuesOf('timeZone') at page load, so it stays current with whatever your operating system has installed.
Is my converted time sent anywhere?
No. The conversion happens entirely in your browser using the built-in JavaScript date and time-zone APIs. Nothing about your meeting times, locations, or selected zones is transmitted, logged, or stored on any server.
Why does the meeting time shift around DST?
Because some zones observe DST and others don't. A 9 AM Pacific meeting hits 12 PM Eastern in winter (both on standard time) but the same 9 AM Pacific stays at 12 PM Eastern in summer (both on DST). However, a 9 AM Pacific meeting hits 1 AM the next day in Tokyo year-round, Tokyo doesn't observe DST, so the difference between LA and Tokyo shifts by an hour twice a year.
What's the safest way to share a meeting time?
Send a calendar invite (.ics file or via Google / Outlook / iCloud Calendar) with the time-zone explicitly attached. The recipient's calendar then renders the time in their local zone, automatically accounting for DST on both ends. If you must send a time in plain text, include both the IANA zone and the offset: "Tuesday 14:00 Europe/Berlin (UTC+01:00)."