Aller au contenu principal

4. Heure locale

4.1. Temps Universel Coordonné (UTC)​

Étant donné que les règles d'heure d'été pour les fuseaux horaires locaux sont si complexes et peuvent changer en fonction de la législation locale à des moments imprévisibles, la véritable interopérabilité est mieux réalisée en utilisant le Temps Universel Coordonné (UTC). Cette spécification ne prend pas en compte les règles de fuseau horaire local.

Pourquoi utiliser l'UTC ?

  • ✅ Norme temporelle unifiée mondialement
  • ✅ Non affecté par l'heure d'été
  • ✅ Non affecté par les décisions politiques
  • ✅ Garantit l'interopérabilité

4.2. Décalages locaux​

Le décalage entre l'heure locale et l'UTC est souvent une information utile. Par exemple, dans le courrier électronique (RFC2822, [IMAIL-UPDATE]), le décalage local fournit une heuristique utile pour déterminer la probabilité d'une réponse rapide. Les tentatives d'étiquetage des décalages locaux avec des chaînes alphabétiques ont entraîné une mauvaise interopérabilité dans le passé [IMAIL], [HOST-REQ]. En conséquence, RFC2822 [IMAIL-UPDATE] a rendu les décalages numériques obligatoires.

Calcul du décalage numérique​

Les décalages numériques sont calculés comme « heure locale moins UTC ». L'heure équivalente en UTC peut donc être déterminée en soustrayant le décalage de l'heure locale.

Exemple 1 :

Heure locale : 18:50:00-04:00
Heure UTC : 18:50:00 - (-04:00) = 18:50:00 + 04:00 = 22:50:00Z

Vérification : Eastern Daylight Time (EDT) est UTC-4

Exemple 2 :

Heure locale : 15:30:00+08:00
Heure UTC : 15:30:00 - (+08:00) = 15:30:00 - 08:00 = 07:30:00Z

Vérification : China Standard Time (CST) est UTC+8

Notes importantes​

Note : Conformément à ISO 8601, les décalages numériques ne représentent que les fuseaux horaires qui diffèrent de l'UTC par un nombre entier de minutes. Cependant, de nombreux fuseaux horaires historiques diffèrent de l'UTC par un nombre non entier de minutes. Pour représenter exactement de tels horodatages historiques, les applications doivent (MUST) les convertir dans un fuseau horaire représentable.

Exemples de fuseaux horaires historiques :

Certaines heures locales à la fin du 19e siècle :
- Amsterdam : UTC+00:19:32
- Paris : UTC+00:09:21

Ceux-ci ne peuvent pas être représentés précisément dans RFC 3339 et doivent être arrondis à la minute la plus proche

4.3. Convention de décalage local inconnu​

Si l'heure en UTC est connue, mais que le décalage par rapport à l'heure locale est inconnu, cela peut être représenté avec un décalage de "-00:00". Cela diffère sémantiquement d'un décalage de "Z" ou "+00:00", qui implique que l'UTC est le point de référence préféré pour l'heure spécifiée. RFC2822 [IMAIL-UPDATE] décrit une convention similaire pour le courrier électronique.

Distinction des trois représentations​

Z ou +00:00 :

2002-07-15T10:30:00Z
2002-07-15T10:30:00+00:00

Signification : Cette heure EST l'heure UTC, l'UTC est le point de référence préféré

-00:00 :

2002-07-15T10:30:00-00:00

Signification : L'heure UTC est 10:30:00, mais le décalage du fuseau horaire local est inconnu
               (possiblement d'un système qui ne connaît pas son réglage de fuseau horaire)

Scénarios d'utilisation :

Scénario 1 : Journaux serveur, connus pour être en UTC → utiliser Z
Scénario 2 : Horodatage généré par un appareil, l'appareil est en UTC mais ne connaît pas le fuseau local → utiliser -00:00
Scénario 3 : Explicitement à Londres (GMT) → utiliser +00:00

4.4. Heure locale non qualifiée​

Un certain nombre d'appareils actuellement connectés à Internet font fonctionner leurs horloges internes en heure locale et ne connaissent pas l'UTC. Bien qu'Internet ait une tradition d'accepter la réalité lors de la conception des spécifications, cela ne devrait pas se faire au détriment de l'interopérabilité. Étant donné que l'interprétation d'un fuseau horaire local non qualifié échouera dans environ 23/24 du globe,

Exigences obligatoires​

Les protocoles Internet doivent (MUST) générer des horodatages entièrement qualifiés.

Cela signifie que les protocoles Internet ne doivent pas (MUST NOT) utiliser l'heure locale sans informations de fuseau horaire.

Exemples incorrects :

❌ 2002-07-15T10:30:00 (aucune information de fuseau horaire)

Exemples corrects :

✅ 2002-07-15T10:30:00Z (UTC)
✅ 2002-07-15T10:30:00+08:00 (fuseau horaire explicite)
✅ 2002-07-15T10:30:00-00:00 (UTC mais zone inconnue)

Problèmes d'interopérabilité​

Si une heure locale non qualifiée est utilisée :

Expéditeur : 2002-07-15T10:30:00 (heure locale de New York, en fait UTC-4)
Destinataire à Tokyo : Interprète comme heure de Tokyo (UTC+9)
Erreur de différence horaire : 13 heures !

Recommandations d'implémentation​

Conception du système​

# Recommandé : Toujours stocker l'heure en UTC
def store_timestamp():
    utc_time = datetime.now(timezone.utc)
    return utc_time.isoformat()  # 2024-12-21T10:30:00+00:00

# Lors de l'affichage : Convertir dans le fuseau horaire local de l'utilisateur
def display_timestamp(utc_time, user_timezone):
    local_time = utc_time.astimezone(user_timezone)
    return local_time.isoformat()

Stockage en base de données​

-- Recommandé : Utiliser TIMESTAMP WITH TIME ZONE
CREATE TABLE events (
    id SERIAL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Éviter : TIMESTAMP WITHOUT TIME ZONE (cause de l'ambiguïté)

Principe clé : Stocker en interne en UTC, convertir dans le fuseau horaire local lors de l'affichage. Ne jamais utiliser d'horodatages sans informations de fuseau horaire pour l'échange de données.

Dernière mise à jour le