Convertisseur de Fuseau Horaire

Les fuseaux horaires ne sont pas de simples décalages par rapport à UTC — ce sont des régions politiques et géographiques complexes avec leurs propres règles. Il y a 38 heures locales en usage dans le monde, avec des décalages allant de UTC-12:00 à UTC+14:00. Certains fuseaux horaires utilisent des décalages de 30 minutes ou 45 minutes (l'Inde est UTC+5:30, le Népal est UTC+5:45). L'heure d'été (DST) ajoute une autre couche de complexité : tous les pays ne l'observent pas, ceux qui le font commencent et finissent à des dates différentes, et les dates changent d'année en année. Les États-Unis, l'UE et l'Australie ont tous des calendriers DST différents.

Les changements historiques de fuseau horaire rendent les choses encore plus difficiles. Les pays changent fréquemment leurs règles de fuseau horaire — la Russie a aboli la DST en 2014, la Corée du Nord a créé son propre fuseau horaire (UTC+8:30, plus tard revenu à UTC+9) en 2015, et le Chili a changé ses règles DST plusieurs fois. La base de données des fuseaux horaires IANA (tzdata) suit tous ces changements et est mise à jour plusieurs fois par an. Votre navigateur utilise cette base de données via l'API Intl, garantissant que les conversions historiques de fuseau horaire sont exactes. C'est pourquoi vous ne devriez jamais coder en dur les décalages de fuseau horaire — utilisez toujours le nom de fuseau horaire IANA (par exemple, 'America/New_York', pas 'UTC-5').

Une erreur courante est de confondre le décalage de fuseau horaire avec le fuseau horaire. 'UTC-5' est un décalage qui change deux fois par an pour New York (UTC-5 pendant EST, UTC-4 pendant EDT). 'America/New_York' est un fuseau horaire qui encapsule les règles de quand basculer. L'API Intl.DateTimeFormat des navigateurs modernes gère cela correctement — vous spécifiez le nom de fuseau horaire IANA et l'API applique le bon décalage pour toute date et heure données.

Stockez et transmettez toujours les heures en UTC. Convertissez en heure locale uniquement pour l'affichage. Cela élimine toute ambiguïté — un horodatage UTC signifie la même chose partout dans le monde. Lors de l'affichage des heures aux utilisateurs, utilisez l'API Intl.DateTimeFormat avec le fuseau horaire de l'utilisateur (obtenu via Intl.DateTimeFormat().resolvedOptions().timeZone) pour afficher automatiquement les heures dans leur fuseau horaire local. Pour la planification d'événements, incluez toujours le fuseau horaire dans l'affichage (par exemple, '15:00 EST' ou '15:00 UTC-5') et envisagez d'utiliser le format ISO 8601 avec décalage de fuseau horaire (par exemple, 2024-01-15T15:00:00-05:00) pour les données lisibles par machine.

Lors de la planification de réunions entre fuseaux horaires, utilisez un outil qui affiche les heures locales de tous les participants côte à côte. Soyez attentif aux transitions DST — une réunion récurrente à '9h00 EST' n'existe pas pendant le creux DST de mars. De plus, certaines dates n'existent pas dans tous les fuseaux horaires : lorsque les US passent à l'heure d'été, de 2h00 à 3h00 n'existe pas, et lorsqu'ils reviennent à l'heure normale, de 1h00 à 2h00 se produit deux fois. Ces cas limites sont gérés automatiquement par l'API Intl mais peuvent causer des bugs si vous faites de l'arithmétique de décalage manuelle.