Timestamps en APIs, bases de datos y logs

La depuración en producción suele significar alinear eventos de un trace HTTP, una fila de base de datos y tres archivos de log — cada uno con su propia representación temporal.

Un flujo de correlación

1. Elige un instante de referencia — p. ej. hora del informe del usuario o timestamp del request ID
2. Normaliza todo a epoch UTC en ms (o ns si lo tienes)
3. Aplica tolerancia de desfase de reloj — portátiles y contenedores se desvían; ±2 minutos es común en sistemas laxos
4. Filtra una ventana adyacente — referencia ± 5 minutos antes de un grep profundo
5. Documenta la unidad de origen en tus notas (nginx: sec, app: ISO UTC, db: timestamptz)

APIs

REST JSON podría exponer:

{ "createdAt": 1700000000000, "updatedAt": "2023-11-14T22:13:20.000Z" }

Tipos mixtos en un mismo payload ocurren cuando los servicios evolucionan. Parsea cada campo según sus propias reglas.

Los esquemas GraphQL y protobuf suelen documentar tipos escalares — léelos antes de escribir comparaciones en el cliente.

Bases de datos

• PostgreSQL TIMESTAMPTZ almacena UTC internamente — buen valor por defecto
• Columnas epoch BIGINT requieren que recuerdes segundos vs ms para siempre
• DATETIME sin zona horaria (MySQL heredado) guarda «hora de pared tal cual» — peligroso para apps globales

Al unir logs de aplicación con SQL, convierte ambos lados a la misma representación de instante primero.

Logs distribuidos

Usa trace IDs que incorporen o acompañen timestamps. Si solo existen cadenas de reloj de pared, convierte una línea de muestra de cada servicio usando un evento conocido (marcador de deploy, heartbeat) para estimar el desfase.

Conclusión clave

La depuración entre servicios es normalización + búsqueda en ventana, no adivinar relojes locales. Convierte primero, compara segundo, amplía la ventana tercero. El Conversor de timestamp UTC acelera la normalización durante incidentes.