Convertisseur de fuseaux horaires, gratuit

Convertissez l'heure entre les fuseaux horaires du monde entier.

Aucune donnée ne quitte votre appareil

Comment utiliser

  1. Sélectionnez deux fuseaux horaires ou plus dans les listes déroulantes.
  2. Saisissez une date et une heure dans n'importe quelle colonne de fuseau horaire, ou cliquez sur « Utiliser l'heure actuelle ».
  3. L'heure se met à jour automatiquement dans tous les fuseaux avec les décalages UTC affichés.
  4. Cliquez sur « + Ajouter un fuseau horaire » pour comparer plusieurs fuseaux à la fois.

Questions fréquentes

Qu'est-ce qu'un décalage UTC ?

Le décalage UTC indique le nombre d'heures qu'un fuseau horaire a en avance (positif) ou en retard (négatif) par rapport au Temps Universel Coordonné (UTC). Par exemple, EST est UTC−5.

Et si je saisis une heure dans un fuseau horaire ?

Le convertisseur calcule et affiche automatiquement l'heure équivalente dans tous les autres fuseaux horaires sélectionnés.

L'heure d'été est-elle prise en compte ?

Oui. Le convertisseur utilise la base de fuseaux horaires de votre navigateur, qui inclut les règles d'heure d'été pour les régions prises en charge.

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:

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 offsetCommon nameMajor cities
UTC−10:00HSTHonolulu (no DST)
UTC−08:00 / −07:00PST / PDTLos Angeles, San Francisco, Vancouver, Seattle, Tijuana
UTC−05:00 / −04:00EST / EDTNew York, Toronto, Atlanta, Miami, Bogotá (no DST), Lima
UTC−03:00BRT / ARTSão Paulo, Buenos Aires, Santiago (varies)
UTC+00:00 / +01:00GMT / BSTLondon, Lisbon, Dublin, Reykjavík (no DST)
UTC+01:00 / +02:00CET / CESTParis, Berlin, Madrid, Rome, Amsterdam, Warsaw
UTC+03:00MSK / ASTMoscow (no DST), Riyadh, Doha, Nairobi
UTC+05:30ISTMumbai, New Delhi, Bangalore, Colombo (no DST, half-hour offset)
UTC+08:00CST / HKT / SGTBeijing, Shanghai, Hong Kong, Singapore, Manila, Perth
UTC+09:00JST / KSTTokyo, Seoul (no DST)
UTC+10:00 / +11:00AEST / AEDTSydney, Melbourne, Brisbane (no DST in QLD)
UTC+12:00 / +13:00NZST / NZDTAuckland, 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:

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

Common Use Cases

Common Mistakes

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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)."

Outils associés

Horloge mondiale, gratuite Convertisseur de timestamp Unix, gratuit Calculatrice de dates, gratuite