Cuando un timestamp falla, rara vez “falla solo”: suele ser un efecto dominó entre logger, red, parser, base de datos y panel. Aquí vamos a entender qué se rompe y por qué, con mecanismos muy típicos (UTC/local, cambio de hora, drift del reloj, muestreo y agregación).

La idea es que, cuando veamos un síntoma (picos a horas raras, lluvia diaria que no cuadra), sepamos apuntar al mecanismo correcto y arreglarlo en el punto adecuado 💡

Este artículo forma parte del tema Datos de calidad en WikiMeteo.es, donde reunimos conceptos y guías prácticas para entender mejor el tiempo y el clima.

1. El tiempo no es “un campo”: es una cadena

Piensa el timestamp como una cadena con eslabones:

• Generación (logger/sensor): crea hora/fecha
• Transporte (red, colas, buffers): mueve paquetes
• Ingesta (parser): interpreta formato y zona
• Persistencia (DB/archivo): guarda con una convención
• Transformación (ETL): agrega a minutos/horas/días
• Visualización (panel): convierte a local, recorta ventanas

Si un eslabón asume UTC y otro asume local, el tiempo se desplaza. Si un eslabón “redondea”, aparecen duplicados.

2. Mapa de mecanismos: qué se rompe y qué síntoma da

• Zona horaria mal asumida → desplazamiento fijo (típico 1–2h) en TODA la serie
• Cambio de hora (DST) → una noche con duplicados o con hora inexistente
• Drift del reloj → desplazamiento que crece con los días/semanas
• Muestreo/intervalo mal interpretado → picos “aplastados” o “doblados”, medias raras
• Agregación mal definida (día UTC vs día local) → lluvia diaria y extremos diarios inconsistentes
• Buffers/reintentos → datos llegan tarde y aparecen “fuera de orden”

3. Mecanismo 1: UTC vs hora local (el clásico)

Qué pasa: el logger emite “hora local” pero el parser la guarda como UTC (o al revés).

Síntoma: todo queda corrido una cantidad constante (en España, típico 1–2h según época).

Cómo detectarlo rápido:

• Máximo de radiación solar lejos del mediodía local de forma estable
• Eventos de lluvia no casan con radar por ~1–2h siempre

Arreglo: unificar: almacenar UTC canónico y convertir solo al mostrar.

4. Mecanismo 2: cambio de hora (DST) y sus dos trampas

4.1 La hora que se repite (otoño)

Qué pasa: el reloj local repite una franja horaria. Si guardas en local, tendrás dos registros con la misma fecha-hora.

Síntoma: duplicados, agregaciones que suman de más, rachas o lluvia duplicada.

Arreglo: almacenar en UTC (no se repite). Si ingestas local, deduplicación determinista + flag.

4.2 La hora que no existe (primavera)

Qué pasa: se salta una hora. Si alguien intenta “rellenar”, puedes ver tiempos imposibles.

Síntoma: gap de 60 minutos o timestamps que el parser no entiende.

Arreglo: normalizar a UTC antes de persistir; gaps marcados como faltantes (no como ceros).

5. Mecanismo 3: deriva del reloj (drift del logger)

Qué pasa: el reloj interno del logger no es perfecto. Sin sincronización, deriva segundos/minutos por día o por semana.

Síntoma: el desplazamiento crece con el tiempo: hoy va 2 min tarde, en dos semanas 20 min.

Cómo se delata:

• Hora del máximo de radiación se va “corriendo” lentamente
• Los picos de lluvia ya no coinciden con radar/vecinas y cada vez peor

Arreglo: sincronizar (NTP si se puede), y si no, estimar drift y aplicar corrección versionada (sin reescribir raw a lo loco).

6. Mecanismo 4: muestreo, intervalo y agregación (donde mueren los diarios)

Aquí se rompen muchas cosas “silenciosas”, especialmente con precipitación y viento.

6.1 Muestreo vs reporte

• Muestreo: cada cuánto mide el sensor internamente (p.ej. 1s, 10s).
• Reporte: cada cuánto manda un valor al sistema (p.ej. 1 min).

Si el reporte es promedio 1-min pero tú lo interpretas como instantáneo, verás picos falsos “suavizados” o al revés.

6.2 Agregación mal definida

Ejemplo típico: “lluvia diaria” calculada como suma de 00:00 a 24:00… pero ¿00:00 de qué? ¿UTC o local?

Síntoma: la lluvia diaria “corta” a horas raras; máximos diarios se van al día anterior/siguiente.

Arreglo: definir explícitamente día local vs día UTC, y recalcular derivados con esa regla.

7. Mecanismo 5: red, buffers y reintentos

Qué pasa: la red cae, el logger almacena y reenvía. O hay colas que reordenan.

Síntoma: datos “fuera de orden” (un paquete viejo llega después). Si el sistema exige monotonicidad, lo marca como inválido o lo mete donde no toca.

Arreglo: permitir pequeña ventana de out-of-order, y basar la ordenación en timestamp canónico, no en “hora de llegada”.

8. Flags de calidad (lo mínimo para detectar cada mecanismo)

• qc_time_parse_ok
• qc_time_normalized_to_utc
• qc_time_duplicate
• qc_time_gap (gapSeconds)
• qc_time_out_of_order
• qc_time_drift_suspected (driftEstimate)
• qc_window_misalignment (maxRadiationVsNoon)

9. Errores comunes

• Guardar local “porque es lo que vemos”
• Usar fechas sin zona (naive datetime)
• Tratar gaps como 0
• Corregir drift reescribiendo raw sin registro

10. Mini-glosario

• UTC, zona horaria, DST, drift, muestreo, agregación, out-of-order

11. Referencias y lecturas recomendadas

• ECMWF
• Copernicus
• WMO