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.
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.