Pourquoi « America/New_York » est-il préférable à « GMT-5 » ?

Parce que America/New_York est une règle, pas une valeur. Il encode EST, EDT et les dates de transition entre les deux — actuellement le deuxième dimanche de mars et le premier dimanche de novembre. « GMT-5 » n’est correct que pour la moitié de l’année. Tout système utilisant des décalages fixes plante silencieusement chaque printemps et chaque automne.

Pourquoi les horloges américaines et européennes ne changent-elles pas le même week-end ?

Les États-Unis passent à l’heure d’été le deuxième dimanche de mars ; l’UE le fait le dernier dimanche de mars. Il y a généralement une fenêtre d’une à trois semaines où le décalage US/UE est d’une heure inférieur à la normale. Une réunion à 9h à New York qui atteint normalement 15h à Paris arrive à 14h pendant cette fenêtre.

Quelle est la meilleure fenêtre de chevauchement entre l’Est américain et l’Europe occidentale ?

13h00–17h00 UTC fonctionne toute l’année. C’est environ 9h–13h à New York et 14h–18h à Londres (15h–19h CET). Évitez la première heure après la fin de la journée de travail européenne — l’engagement chute fortement.

Y a-t-il un chevauchement incluant la côte Ouest américaine et l’Asie ?

À peine. Le fuseau Pacifique et Tokyo se chevauchent environ une heure le matin côté Pacifique / en soirée côté Tokyo (7h PT = 23h JST en hiver, minuit en été). La plupart des équipes réparties mondialement acceptent que cette association soit exclusivement asynchrone ou qu’elle fasse tourner l’inconvénient.

Pourquoi Outlook et Google Agenda ne sont-ils pas d’accord sur la même invitation ?

Les fichiers ICS peuvent encoder une réunion soit avec un instant UTC fixe plus une zone d’affichage, soit avec une heure locale « flottante ». Outlook utilisait historiquement une approche, Google l’autre. Utilisez toujours un client compatible avec les fuseaux horaires et vérifiez que l’ICS contient un TZID.

Dois-je utiliser UTC pour toute planification interne ?

Oui pour le stockage, non pour l’affichage. Stockez chaque événement comme un instant UTC plus la zone IANA de l’organisateur. Affichez dans la zone locale de chaque spectateur. Ne planifiez jamais une réunion récurrente en « UTC » comme zone d’affichage — elle ne change pas pour l’heure d’été.

Guide

Planifier des réunions entre fuseaux horaires : guide pratique pour les équipes distantes

La réunion récurrente dans votre agenda est incorrecte deux fois par an, de deux manières différentes, et personne ne vous l’a dit.

By Buğra SözeriPublished May 31, 2026

Les équipes distribuées perdent une quantité absurde de temps aux mêmes quelques bugs de fuseau horaire : des réunions qui décalent d’une heure deux fois par an, des invitations qui arrivent à la mauvaise heure, des « 9h pour tout le monde » qui ne le sont pas. Les corrections sont simples. Le coût de ne pas les appliquer est un lancement de produit raté par an, en moyenne.

Utilisez les zones IANA, pas les décalages fixes

La base de données de fuseaux horaires IANA (souvent appelée tzdata ou zoneinfo) est la source canonique sur le comportement des horloges dans le monde. Chaque zone —Europe/Istanbul, America/Los_Angeles, Asia/Tokyo — est une règle: l’historique complet des décalages UTC, des transitions de l’heure d’été et des changements politiques pour cet emplacement.

Un décalage brut comme GMT+3 ou UTC-5 est une valeur. Il est correct pour certains endroits à certaines périodes de l’année, mais il ne sait rien des transitions de l’heure d’été. La Turquie a abandonné l’heure d’été en 2016 et est passée définitivement à UTC+3 ; le Royaume-Uni reste sur UTC+0 en hiver et UTC+1 en été. Un système utilisant des décalages fixes se trompe silencieusement.

Règle générale : chaque datetime stocké dans votre base de données devrait être accompagné d’un identifiant de zone IANA à côté de l’instant UTC. Notre entrée du glossaire sur les fuseaux horaires IANA couvre le format plus en détail.

Semaines de transition de l’heure d’été

Le moyen le plus fiable de trouver des bugs de fuseau horaire dans une application de calendrier est de regarder la deuxième semaine de mars. Voici pourquoi.

États-Unispassent à l’heure d’été le deuxième dimanche de mars et reviennent le premier dimanche de novembre (depuis 2007).
Union européenne passe le dernierdimanche de mars et revient le dernier dimanche d’octobre.
Royaume-Unisuit le calendrier de l’UE (BST commence le dernier dimanche de mars).
Australie (États de l’est)change en sens inverse en octobre et en avril — ils sont dans l’hémisphère Sud.
Japon, Chine, Inde, la plupart de l’Afrique, la plupart de l’Amérique du Sud— aucun changement d’heure d’été.

Les conséquences pratiques : entre le deuxième dimanche de mars et le dernier dimanche de mars, les États-Unis sont à l’heure d’été tandis que l’Europe est encore à l’heure standard. L’écart habituel New York / Londres de 5 heures passe à 4 heures. Une réunion à 9h à New York qui tombe normalement à 14h à Londres tombe à 13h à Londres. Les réunions récurrentes stockées comme « 9h America/New_York » dans un client compatible avec les fuseaux horaires gèrent cela correctement.

Fenêtres de chevauchement pratiques

Est américain ↔ Europe occidentale

13h00–17h00 UTC.C’est environ 9h–13h côté Est et 14h–18h à Londres / 15h–19h en Europe centrale. Évitez 17h00–18h00 UTC — l’engagement chute fortement une fois la journée de travail européenne terminée.

Ouest américain ↔ Europe occidentale

16h00–17h00 UTC.Une fenêtre d’une heure : 9h Pacifique = 17h Londres. Beaucoup d’équipes acceptent cela et organisent une seule réunion hebdomadaire, avec tout le reste en asynchrone.

Europe occidentale ↔ Asie (Tokyo, Singapour, Séoul)

08h00–10h00 UTC. 9h Londres = 18h Tokyo. Tôt pour Londres, fin de journée pour Tokyo. Planifiez les réunions récurrentes le lundi ou le mardi.

Ouest américain ↔ Asie

14h00–15h00 UTC.C’est 7h Pacifique = 23h Tokyo (hiver). Pénible pour les deux côtés. La plupart des équipes associant ces deux régions évitent entièrement les réunions en direct.

Pour une consultation interactive, notre planificateur de réunion affiche les plages de chevauchement sur plusieurs zones. L’horloge mondiale est pratique pour les vérifications rapides « est-ce qu’il est au milieu de la nuit chez eux en ce moment ? ».

Pièges des invitations calendrier

ICS sans TZID

Le format iCalendar (ICS) peut encoder une réunion de deux façons : comme un instant UTC (ex. DTSTART:20260601T130000Z) ou comme une heure locale liée à une zone (ex. DTSTART;TZID=America/New_York:20260601T090000). La première forme est non ambiguë sur l’instant mais ne change pas avec l’heure d’été. La deuxième forme le fait.

Les réunions récurrentes doivent toujours utiliser la forme TZID. Si vous créez un événement récurrent dans un outil qui ne stocke qu’en UTC, chaque participant hors de cette zone verra la réunion décaler d’une heure deux fois par an.

Heures « flottantes »

Certaines applications prennent en charge une troisième forme : heure locale sans aucune zone, signifiant « 9h où que vous soyez ». Cela est correct pour les rappels de médicaments et presque toujours faux pour les réunions partagées.

Recommandations pratiques

Stocker UTC + zone IANA.Deux colonnes : une pour l’instant absolu, une pour la zone de l’organisateur. Afficher dans la zone du spectateur.
Choisir les horaires de réunions récurrentes par plage UTC, pas par heure locale.Une réunion hebdomadaire à « 13h00 UTC » reste dans la même fenêtre de chevauchement toute l’année même si elle décale d’une heure en heure locale.
Auditer les réunions récurrentes autour des transitions. Bloquez 30 minutes la semaine précédant chaque transition pour confirmer que les invitations atterrissent toujours comme prévu.
Asynchrone par défaut.Le correctif de fuseau horaire le moins cher est d’avoir moins de réunions à présence obligatoire.
Utiliser les noms de zones IANA dans les outils. « PST » est ambigu. America/Los_Angelesne l’est pas.

Essayez le planificateur

Entrez les zones de votre équipe dans notre planificateur de réunion pour voir les plages de chevauchement en vert/rouge sur une journée de 24 heures. Pour les conversions ponctuelles, le convertisseur de fuseau horaire gère les entrées de date et d’heure arbitraires.

Conclusion

Les bugs de fuseau horaire sont entièrement évitables. Utilisez les noms de zones IANA, stockez UTC plus zone, planifiez les réunions récurrentes par plage UTC, et vérifiez autour des semaines de transition de l’heure d’été. La plupart des frustrations liées aux calendriers dans les équipes distribuées remontent à l’une de ces quatre règles violées. Elles sont peu coûteuses à respecter ; l’alternative est des réunions manquées et du ressentiment silencieux.

Frequently asked questions

Pourquoi « America/New_York » est-il préférable à « GMT-5 » ?: Parce que America/New_York est une règle, pas une valeur. Il encode EST, EDT et les dates de transition entre les deux — actuellement le deuxième dimanche de mars et le premier dimanche de novembre. « GMT-5 » n’est correct que pour la moitié de l’année. Tout système utilisant des décalages fixes plante silencieusement chaque printemps et chaque automne.
Pourquoi les horloges américaines et européennes ne changent-elles pas le même week-end ?: Les États-Unis passent à l’heure d’été le deuxième dimanche de mars ; l’UE le fait le dernier dimanche de mars. Il y a généralement une fenêtre d’une à trois semaines où le décalage US/UE est d’une heure inférieur à la normale. Une réunion à 9h à New York qui atteint normalement 15h à Paris arrive à 14h pendant cette fenêtre.
Quelle est la meilleure fenêtre de chevauchement entre l’Est américain et l’Europe occidentale ?: 13h00–17h00 UTC fonctionne toute l’année. C’est environ 9h–13h à New York et 14h–18h à Londres (15h–19h CET). Évitez la première heure après la fin de la journée de travail européenne — l’engagement chute fortement.
Y a-t-il un chevauchement incluant la côte Ouest américaine et l’Asie ?: À peine. Le fuseau Pacifique et Tokyo se chevauchent environ une heure le matin côté Pacifique / en soirée côté Tokyo (7h PT = 23h JST en hiver, minuit en été). La plupart des équipes réparties mondialement acceptent que cette association soit exclusivement asynchrone ou qu’elle fasse tourner l’inconvénient.
Pourquoi Outlook et Google Agenda ne sont-ils pas d’accord sur la même invitation ?: Les fichiers ICS peuvent encoder une réunion soit avec un instant UTC fixe plus une zone d’affichage, soit avec une heure locale « flottante ». Outlook utilisait historiquement une approche, Google l’autre. Utilisez toujours un client compatible avec les fuseaux horaires et vérifiez que l’ICS contient un TZID.
Dois-je utiliser UTC pour toute planification interne ?: Oui pour le stockage, non pour l’affichage. Stockez chaque événement comme un instant UTC plus la zone IANA de l’organisateur. Affichez dans la zone locale de chaque spectateur. Ne planifiez jamais une réunion récurrente en « UTC » comme zone d’affichage — elle ne change pas pour l’heure d’été.

Published May 31, 2026