Convertir des fuseaux horaires sans erreur

Un client propose une visio « mardi 9 h, heure de Chicago ». Vous ajoutez 7 heures, vous notez 16 h dans l'agenda, et le mardi venu personne n'est en ligne. On était mi-mars : les États-Unis avaient déjà avancé leurs pendules, pas l'Europe. Ce jour-là le décalage valait 6 heures, pas 7. Presque toutes les erreurs de fuseau horaire ressemblent à celle-ci — l'addition est juste, c'est l'hypothèse de départ qui est fausse.

Un sigle de trois lettres ne désigne pas un fuseau

Les abréviations sont la première source de confusion, parce qu'elles ne sont ni normalisées ni uniques :

• CST : Central Standard Time (UTC−6, Chicago), China Standard Time (UTC+8, Pékin) ou Cuba Standard Time (UTC−5). Quatorze heures séparent les deux premières lectures.
• IST : India Standard Time (UTC+5:30), Irish Standard Time (UTC+1) ou Israel Standard Time (UTC+2).
• BST : British Summer Time (UTC+1) ou Bangladesh Standard Time (UTC+6).

Second piège, plus discret : PST et EST désignent l'heure d'hiver de la côte ouest et de la côte est américaines. Un webinaire annoncé « 9:00 AM PST » en juillet veut presque toujours dire « 9 h à Los Angeles », c'est-à-dire 9:00 PDT. Qui convertit le sigle au pied de la lettre se connecte une heure trop tard.

La seule désignation non ambiguë est le nom de zone IANA : America/Chicago, Asia/Shanghai, Europe/Paris. C'est le vocabulaire qu'emploient les systèmes d'exploitation, les navigateurs et les bases de données, et c'est celui à privilégier dès qu'un doute existe.

Tous les décalages ne sont pas des heures entières

Une bonne partie de la planète vit sur des décalages à la demi-heure, voire au quart d'heure. Arrondir Katmandou à UTC+6 fait rater les quinze premières minutes d'une réunion.

L'heure d'été, principale cause d'erreur

Les calendriers ne coïncident pas

L'Union européenne bascule le dernier dimanche de mars et le dernier dimanche d'octobre, à 01:00 UTC, simultanément dans tous les pays membres. L'Amérique du Nord bascule le deuxième dimanche de mars et le premier dimanche de novembre, à 2 h locales — donc pas au même instant d'un fuseau américain à l'autre. Résultat : deux fenêtres par an, environ trois semaines en mars et une semaine fin octobre, pendant lesquelles Paris–New York vaut 5 heures au lieu de 6.

L'hémisphère sud raisonne à l'envers : Sydney passe à l'heure d'été début octobre et en sort début avril. Selon la période, l'écart Paris–Sydney vaut 8, 9 ou 10 heures. Aucune valeur mémorisable.

Beaucoup de pays, enfin, ne changent plus d'heure du tout : la Chine (un seul fuseau, UTC+8, pour tout le territoire), l'Inde, le Japon, la Russie depuis 2014, le Brésil depuis 2019, la majeure partie du Mexique depuis 2022. Avec Tokyo comme avec São Paulo, le décalage bouge quand même : 8 heures depuis Paris en hiver, 7 en été, non pas parce que le Japon change d'heure, mais parce que c'est Paris qui change.

L'heure qui n'existe pas, l'heure qui existe deux fois

La nuit du passage à l'heure d'été en Europe, 2 h devient directement 3 h : entre 02:00 et 02:59, aucune heure locale n'existe. Une saisie « 02:30 » ce dimanche-là ne correspond à rien, et la plupart des outils la décalent d'une heure sans le dire. À l'automne, l'inverse : 3 h redevient 2 h, l'intervalle 02:00–02:59 se produit deux fois, et un horodatage sans décalage explicite y est irrémédiablement ambigu.

Le convertisseur de fuseaux horaires affiche un avertissement quand la date saisie tombe dans ce trou du printemps, au lieu d'ajuster l'heure en silence.

La bonne méthode : convertir un instant, pas une heure

Une heure locale seule (« 15:00 ») ne désigne rien. Ce qui existe, c'est un instant : une date, une heure et un fuseau. D'où trois réflexes :

1. Fixer la date en même temps que l'heure — le décalage du 20 mars n'est pas celui du 20 avril.
2. Déclarer le fuseau de départ par son nom de zone, jamais par un sigle.
3. Lire toutes les destinations d'un coup, au lieu d'additionner des décalages de tête ville par ville.

C'est exactement le déroulé de l'outil : vous saisissez date et heure, choisissez le fuseau de départ, puis empilez autant de villes que nécessaire. Chaque ligne affiche l'heure locale correspondante et le décalage réellement en vigueur à cette date (UTC+02:00, UTC−04:00, UTC+05:30…). Une trentaine de zones sont proposées, plus celle de votre appareil, détectée automatiquement. Un bouton de copie sort le récapitulatif en texte brut, prêt à coller dans une invitation. Tout le calcul se fait dans le navigateur : rien n'est envoyé nulle part.

Écrire l'heure pour qu'elle survive à l'envoi

La conversion faite, il reste à la transmettre sans réintroduire l'ambiguïté qu'on vient d'éliminer.

• Dans un message : donnez les deux heures locales avec les villes — « mardi 12 mai, 9 h à Chicago / 16 h à Paris ». Le nom de ville règle tout ce qu'un sigle embrouille.
• Dans un fichier ou une API : ISO 8601 avec décalage explicite, 2026-05-12T09:00:00−05:00, ou UTC suffixé d'un Z, 2026-05-12T14:00:00Z.
• Pour un événement futur ou récurrent : stockez le nom de zone (Europe/Paris), pas le décalage. Les règles changent, la base IANA qui les décrit est mise à jour plusieurs fois par an, et un « +02:00 » figé devient faux du jour au lendemain.

Méfiez-vous aussi du AM/PM : 12:00 AM est minuit et 12:00 PM est midi. C'est contre-intuitif et cela produit des rendez-vous à douze heures d'écart. En cas de doute, écrivez 00:00 et 12:00.

Ce qui coince encore, et quoi faire

UTC, GMT et Z ne sont pas synonymes

UTC est une référence, sans heure d'été, jamais. GMT est un fuseau : celui du Royaume-Uni et de l'Irlande en hiver uniquement, puisque l'été ces pays sont à UTC+1. Écrire « GMT+1 » pour Paris est donc juste en janvier et faux en juillet. Le Z d'un horodatage ISO, lui, signifie exactement UTC+00:00.

Une durée à cheval sur un changement d'heure

Du samedi 20 h au dimanche 20 h, la nuit du passage à l'heure d'été, il ne s'écoule que 23 heures réelles. Pour un délai contractuel, une durée de location ou un décompte de congés autour de fin mars ou fin octobre, la différence entre deux dates donne le nombre de jours calendaires et de jours ouvrés sans avoir à compter les cases du calendrier. En revanche, pour une durée en heures qui enjambe une bascule, retirez ou ajoutez l'heure à la main : ce week-end-là ne fait pas 24 heures.

Des logs ou des exports en timestamps

Journaux serveur, exports de bases, beaucoup d'API : ces sources n'utilisent aucun fuseau, elles comptent les secondes écoulées depuis le 1er janvier 1970 à 00:00 UTC. C'est le format le plus fiable qui soit, et le plus illisible. Le convertisseur de timestamp Unix le traduit dans les deux sens, en distinguant secondes et millisecondes — une valeur d'au moins onze chiffres est presque toujours en millisecondes, et la lire en secondes projette la date des siècles, voire des millénaires, dans le futur — un timestamp en millisecondes d'aujourd'hui, à treize chiffres, atterrit vers l'an 58 000.

Une échéance « 23:59 » sans fuseau

Les appels à candidature et les soumissions académiques emploient souvent la mention AoE (Anywhere on Earth), qui correspond à UTC−12 : le délai court tant qu'il reste un endroit sur Terre où la date n'a pas tourné. Une échéance « 23:59 AoE le 30 juin » expire donc le 1er juillet à 11:59 UTC, soit 13:59 à Paris en été. Une demi-journée de marge que beaucoup laissent filer faute de la calculer.

Une règle évite la majorité des incidents : ne convertissez jamais une heure sans sa date et sans le nom de son fuseau, et communiquez les deux heures locales plutôt qu'un décalage. Le reste n'est que de l'arithmétique, autant la confier à l'outil.