Retour à l'outil
*

Fuseaux horaires en programmation

Mis à jour : mai 2026

Les bugs de date viennent rarement du timestamp lui-même. Ils viennent de l'affichage local, du passage à l'heure d'été, d'une abréviation ambiguë ou d'une API qui mélange UTC et heure locale.

Tester un fuseau IANA

Europe/Paris - America/New_York - Asia/Kolkata

Règle de base

  • Stockez l'instant en UTC, timestamp ou ISO 8601 avec offset.
  • Stockez le fuseau utilisateur séparément si l'événement est récurrent.
  • Affichez avec un nom IANA : Europe/Paris, America/New_York, Asia/Tokyo.
  • Évitez de coder manuellement +1, -5 ou +5:30 pour une date future.

Exemple JavaScript

const instant = new Date('2026-10-25T13:00:00Z');

const paris = new Intl.DateTimeFormat('fr-FR', {
  timeZone: 'Europe/Paris',
  dateStyle: 'full',
  timeStyle: 'short'
}).format(instant);

Cette approche laisse le moteur JavaScript appliquer les règles de fuseau et de DST connues par le navigateur.

Pièges fréquents

Un offset n'est pas un fuseau. UTC+1 peut désigner Paris en hiver, mais Paris devient UTC+2 en été. Une abréviation n'est pas forcément unique : IST peut signifier India Standard Time, Irish Standard Time ou Israel Standard Time selon le contexte.

Pour les APIs, envoyez un instant clair comme 2026-05-29T12:00:00Z et un champ séparé timeZone: "Europe/Paris" si l'intention locale doit être préservée.

Questions fréquentes

Faut-il stocker les dates en UTC ?

Oui pour les instants. Pour un événement récurrent local, stockez aussi le fuseau.

Pourquoi éviter EST ou CET dans le code ?

Ces abréviations ne décrivent pas toujours l'heure d'été et peuvent être ambiguës.

JavaScript sait-il gérer les fuseaux ?

Oui via Intl.DateTimeFormat et les noms IANA pris en charge par le navigateur.