Conversion de fuseaux horaires des horodatages Unix : un guide pratique

Pourquoi le fuseau horaire compte pour les horodatages Unix

Les horodatages Unix eux-mêmes sont indépendants du fuseau horaire — le nombre 1785292800 signifie le même instant partout. La complexité apparaît lorsque vous convertissez cet instant en une heure locale lisible pour l'affichage, la journalisation ou l'analyse de données.

Le principe fondamental : stockez toujours en UTC, convertissez uniquement pour l'affichage. Cette règle élimine des catégories entières de bugs et rend vos données portables entre les fuseaux horaires.

UTC vs heure locale : comprendre la différence

UTC (temps universel coordonné)

L'UTC est la norme de temps primaire. Il ne change jamais pour l'heure d'été et est le même partout sur Terre. Les horodatages Unix sont définis en UTC.

Heure locale

L'heure locale est l'UTC ajusté pour une région géographique spécifique. Elle peut différer de l'UTC par un décalage fixe (par ex. UTC+8 pour l'heure normale de la Chine) ou un décalage variable (par ex. l'heure de l'Est alterne entre UTC-5 et UTC-4 pour l'heure d'été).

Le problème du décalage

Le même horodatage Unix produit des heures locales différentes selon l'emplacement de l'observateur :

| Horodatage | UTC | New York (EST) | Tokyo (JST) | Londres (BST) | |-----------|-----|----------------|-------------|--------------| | 1785292800 | 2026-07-19 00:00 | 2026-07-18 20:00 | 2026-07-19 09:00 | 2026-07-19 01:00 | | 1785379200 | 2026-07-19 23:59 | 2026-07-19 19:59 | 2026-07-20 08:59 | 2026-07-20 00:59 |

L'heure d'été (DST)

Qu'est-ce que l'heure d'été ?

L'heure d'été est la pratique consistant à avancer les horloges pendant les mois d'été afin que la lumière du soir dure plus longtemps. Les horloges « avancent » (perdent une heure) au printemps et « reculent » (gagnent une heure) en automne.

L'impact sur la conversion d'horodatages

L'heure d'été crée un décalage variable entre l'heure locale et l'UTC. Cela signifie :

1. La même heure locale peut correspondre à deux horodatages différents (lors de la transition « recule », l'heure de 1:00 du matin se produit deux fois)
2. Certaines heures locales n'existent pas (lors de la transition « avance », par ex. 2:00 du matin ne se produit jamais — les horloges passent directement à 3:00 du matin)

Exemple : l'heure ambiguë

Dans le fuseau horaire de l'Est des États-Unis, le premier dimanche de novembre à 2:00 du matin, les horloges reculent à 1:00 du matin. Cela signifie :

from datetime import datetime, timezone
import pytz

eastern = pytz.timezone("America/New_York")

# First occurrence of 1:00 AM (EDT, UTC-4)
first = eastern.localize(datetime(2026, 11, 1, 1, 0), is_dst=True)
print(first.timestamp())
# Some timestamp value

# Second occurrence of 1:00 AM (EST, UTC-5) = 3600 seconds later!
second = eastern.localize(datetime(2026, 11, 1, 1, 0), is_dst=False)
print(second.timestamp())
# first.timestamp() + 3600

Gérez toujours soigneusement l'heure ambiguë de la transition de recul dans vos applications. L'utilisation des drapeaux is_dst/ambiguous en Python ou des options équivalentes dans d'autres langages évite des bugs subtils.

Convertir entre les fuseaux horaires

Utiliser notre outil en ligne

L'approche la plus simple pour les conversions ponctuelles est notre Convertisseur d'horodatage Unix, qui affiche les résultats dans plusieurs fuseaux horaires simultanément.

Utiliser la ligne de commande Linux

# Display timestamp in multiple timezones
TZ="America/New_York" date -d @1785292800
TZ="Europe/London"    date -d @1785292800
TZ="Asia/Tokyo"       date -d @1785292800

# With custom ISO format
TZ="UTC" date -d @1785292800 +"%Y-%m-%d %H:%M:%S %Z"
# Output: 2026-07-19 00:00:00 UTC

TZ="Asia/Shanghai" date -d @1785292800 +"%Y-%m-%d %H:%M:%S %Z"
# Output: 2026-07-19 08:00:00 CST

Utiliser Python

from datetime import datetime
from zoneinfo import ZoneInfo  # Python 3.9+

ts = 1785292800

# Convert to multiple timezones
timezones = ["America/New_York", "Europe/London", "Asia/Tokyo", "Australia/Sydney"]

for tz_name in timezones:
    tz = ZoneInfo(tz_name)
    dt = datetime.fromtimestamp(ts, tz=tz)
    print(f"{tz_name}: {dt.strftime('%Y-%m-%d %H:%M:%S %Z')}")

Utiliser JavaScript

const ts = 1785292800;
const date = new Date(ts * 1000);

const timezones = [
    "America/New_York",
    "Europe/London",
    "Asia/Tokyo",
    "Australia/Sydney"
];

for (const tz of timezones) {
    const str = date.toLocaleString("en-US", {
        timeZone: tz,
        timeZoneName: "short",
    });
    console.log(`${tz}: ${str}`);
}

Utiliser Go

package main

import (
    "fmt"
    "time"
)

func main() {
    t := time.Unix(1785292800, 0)
    
    timezones := []string{
        "America/New_York",
        "Europe/London",
        "Asia/Tokyo",
        "Australia/Sydney",
    }
    
    for _, tz := range timezones {
        loc, _ := time.LoadLocation(tz)
        fmt.Printf("%s: %s\n", tz, t.In(loc).Format("2006-01-02 15:04:05"))
    }
}

Modèles courants de conversion de fuseaux horaires

Convertir les journaux serveur en heure locale

Les journaux serveur enregistrent couramment les horodatages en UTC. Lors de leur analyse, convertissez-les dans votre fuseau horaire local :

# Read a log file and display timestamps in Pacific time
while IFS= read -r line; do
    if [[ $line =~ ^([0-9]+) ]]; then
        ts="${BASH_REMATCH[1]}"
        TZ="America/Los_Angeles" date -d @"$ts" "+%Y-%m-%d %H:%M:%S"
        echo " $line"
    fi
done < server.log

Planifier des événements entre fuseaux horaires

Lorsque vous partagez des heures d'événements entre fuseaux horaires, communiquez toujours en UTC ou partagez directement l'horodatage Unix. Cela élimine l'ambiguïté :

• « Réunion à 1785292800 » est sans ambiguïté
• « Réunion à 9:00 EST » devient ambigu lors des transitions d'heure d'été
• « Réunion à 9:00 America/New_York » est mieux mais exige encore de connaître le statut de l'heure d'été

Stocker les horodatages dans les bases de données

-- Always store the timestamp itself (timezone-independent)
INSERT INTO events (occurred_at, user_id) VALUES (1785292800, 42);

-- OR store with an explicit UTC timestamp column
INSERT INTO events (occurred_at_utc, user_id) 
VALUES ('2026-07-19 00:00:00+00', 42);

Résumé des meilleures pratiques

1. Stockez en UTC, convertissez pour l'affichage — Ne stockez jamais l'heure locale dans les bases de données
2. Utilisez les noms de fuseaux horaires IANA (par ex. America/New_York) au lieu des abréviations (EST, PST) — les abréviations sont ambiguës et ne tiennent pas compte de l'heure d'été
3. Gérez l'heure d'été explicitement — Utilisez des bibliothèques tenant compte du fuseau horaire ; n'ajoutez/soustrayez jamais manuellement des heures
4. Transmettez toujours l'information de fuseau horaire — Lorsque vous acceptez des dates de la part d'utilisateurs, collectez le fuseau horaire, pas seulement le décalage
5. Testez les dates limites — Testez votre logique de conversion sur les dates de transition d'heure d'été (printemps et automne) pour détecter les bugs tôt

Base de données des fuseaux horaires

Les données de fuseaux horaires de votre système proviennent de la base de données IANA des fuseaux horaires (également appelée base de données Olson), mise à jour plusieurs fois par an à mesure que les gouvernements modifient les règles d'heure d'été. Gardez votre système à jour :

# Debian / Ubuntu
sudo apt update && sudo apt install tzdata

# macOS
# Automatically updated via software updates

# Verify your database version
zdump -v /etc/localtime | head -1

Utilisez notre Convertisseur d'horodatage Unix pour des conversions rapides tenant compte du fuseau horaire sur tous les fuseaux horaires majeurs.