Convertir une date/heure entre deux fuseaux IANA avec gestion DST.
Utilise les données IANA tzdata de votre navigateur — les transitions DST sont correctement gérées. Pour un usage aéronautique/médical, vérifiez toujours auprès de la source officielle.
Planifier une réunion entre fuseaux horaires est la friction quotidienne du travail à distance. « Mardi à 16h Paris » est sans ambiguïté pour un Parisien et ambigu pour tous les autres : s'agit-il de l'heure d'été du Pacifique à 7h ou de l'heure d'hiver du Pacifique à 7h, selon qu'il s'agisse du printemps ou de l'automne ? L'heure d'été diffère entre les hémisphères (Sydney recule tandis que Paris avance) et au fil des décennies (en 2024, la majeure partie de l'Amérique du Sud a abandonné l'heure d'été). Le projet IANA tzdata maintient le mappage canonique de chaque fuseau horaire nommé à son historique de décalage, et chaque navigateur moderne embarque une copie locale qui gère les règles automatiquement. Ce calculateur est l'interface utilisateur de ces données : entrez une date, une heure locale et un fuseau horaire source ; choisissez un fuseau horaire de destination ; obtenez l'heure locale équivalente à la destination, plus le décalage entre les deux zones pour cet instant précis. Les 20 villes de la liste déroulante couvrent la majorité des réunions inter-fuseaux horaires : les principales capitales européennes, les zones continentales américaines, les quatre principaux centres d'affaires asiatiques, les villes d'affaires de l'hémisphère sud, et l'UTC comme référence sans ambiguïté.
Il n'existe pas de formule fermée — le calculateur s'appuie sur l'API Intl.DateTimeFormat du navigateur, qui a accès aux données tzdata d'IANA via le système d'exploitation. En interne : (1) Construire un instant UTC qui, interprété dans le fuseau horaire source, affiche l'heure locale spécifiée par l'utilisateur. Cela nécessite une petite boucle en deux passes : prendre les entrées comme si elles étaient en UTC, demander à Intl ce que la zone source affiche pour cet instant, calculer le décalage entre l'heure affichée et l'heure locale souhaitée, soustraire ce décalage pour trouver l'instant UTC réel. (2) Formater le même instant UTC dans la zone de destination en utilisant Intl.DateTimeFormat avec timeZone: <destination>. (3) Calculer la différence de décalage entre les deux zones pour cet instant précis — nécessaire car le décalage n'est pas fixe ; il varie avec l'heure d'été. Le résultat inclut le jour de la semaine, la date complète, l'heure et la minute, et l'abréviation de la zone (CET, EST, JST, etc.) pour plus de clarté.
Quatre entrées : date (sélecteur de date), heure (sélecteur d'heure 24h/24), fuseau horaire source (liste déroulante), fuseau horaire destination (liste déroulante). Valeurs par défaut : aujourd'hui à 14h30, Paris vers New York. Le panneau de résultats affiche l'heure source et l'heure de destination sous forme de deux grands indicateurs clés de performance (KPI) parallèles, et en dessous l'heure de référence UTC et le décalage entre les deux zones pour cet instant. La liste déroulante des 20 villes couvre l'Europe (Paris, Londres, Berlin, Moscou), les Amériques (New York, Chicago, Denver, Los Angeles, São Paulo), l'Afrique (Le Caire, Johannesburg), l'Asie (Dubaï, Mumbai, Pékin, Tokyo, Singapour, Séoul), l'Océanie (Sydney, Auckland), plus l'UTC. Ajoutez de nouvelles villes en modifiant la liste déroulante ; le mécanisme sous-jacent gère tout identifiant de fuseau horaire IANA.
Une équipe parisienne souhaite planifier un lancement avec sa contrepartie new-yorkaise le 15 mai 2026 à 14h30 heure de Paris. Source : 14h30 le 15 mai 2026 en Europe/Paris (CEST, UTC+2 en mai car l'heure d'été est en vigueur). Destination : America/New_York (EDT, UTC-4 en mai). Source vers UTC : 14h30 - 02h00 = 12h30 UTC. UTC vers destination : 12h30 + (-04:00) = 08h30 EDT. Donc 14h30 Paris = 08h30 New York le même jour, un décalage de 6 heures. Considérons maintenant le 15 janvier 2026 à 14h30 Paris (CET, UTC+1) → New York (EST, UTC-5). Source vers UTC : 14h30 - 01h00 = 13h30 UTC. UTC vers destination : 13h30 - 05h00 = 08h30 EST. Même conversion d'heure locale, mais seulement parce que Paris et New York sont tous deux à l'heure standard ; si Paris était passé à l'heure d'été et New York n'avait pas changé (une situation réelle fin mars chaque année), le décalage serait de 5 heures au lieu de 6. Le calculateur gère cela de manière transparente : l'utilisateur n'a pas besoin de suivre l'heure d'été dans deux zones ; la base de données IANA s'en charge pour lui. Un exemple plus frappant : le 15 décembre 2026 à 09h00 Sydney (AEDT, UTC+11) → Londres (GMT, UTC+0). Source vers UTC : 09h00 - 11h00 = -02h00 UTC, soit 22h00 la veille. Londres à 22h00 le 14 décembre — à travers la ligne de changement de date en termes de calendrier, 11 heures de décalage en termes d'horloge.
Premièrement, confondre le décalage UTC et le fuseau horaire. « UTC+1 » décrit le décalage ; « Europe/Paris » décrit le fuseau horaire. Paris est UTC+1 en hiver et UTC+2 en été. Le codage en dur de UTC+1 pour « l'heure française » entraîne une erreur d'une heure de fin mars à fin octobre. Deuxièmement, ignorer l'heure d'été. Paris et New York observent tous deux l'heure d'été, mais selon des calendriers différents : à la mi-mars, Paris est encore en CET (UTC+1) pendant deux semaines tandis que New York est déjà passé à l'EDT (UTC-4) ; le décalage est de 5 heures au lieu de 6 pendant cette période. Le calculateur gère cela ; les conversions manuelles se trompent généralement. Troisièmement, mélanger la notation 12 heures et 24 heures entre les cultures. Les États-Unis et le Royaume-Uni utilisent colloquiellement des horloges de 12 heures AM/PM ; l'Europe continentale utilise les 24 heures. Le sélecteur du calculateur est en 24 heures ; la sortie de destination utilise également les 24 heures pour éviter toute ambiguïté. Quatrièmement, planifier au-delà d'un passage de ligne de changement de date sans s'en rendre compte. Tokyo à 09h00 mardi correspond à San Francisco à 17h00 lundi — un décalage de 16 heures qui traverse le jour civil. Le calculateur affiche la date complète à la destination, pas seulement l'heure, pour rendre cela visible. Cinquièmement, considérer le convertisseur comme faisant autorité pour un usage juridique ou aéronautique. Le calculateur utilise les données tzdata du navigateur, qui sont mises à jour lorsque le système d'exploitation est mis à jour ; si l'utilisateur utilise un ancien système, les règles peuvent être obsolètes pour des changements récents d'heure d'été (par exemple, l'abolition de l'heure d'été par le Brésil en 2019, la suppression partielle de l'heure d'été par le Mexique en 2022). Pour les contextes contraignants, vérifiez toujours la source officielle.
Les fuseaux horaires sont un système politiquement fluide. Les changements d'heure d'été sont fréquents : l'UE débat de la fin de l'heure d'été depuis 2018 (aucun consensus atteint en 2025) ; la Russie a aboli l'heure d'été en 2014 ; le Mexique l'a abolie dans la plupart des régions en 2022 ; l'Iran l'a abolie en 2022. Le projet IANA tzdata suit tous ces changements et publie des mises à jour plusieurs fois par an ; les systèmes d'exploitation modernes les récupèrent automatiquement. Il existe des décalages d'une demi-heure et d'un quart d'heure : l'Inde est UTC+5:30, l'Iran UTC+3:30, Terre-Neuve UTC-3:30, le Népal UTC+5:45, les îles Chatham UTC+12:45. Le calculateur les gère de manière transparente car IANA le fait. Les régions polaires utilisent le fuseau horaire qui leur convient administrativement ; les stations antarctiques peuvent suivre l'heure de leur nation d'approvisionnement. Les conversions historiques (l'heure d'une réunion de 1956 à Berlin vers NYC) sont également prises en charge par IANA, qui enregistre tout l'historique des décalages pour chaque zone. Les conversions programmatiques dans le code doivent toujours stocker les horodatages en UTC et ne les convertir en heure locale qu'au moment de l'affichage ; ce calculateur démontre la conversion à la frontière, où l'utilisateur voit le résultat.