Horodatage Invalide : Diagnostic Rapide et Corrections

Liste de vérification diagnostic rapide

Vérifier longueur : 10=secondes, 13=ms, 16=µs, 19=ns.
Vérifier chiffres : nombres uniquement ; supprimer espaces/lettres.
Vérifier plage : la date résultante est-elle plausible et sûre pour 64-bit ?
Vérifier fuseau horaire : convertir en UTC d'abord, puis appliquer le décalage cible.
Vérifier bord DST : si localisation, utiliser une zone IANA (America/New_York).

Besoin de vérifier maintenant ? Aller à Convertisseur Unix Timestamp ou Convertisseur par Lots.

Types d'erreurs courants

Longueur incorrecte : 13 chiffres traités comme secondes → date dans le futur lointain.
Caractères non numériques : espaces cachés, virgules ou lettres.
Hors plage : secondes 32-bit débordent après 2038 ; négatifs non supportés dans certains systèmes.
Ambiguïté de fuseau horaire : heure locale du serveur vs. UTC attendu.
Décalages DST : parsing en heure locale pendant l'heure manquante cause un échec.

Étapes de validation (copier-coller)

JavaScript


JAVASCRIPT
1// JavaScript : valider et normaliser en millisecondes
2export function normaliserEpoch(raw) {
3  const recadre = raw.trim();
4  if (!/^[0-9]+$/.test(recadre)) throw new Error("Chiffres uniquement");
5  const len = recadre.length;
6  if (len === 10) return Number(recadre) * 1000;
7  if (len === 13) return Number(recadre);
8  if (len === 16) return Number(recadre) / 1000;
9  if (len === 19) return Number(recadre) / 1_000_000;
10  throw new Error("Longueur invalide");
11}

Python


PYTHON
1# Python : valider et convertir en datetime (UTC)
2from datetime import datetime, timezone
3
4def parse_epoch(raw: str) -> datetime:
5    if not raw.isdigit():
6        raise ValueError("Chiffres uniquement")
7    n = len(raw)
8    if n == 10:
9        ts = int(raw)
10    elif n == 13:
11        ts = int(raw) / 1000
12    elif n == 16:
13        ts = int(raw) / 1_000_000
14    elif n == 19:
15        ts = int(raw) / 1_000_000_000
16    else:
17        raise ValueError("Longueur invalide")
18    return datetime.fromtimestamp(ts, tz=timezone.utc)

SQL (PostgreSQL)


SQL
1-- SQL : valider la longueur du timestamp dans une table
2SELECT id, ts_raw,
3       CASE
4         WHEN ts_raw ~ '^[0-9]{10}$' THEN 'secondes'
5         WHEN ts_raw ~ '^[0-9]{13}$' THEN 'millisecondes'
6         WHEN ts_raw ~ '^[0-9]{16}$' THEN 'microsecondes'
7         WHEN ts_raw ~ '^[0-9]{19}$' THEN 'nanosecondes'
8         ELSE 'invalide'
9       END AS ts_precision
10FROM evenements
11WHERE ts_raw !~ '^[0-9]{10}$'
12   OR ts_raw::numeric > 32503680000; -- > 3000-01-01 comme limite de bon sens

Modèles de correction

Correction de précision : détecter longueur → mettre à l'échelle en millisecondes → re-parser.
Nettoyer / assainir : supprimer espaces et virgules avant validation regex.
Garde de plage : limiter ou rejeter les valeurs hors de la fenêtre plausible (ex., année < 2000 ou > 2100).
Correction de fuseau horaire : parser en UTC, puis formater vers le décalage/zone cible.
Parsing sûr pour DST : préférer UTC ; si local requis, utiliser des bibliothèques de zone IANA.

FAQ

Quelle est la valeur par défaut la plus sûre ? Parser en UTC, puis formater vers le fuseau horaire demandé.
Comment prévenir les problèmes de 2038 ? Stocker en entiers 64-bit ; éviter le stockage basé sur secondes 32-bit.
Comment nettoyer les données en lots ? Utiliser un pré-filtre regex + mise à l'échelle basée sur la longueur, puis canaliser vers un convertisseur ; essayer Convertisseur par Lots.

Outils et guides connexes

Liste de vérification diagnostic rapide

Vérifier longueur : 10=secondes, 13=ms, 16=µs, 19=ns.

Vérifier chiffres : nombres uniquement ; supprimer espaces/lettres.

Vérifier plage : la date résultante est-elle plausible et sûre pour 64-bit ?

Vérifier fuseau horaire : convertir en UTC d'abord, puis appliquer le décalage cible.

Vérifier bord DST : si localisation, utiliser une zone IANA (America/New_York).

Types d'erreurs courants

Longueur incorrecte : 13 chiffres traités comme secondes → date dans le futur lointain.

Caractères non numériques : espaces cachés, virgules ou lettres.

Hors plage : secondes 32-bit débordent après 2038 ; négatifs non supportés dans certains systèmes.

Ambiguïté de fuseau horaire : heure locale du serveur vs. UTC attendu.

Décalages DST : parsing en heure locale pendant l'heure manquante cause un échec.

Étapes de validation (copier-coller)

JavaScript

JAVASCRIPT

// JavaScript : valider et normaliser en millisecondes
export function normaliserEpoch(raw) {
  const recadre = raw.trim();
  if (!/^[0-9]+$/.test(recadre)) throw new Error("Chiffres uniquement");
  const len = recadre.length;
  if (len === 10) return Number(recadre) * 1000;
  if (len === 13) return Number(recadre);
  if (len === 16) return Number(recadre) / 1000;
  if (len === 19) return Number(recadre) / 1_000_000;
  throw new Error("Longueur invalide");
}

Python

PYTHON

# Python : valider et convertir en datetime (UTC)
from datetime import datetime, timezone

def parse_epoch(raw: str) -> datetime:
    if not raw.isdigit():
        raise ValueError("Chiffres uniquement")
    n = len(raw)
    if n == 10:
        ts = int(raw)
    elif n == 13:
        ts = int(raw) / 1000
    elif n == 16:
        ts = int(raw) / 1_000_000
    elif n == 19:
        ts = int(raw) / 1_000_000_000
    else:
        raise ValueError("Longueur invalide")
    return datetime.fromtimestamp(ts, tz=timezone.utc)

SQL (PostgreSQL)

SQL

-- SQL : valider la longueur du timestamp dans une table
SELECT id, ts_raw,
       CASE
         WHEN ts_raw ~ '^[0-9]{10}$' THEN 'secondes'
         WHEN ts_raw ~ '^[0-9]{13}$' THEN 'millisecondes'
         WHEN ts_raw ~ '^[0-9]{16}$' THEN 'microsecondes'
         WHEN ts_raw ~ '^[0-9]{19}$' THEN 'nanosecondes'
         ELSE 'invalide'
       END AS ts_precision
FROM evenements
WHERE ts_raw !~ '^[0-9]{10}$'
   OR ts_raw::numeric > 32503680000; -- > 3000-01-01 comme limite de bon sens

Modèles de correction

Correction de précision : détecter longueur → mettre à l'échelle en millisecondes → re-parser.

Nettoyer / assainir : supprimer espaces et virgules avant validation regex.

Garde de plage : limiter ou rejeter les valeurs hors de la fenêtre plausible (ex., année < 2000 ou > 2100).

Correction de fuseau horaire : parser en UTC, puis formater vers le décalage/zone cible.

Parsing sûr pour DST : préférer UTC ; si local requis, utiliser des bibliothèques de zone IANA.

FAQ

Quelle est la valeur par défaut la plus sûre ? Parser en UTC, puis formater vers le fuseau horaire demandé.

Comment prévenir les problèmes de 2038 ? Stocker en entiers 64-bit ; éviter le stockage basé sur secondes 32-bit.

Comment nettoyer les données en lots ? Utiliser un pré-filtre regex + mise à l'échelle basée sur la longueur, puis canaliser vers un convertisseur ; essayer Convertisseur par Lots.