Timestamp Inválido: Diagnóstico Rápido y Soluciones

Lista de verificación de diagnóstico rápido

Verificar longitud: 10=segundos, 13=ms, 16=µs, 19=ns.
Verificar dígitos: solo números; eliminar espacios/letras.
Verificar rango: ¿la fecha resultante es plausible y segura para 64-bit?
Verificar zona horaria: convertir a UTC primero, luego aplicar desplazamiento objetivo.
Verificar borde DST: si localizas, usa zona IANA (America/New_York).

¿Necesitas verificar ahora mismo? Ir a Convertidor Unix Timestamp o Convertidor por Lotes.

Tipos de errores comunes

Longitud incorrecta: 13 dígitos tratados como segundos → fecha en futuro lejano.
Caracteres no numéricos: espacios ocultos, comas o letras.
Fuera de rango: segundos 32-bit desbordan después de 2038; negativos no soportados en algunos sistemas.
Ambigüedad de zona horaria: hora local del servidor vs. UTC esperado.
Cambios DST: parsing a hora local durante la hora faltante causa fallo.

Pasos de validación (copiar y pegar)

JavaScript


JAVASCRIPT
1// JavaScript: validar y normalizar a milisegundos
2export function normalizarEpoch(raw) {
3  const recortado = raw.trim();
4  if (!/^[0-9]+$/.test(recortado)) throw new Error("Solo dígitos");
5  const len = recortado.length;
6  if (len === 10) return Number(recortado) * 1000;
7  if (len === 13) return Number(recortado);
8  if (len === 16) return Number(recortado) / 1000;
9  if (len === 19) return Number(recortado) / 1_000_000;
10  throw new Error("Longitud inválida");
11}

Python


PYTHON
1# Python: validar y convertir a datetime (UTC)
2from datetime import datetime, timezone
3
4def parse_epoch(raw: str) -> datetime:
5    if not raw.isdigit():
6        raise ValueError("Solo dígitos")
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("Longitud inválida")
18    return datetime.fromtimestamp(ts, tz=timezone.utc)

SQL (PostgreSQL)


SQL
1-- SQL: validar longitud de timestamp en una tabla
2SELECT id, ts_raw,
3       CASE
4         WHEN ts_raw ~ '^[0-9]{10}$' THEN 'segundos'
5         WHEN ts_raw ~ '^[0-9]{13}$' THEN 'milisegundos'
6         WHEN ts_raw ~ '^[0-9]{16}$' THEN 'microsegundos'
7         WHEN ts_raw ~ '^[0-9]{19}$' THEN 'nanosegundos'
8         ELSE 'inválido'
9       END AS ts_precision
10FROM eventos
11WHERE ts_raw !~ '^[0-9]{10}$'
12   OR ts_raw::numeric > 32503680000; -- > 3000-01-01 como límite de cordura

Plantillas de corrección

Corrección de precisión: detectar longitud → escalar a milisegundos → volver a parsear.
Recortar / sanitizar: eliminar espacios y comas antes de validación regex.
Guardia de rango: limitar o descartar valores fuera de ventana plausible (ej., año < 2000 o > 2100).
Corrección de zona horaria: parsear como UTC, luego formatear al desplazamiento/zona objetivo.
Parsing seguro para DST: preferir UTC; si se requiere local, usar bibliotecas de zona IANA.

FAQ

¿Cuál es el valor por defecto más seguro? Parsear como UTC, luego formatear a la zona horaria solicitada.
¿Cómo prevenir problemas de 2038? Almacenar como enteros de 64-bit; evitar almacenamiento basado en segundos de 32-bit.
¿Cómo limpiar datos en lote? Usar pre-filtro regex + escalado basado en longitud, luego canalizar a un convertidor; probar Convertidor por Lotes.

Herramientas y guías relacionadas

Lista de verificación de diagnóstico rápido

Verificar longitud: 10=segundos, 13=ms, 16=µs, 19=ns.

Verificar dígitos: solo números; eliminar espacios/letras.

Verificar rango: ¿la fecha resultante es plausible y segura para 64-bit?

Verificar zona horaria: convertir a UTC primero, luego aplicar desplazamiento objetivo.

Verificar borde DST: si localizas, usa zona IANA (America/New_York).

Tipos de errores comunes

Longitud incorrecta: 13 dígitos tratados como segundos → fecha en futuro lejano.

Caracteres no numéricos: espacios ocultos, comas o letras.

Fuera de rango: segundos 32-bit desbordan después de 2038; negativos no soportados en algunos sistemas.

Ambigüedad de zona horaria: hora local del servidor vs. UTC esperado.

Cambios DST: parsing a hora local durante la hora faltante causa fallo.

Pasos de validación (copiar y pegar)

JavaScript

JAVASCRIPT

// JavaScript: validar y normalizar a milisegundos
export function normalizarEpoch(raw) {
  const recortado = raw.trim();
  if (!/^[0-9]+$/.test(recortado)) throw new Error("Solo dígitos");
  const len = recortado.length;
  if (len === 10) return Number(recortado) * 1000;
  if (len === 13) return Number(recortado);
  if (len === 16) return Number(recortado) / 1000;
  if (len === 19) return Number(recortado) / 1_000_000;
  throw new Error("Longitud inválida");
}

Python

PYTHON

# Python: validar y convertir a datetime (UTC)
from datetime import datetime, timezone

def parse_epoch(raw: str) -> datetime:
    if not raw.isdigit():
        raise ValueError("Solo dígitos")
    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("Longitud inválida")
    return datetime.fromtimestamp(ts, tz=timezone.utc)

SQL (PostgreSQL)

SQL

-- SQL: validar longitud de timestamp en una tabla
SELECT id, ts_raw,
       CASE
         WHEN ts_raw ~ '^[0-9]{10}$' THEN 'segundos'
         WHEN ts_raw ~ '^[0-9]{13}$' THEN 'milisegundos'
         WHEN ts_raw ~ '^[0-9]{16}$' THEN 'microsegundos'
         WHEN ts_raw ~ '^[0-9]{19}$' THEN 'nanosegundos'
         ELSE 'inválido'
       END AS ts_precision
FROM eventos
WHERE ts_raw !~ '^[0-9]{10}$'
   OR ts_raw::numeric > 32503680000; -- > 3000-01-01 como límite de cordura

Plantillas de corrección

Corrección de precisión: detectar longitud → escalar a milisegundos → volver a parsear.

Recortar / sanitizar: eliminar espacios y comas antes de validación regex.

Guardia de rango: limitar o descartar valores fuera de ventana plausible (ej., año < 2000 o > 2100).

Corrección de zona horaria: parsear como UTC, luego formatear al desplazamiento/zona objetivo.

Parsing seguro para DST: preferir UTC; si se requiere local, usar bibliotecas de zona IANA.

FAQ

¿Cuál es el valor por defecto más seguro? Parsear como UTC, luego formatear a la zona horaria solicitada.

¿Cómo prevenir problemas de 2038? Almacenar como enteros de 64-bit; evitar almacenamiento basado en segundos de 32-bit.

¿Cómo limpiar datos en lote? Usar pre-filtro regex + escalado basado en longitud, luego canalizar a un convertidor; probar Convertidor por Lotes.