Datos, calidad y series · Última actualización: 2026-01-27

Timestamps: UTC, zonas horarias y desfases: uso operativo

Operar una estación mete sin estrés no va de “tener muchos datos”, va de tener el tiempo bien. Si el timestamp falla, todo lo demás se convierte en una telenovela: máximas que no cuadran, lluvia diaria partida, gráficas con dientes, y tú pensando “¿esto es meteorología o es el reloj?” 😅

Vamos a dejar un sistema sencillo y práctico para que UTC, zonas horarias y desfases no nos roben la paz.

Este artículo forma parte del tema Datos de calidad en WikiMeteo.es, enfocado a operar con tranquilidad y sin autoengaños.

1. Objetivo operativo (qué queremos lograr)

  • Que el almacenamiento sea coherente (ideal: UTC)
  • Que el panel muestre hora local sin romper nada
  • Que los diarios/mensuales/anuales salgan bien siempre
  • Que si algo se desvía, lo detectemos rápido con señales claras

2. Reglas de oro (las 5 que te ahorran el 80% de problemas)

2.1 Guarda en UTC, visualiza en local

Regla reina: base de datos y archivos en UTC. La conversión a zona horaria solo en la capa de visualización.

2.2 No mezcles “hora de medición” con “hora de ingestión”

Si el dato llega tarde, no cambies el timestamp de cuándo ocurrió. Si no puedes guardar ambos, al menos deja claro cuál usas.

2.3 Define una vez qué es “un día” y no lo cambies sin avisar

Los acumulados diarios pueden definirse por día local o día UTC, pero debes ser consistente. Si cambias la política, recalcula y etiqueta.

2.4 El cambio de hora (DST) no debe romper la serie

Con UTC canónico, el DST solo afecta a cómo lo ves, no a cómo se guarda. Así evitas el gap/duplicado “mágico”.

2.5 La auditoría es parte del mantenimiento

Igual que limpias el pluvio o nivelas el anemómetro, revisas el tiempo: NTP, drift y consistencia.

3. Qué revisar cuando “algo huele raro” (sin entrar en pánico)

  • ¿Hay gaps? (faltan puntos)
  • ¿Hay duplicados? (mismo timestamp repetido)
  • ¿Hay out-of-order? (timestamp que retrocede)
  • ¿Hay offset fijo? (+3600/+7200)
  • ¿Hay drift? (se va moviendo poco a poco)

4. Rutina diaria de 2 minutos (modo “sin estrés”)

  1. Mirar “último dato” y cadencia: ¿llega cada X segundos como toca?
  2. Mirar un gráfico de 24h de una variable estable (presión o temperatura nocturna): ¿hay dientes raros?
  3. Mirar el diario de lluvia/temperatura: ¿hay saltos absurdos sin apoyo?
  4. Si ves algo: anota hora y ventana afectada (para depurar sin perderte)

5. Ejemplos prácticos (para no confundir meteorología con relojes)

5.1 Lluvia convectiva

Un pico fuerte puede ser real. Antes de culpar al timestamp, cruza con:

  • Radar/descargas si tienes
  • Estaciones cercanas (si existen)
  • Si el acumulado crece de forma coherente o hay un salto aislado

5.2 Viento (anemómetro)

Muchos líos son por ventanas: racha (máximo) vs media. Si parece desfase, revisa si comparas una media 10-min con una racha instantánea.

5.3 Agregación

Si agregas a 5 min / 10 min / 1 h, define si el timestamp representa inicio, fin o centro de la ventana. Si no, verás “desfases” que no son reales.

6. Errores típicos que generan caos

  • Guardar en hora local y luego “convertir a UTC” sin control → doble conversión
  • Aplicar DST en el logger y también en el servidor → DST x2
  • Redondear timestamps al minuto y reintentar envíos → duplicados
  • Backfill sin ordenar → out-of-order
  • Definir diarios en UTC pero mostrar como si fueran locales (o al revés) → lluvia/temperaturas diarias raras

7. Checklist práctico (para pegar y vivir tranquilo)

  • Almacenamiento en UTC
  • Conversión de zona horaria solo en UI
  • Cadencia estable dentro de tolerancia
  • Sin duplicados (salvo casos controlados)
  • Sin out-of-order (o con backfill gestionado)
  • Política de corte diario definida y documentada
  • NTP activo y drift bajo control

8. Referencias y lecturas recomendadas

  • Met Office
  • WMO
  • NOAA