Los timestamps fallan de formas muy “tontas”… y por eso duelen tanto 😅. Porque no se rompen con un error rojo gigante: se rompen “casi bien”, y ese “casi” te destroza máximas/mínimas, lluvia diaria, comparativas y cualquier verificación.

Vamos a los errores comunes (los que más aparecen en estaciones, APIs y paneles) y a cómo evitarlos sin necesidad de volverte loco.

Tema: Calidad de datos · Enfoque: operativo, con ejemplos.

1. Antes de empezar: el mantra que salva vidas

• Almacena en UTC (canónico).
• Convierte a hora local solo al mostrar (UI/cliente), usando zona IANA (Europe/Madrid, etc.).
• DST no existe para tu base de datos: solo para la interfaz.

Si rompes esto, te compras tickets para el parque temático del sufrimiento 😂

2. Errores comunes de UTC/zona horaria (los clásicos)

2.1 Guardar en hora local “porque es más cómodo”

Qué pasa: llega el cambio de hora y aparece un día con 23h o 25h; además, comparar con otras fuentes se vuelve ambiguo.

Señal típica: duplicados o huecos justo en marzo/octubre; resúmenes diarios raros.

Cómo evitarlo: storage UTC + UI local.

2.2 Aplicar el offset dos veces (doble conversión)

Qué pasa: tu dato se desplaza 1h o 2h (a veces 3 si el caos es premium).

Señal típica: todo está corrido exactamente lo mismo todo el año.

Cómo evitarlo: define un único punto de conversión (UI) y audítalo.

2.3 Mezclar “Z” con timestamps sin zona (naive)

Qué pasa: unas partes del sistema interpretan naive como local, otras como UTC.

Señal típica: inconsistencias que solo pasan en algunos gráficos o endpoints.

Cómo evitarlo: en almacenamiento: ISO8601 con “Z” (o +00:00), siempre.

2.4 DST tratado como si fuera una “conversión normal”

Qué pasa: el mismo timestamp local puede existir dos veces (hora repetida) o ninguna (hora saltada).

Señal típica: duplicados exactos 02:xx o gaps.

Cómo evitarlo: evitar local time en storage; y si tienes local por legado, guarda además un UTC real o un offset explícito.

3. Errores de agregación (el enemigo silencioso)

3.1 No definir qué representa el timestamp del agregado

Qué pasa: si agregas cada 10 min, ¿el timestamp es inicio, final o centro? Si no lo documentas, tendrás desfases aparentes.

Señal típica: la lluvia “empieza” antes o después que en radar; máximos desplazados respecto a observación.

Cómo evitarlo: convención clara: start/end/center + metadato.

3.2 Cortes diarios “a ojo” (día local vs día UTC)

Qué pasa: el acumulado diario no coincide con otras fuentes; los extremos diarios se “mueven” de día.

Señal típica: lluvia diaria que parece cambiar de fecha cuando comparas con AEMET/otra red.

Cómo evitarlo: define dayDefinition (local o UTC) y sé consistente en todo el pipeline.

3.3 Mezclar muestras irregulares con agregación fija sin tratar gaps

Qué pasa: medias/energías erróneas; sumas sesgadas; extremos raros.

Señal típica: valores raros tras cortes de red.

Cómo evitarlo: antes de agregar, calcula cadencia y marca ventanas con gaps (flag).

4. La trampa estrella: lluvia convectiva (picos reales vs error de tiempo)

La convectiva es el sitio donde más nos engañan los ojos. Porque un pico puede ser:

• Real: chaparrón brutal de 10 min.
• Error de timestamp: backfill (se sube de golpe lo acumulado), reintentos, o offset.
• Error de agregación: sumas sobre ventanas mal definidas.

4.1 Errores comunes específicos en precipitación

• Backfill “en bloque”: tras un gap, entran 30–60 min de golpe con timestamps “actuales”.
• Bucket tip replay: se reenvían impulsos con hora incorrecta.
• Acumulado diario recalculado con corte distinto: parece que “llovió ayer” cuando fue hoy.

4.2 Cómo distinguir pico real de artefacto (rápido)

• ¿Hay gap justo antes? (si sí, sospecha backfill)
• ¿El pico coincide con un cambio en otras variables (humedad, T, viento)?
• ¿La cadencia se mantiene o hay out-of-order/duplicados?
• Si hay radar/descargas: ¿hay convección cerca en ese momento?

5. Errores de pipeline y almacenamiento (los “esto no debería pasar”)

5.1 Timestamp generado en servidor en vez de en el dato

Qué pasa: cuando hay cola/buffer, el timestamp refleja llegada, no observación.

Señal típica: todo parece “retrasado” y los eventos se apelotonan.

Cómo evitarlo: separar observed_time vs ingest_time (si puedes) y usar observed_time para series.

5.2 Redondeo agresivo (al minuto) + reintentos

Qué pasa: duplicados inevitables.

Cómo evitarlo: idempotencia por clave compuesta (sensor+timestamp original) o mantener precisión real.

5.3 No controlar out-of-order

Qué pasa: gráficas que van atrás; agregados rotos; extremos mal calculados.

Cómo evitarlo: buffer de reordenado pequeño o ingesta que rechace (o versiona backfill).

6. Checklist anti-errores (para no repetir golpes)

• Storage UTC (ISO8601 con Z)
• UI local con zona IANA
• Documentar convención de timestamp en agregados (start/end/center)
• Definir dayDefinition (local vs UTC) y mantenerlo
• Checks automáticos: gaps, duplicados, out-of-order
• Si hay precipitación: detector de backfill (picos tras gaps)
• Metadatos de mantenimiento (firmware, batería RTC, cambios)

7. Referencias

• Met Office
• WMO
• NOAA