Si el tiempo (timestamp) falla, todo lo demás se vuelve sospechoso: lluvia diaria rara, máximas que se mueven, gráficas con dientes… y tú mirando el panel como si fuera una película de misterio 🕵️‍♂️😅

Aquí comparamos métodos para detectar y corregir líos de UTC/zona horaria/desfase y decidir cuál usar según el caso, sin entrar en modo “ingeniería del caos”.

Tema: Calidad de datos. Enfoque: práctico y operativo, con señales claras.

1. Qué estamos intentando averiguar (la pregunta correcta)

Normalmente no es “¿mis datos están mal?”, es una de estas:

• ¿Estoy guardando en UTC o en hora local sin saberlo?
• ¿Tengo un offset fijo (p.ej. +3600 / +7200)?
• ¿Tengo drift (el reloj se va moviendo poco a poco)?
• ¿Me estoy comiendo el cambio de hora (DST) con duplicados/gaps?
• ¿Es un tema de agregación (ventanas) y no de reloj?

2. Diagnóstico rápido: qué síntoma ves

• Offset fijo: todo está corrido exactamente 1h o 2h, siempre
• Drift: al principio ok, pero con días/semanas se descuadra
• Duplicados: misma hora repetida (típico DST o reintentos)
• Gaps: faltan tramos (red, logger, ingest)
• Out-of-order: el tiempo “retrocede” (backfill o reloj loco)

3. Comparación de métodos (cuándo usar cada uno)

Piensa en esto como un “kit de herramientas”. No hace falta usarlas todas siempre.

3.1 Método A: inspección visual de serie (rápido, barato)

Qué es: mirar 24h/7d de una variable estable (presión, temperatura nocturna) y detectar dientes, saltos, huecos.

Úsalo cuando: quieres confirmar que “algo pasa” en 30 segundos.

Ventajas: inmediato, no requiere mucha infraestructura.

Limitaciones: no te dice la causa exacta; convectiva puede engañar (picos reales).

3.2 Método B: estadística de deltas (cadencia y continuidad)

Qué es: analizar Δt entre muestras: % dentro de tolerancia, p95/p99, gaps, out-of-order.

Úsalo cuando: sospechas ingest/red/rewinds, o necesitas pruebas objetivas.

Ventajas: detecta gaps/duplicados/out-of-order con precisión.

Limitaciones: no distingue bien offset fijo vs conversión mal aplicada si la cadencia sigue perfecta.

3.3 Método C: “firma DST” (cambio de hora)

Qué es: buscar el patrón de 23h/25h en el día del cambio, duplicados de hora local o hueco.

Úsalo cuando: el caos aparece “solo” en marzo/octubre.

Ventajas: muy específico.

Limitaciones: si guardas UTC canónico, este problema debería desaparecer (y solo afectar a UI).

3.4 Método D: evidencia solar (si tienes radiación/UV)

Qué es: usar la hora del pico diurno de radiación (o un proxy) como detector de offset/drift.

Úsalo cuando: sospechas desfase de 1–2 horas o drift progresivo.

Ventajas: brutal para offset/drift; la naturaleza te chiva el reloj.

Limitaciones: días nublados complican; necesitas radiación/UV o al menos una señal diurna clara.

3.5 Método E: comparación con referencia externa (estaciones cercanas / reanálisis)

Qué es: cruzar con otra estación cercana o una referencia (ojo: reanálisis no es “verdad”, pero ayuda).

Úsalo cuando: dudas si un pico es meteorología real o error temporal/sensor.

Ventajas: reduce autoengaño.

Limitaciones: microclima puede dar diferencias reales; no uses esto como martillo para todo.

3.6 Método F: validación de schema + metadatos (prevenir líos silenciosos)

Qué es: checks automáticos de formato: timezone, ISO8601, monotonía, rangos, duplicados, campos obligatorios.

Úsalo cuando: tienes pipeline (API/ETL) y quieres evitar que se cuelen problemas a producción.

Ventajas: evita el “se coló y nadie lo vio”.

Limitaciones: no prueba “veracidad meteorológica”, solo coherencia.

4. Qué método elegir según el caso (tabla mental)

• Offset fijo 1h/2h: evidencia solar + inspección + revisión de dónde aplicas tz (UI vs ingest)
• Drift gradual: evidencia solar + auditoría NTP/RTC + tendencia en hora de máximos
• Duplicados: estadística de deltas + firma DST + revisión de reintentos
• Gaps: estadística de deltas + ingest delay (si lo guardas) + conectividad/logger
• Picos en lluvia convectiva: comparación externa + coherencia del acumulado + radar si hay

5. Ejemplos típicos (vida real)

5.1 Offset por doble conversión (UTC→local→UTC)

Síntoma: todo corrido 1h/2h todo el año.

Métodos ganadores: evidencia solar + revisión pipeline (tz aplicada dos veces).

5.2 Drift por logger sin NTP

Síntoma: al principio ok; semanas después, la serie “se desplaza” respecto a lo esperable.

Métodos ganadores: evidencia solar + auditoría NTP/RTC.

5.3 Duplicados por reintentos con timestamp redondeado

Síntoma: duplicados exactos al minuto/5min.

Métodos ganadores: validación de schema + detector de duplicados + revisar redondeo.

5.4 Convectiva real vs error

Síntoma: salto de lluvia brutal; puede ser tormenta o puede ser replay/backfill.

Métodos ganadores: deltas (gaps/out-of-order), coherencia del acumulado, radar/descargas si existe.

6. Errores comunes (el “no lo hagas”)

• Guardar en hora local y luego “convertir” en distintos sitios sin control
• Aplicar DST en el logger y también en el servidor
• Agregar sin documentar si el timestamp es inicio/fin/centro
• No registrar mantenimiento (cambio de firmware, batería RTC, etc.)

7. Checklist final (mínimo viable para vivir en paz)

• UTC canónico en almacenamiento
• UI convierte a zona horaria con IANA tz
• Checks de deltas: gaps, duplicados, out-of-order
• Si hay radiación/UV: detector solar de offset/drift
• Schema validation (ISO8601, monotonicidad, campos obligatorios)
• Registro de cambios (metadatos)

8. Referencias

• WMO
• NOAA
• UCAR/COMET