Marcas de tiempo en datos de riego: evite errores de zona y horario de verano
Las marcas de tiempo fiables para datos de riego requieren dos datos distintos: un instante inequívoco para almacenar y una zona horaria local con nombre para mostrar y elaborar informes del día agrícola. Guarde cada observación y evento en UTC, o con un desplazamiento explícito que permita convertirlo a UTC. Conserve por separado el identificador IANA de la zona de la finca. Un valor aislado como «2026-11-01 01:30» nunca debe ser el único registro temporal, porque esa hora de reloj puede ocurrir dos veces cuando termina el horario de verano.
Un investigador del USDA ARS trabaja en el controlador local de un sistema de riego por pivote central. El controlador y el operador proceden de la fotografía real del USDA; solo se ampliaron con IA los lados para crear un encuadre horizontal. Foto: Peggy Greb / USDA Agricultural Research Service. La escena aporta contexto del equipo, pero no valida el diseño de marcas de tiempo explicado abajo.
Esta guía define un contrato de datos para software de gestión del riego, controladores, pasarelas, sensores e informes. Separa la hora de medición de la hora de llegada, resuelve horas locales repetidas o inexistentes y propone una prueba de aceptación antes de confiar en los totales diarios de agua. Es un método de diseño y puesta en servicio, no una afirmación sobre una plataforma concreta.
1. Asignar un significado preciso a cada marca de tiempo
Una marca de tiempo solo es útil si se nombra el evento. En una lectura de humedad, observed_at debe indicar cuándo midió el sensor. En una orden de válvula, requested_at, accepted_at y executed_at representan hechos diferentes. Un total de caudal necesita además el comienzo y el final del intervalo acumulado. Llamar «tiempo» a todos los campos oculta estas diferencias y puede invertir el orden aparente del trabajo.
Guarde en un campo ingested_at separado el instante en que la pasarela o la plataforma recibió el registro. Un registrador remoto puede almacenar observaciones durante una interrupción y entregarlas después. Esa llegada tardía no debe sustituir a la hora original: de lo contrario un riego nocturno aparece por la mañana, un sensor antiguo parece actual y el cálculo de demora de una alarma pierde sentido.
Registre la calidad del reloj cuando afecte a la decisión. Los estados pueden ser sincronizado, estimado tras reinicio, reloj del controlador desconocido o corregido al importar. Un sufijo UTC no repara un reloj atrasado diez minutos; solo identifica la base temporal asumida. La guía de ubicación de sensores de humedad comprueba si una lectura representa la zona radicular irrigada; este artículo comprueba si se conserva cuándo se midió. Ambas pruebas son necesarias para decidir el riego.
| Campo | Significado | Ejemplo | Motivo para separarlo |
|---|---|---|---|
| observed_at_utc | Instante de la observación del sensor o controlador | 2026-11-01T05:30:00Z | Ordena la evidencia sin ambigüedad local |
| ingested_at_utc | Instante de recepción en la plataforma | 2026-11-01T05:42:18Z | Mide el retraso sin reescribir la historia |
| site_time_zone | Zona usada en pantallas e informes de la finca | America/New_York | Aplica la regla correcta en esa fecha |
| utc_offset_at_event | Desplazamiento aplicable al instante | -04:00 | Elimina la ambigüedad de la hora local exportada |
| clock_quality | Condición conocida o incertidumbre del reloj | synchronized | Evita falsa precisión tras un reinicio |
2. Usar instante, desplazamiento y zona con nombre para trabajos distintos
UTC identifica el instante. Un desplazamiento como −04:00 indica la relación entre la hora civil local y UTC en ese instante. Una zona como America/New_York contiene reglas civiles históricas y futuras. Son datos relacionados, pero responden preguntas distintas y no deben intercambiarse.
El desplazamiento solo no calcula el horario local de la próxima temporada porque carece de reglas de horario de verano. Una abreviatura como CST es aún más débil: puede designar diferentes regiones y desplazamientos. Guarde un identificador mantenido para la ubicación real y conserve en UTC las observaciones y ejecuciones.
El Instituto Nacional de Estándares y Tecnología de Estados Unidos explica las fechas establecidas por las reglas actuales y señala que algunas jurisdicciones estadounidenses no cambian la hora. Esa guía gubernamental se revisó como investigación de contexto. La ley puede cambiar, por lo que el sistema debe usar una base de zonas actualizada y registrar la versión utilizada en una exportación crítica, en vez de fijar un desplazamiento permanente.
La hora local corresponde a la presentación y a las reglas del negocio. El operador pregunta qué ocurrió a las 06:00 en la finca o cuánta agua se aplicó el lunes. La aplicación responde convirtiendo los instantes almacenados con la zona del sitio. En una vista multifinca debe etiquetar la zona elegida y mantener la zona propia de cada finca en la exportación.
3. Conservar la hora repetida al terminar el horario de verano
Cuando los relojes retroceden, una parte de la hora local se repite. En Nueva York el 1 de noviembre de 2026, 01:30 puede ser 2026-11-01T05:30:00Z con desplazamiento −04:00 o 2026-11-01T06:30:00Z con −05:00. Las observaciones están separadas por una hora aunque una columna local sin desplazamiento las haga parecer iguales.
No deduplique mediante fecha local, hora local e identificador de sensor. Use un identificador estable o el instante inequívoco en la clave. El gráfico debe conservar ambos puntos y puede mostrar el desplazamiento o una marca de hora repetida. El CSV debe incluir UTC y la hora local con desplazamiento en columnas distintas.
Un programa a las 01:30 de ese día necesita una política explícita: primera ocurrencia, segunda, ambas o una sola según la regla documentada del controlador. No se puede deducir el resultado de un panel. Defina la intención de la finca, confirme que el equipo la admite y pruebe la transición exacta en un simulador o entorno de ensayo seguro.
Para obtener la duración de riego, reste instantes y no etiquetas del reloj. Una operación que comienza en el primer 01:45 y termina en el segundo 01:15 tiene duración positiva aunque el reloj parezca retroceder. Preserve los instantes de inicio y parada junto al tiempo de marcha y el volumen calculados.
4. Resolver la hora inexistente al comenzar el horario de verano
Cuando el reloj avanza, algunas horas locales no existen. Una solicitud para iniciar a las 02:15 puede ser rechazada, omitida o desplazada por el motor de programación. La aplicación debe documentar el resultado y mostrarlo antes de que el operador dependa de ese programa.
Separe tres recurrencias. Un horario de reloj significa «regar a las 06:00 hora de la finca». Un intervalo transcurrido significa «24 horas después del último comienzo» y puede variar una hora local. Un disparador solar o agronómico depende de otra observación o modelo. Guardar los tres como evento diario genérico produce cambios silenciosos.
Para una hora inexistente, defina si se omite, se mueve al siguiente instante válido o requiere revisión. La política pertenece a la definición y al registro de auditoría. No normalice 02:15 a 03:15 sin avisar: puede trasladar el riego a otra tarifa eléctrica, ventana laboral o secuencia de fertirrigación.
Los controladores que funcionan sin conexión pueden aplicar sus propias reglas mientras no haya nube. Registre firmware, zona y fuente del reloj. Al reconectar, concilie los registros de ejecución reales en vez de inferirlos del plan. La guía de selección de controladores de riego ayuda a identificar qué arquitectura ejecuta localmente; el comportamiento horario exige confirmación específica del modelo.
5. Definir los límites del informe antes de calcular totales
El día agrícola es un intervalo del calendario en la zona del sitio, no siempre 24 horas transcurridas. El día del adelanto puede tener 23 horas y el del retroceso 25. Calcule el instante UTC de la medianoche local inicial y de la siguiente medianoche, y agregue observaciones dentro de ese intervalo exacto.
Use límites semiabiertos [inicio, fin): incluya el inicio y excluya el fin. El informe siguiente empieza donde termina el anterior, evitando contar dos veces una lectura a medianoche. Para mediciones que cruzan el límite, defina si se dividen desde muestras brutas, se asignan por el final del intervalo o se conservan como registro transversal identificado.
No divida el volumen diario entre 24 para obtener caudal medio en un día de transición; use los segundos reales. Distinga también la diferencia de un totalizador de la suma de intervalos. La guía de pulsos de medidores de riego explica el reinicio y el desbordamiento del contador; el límite temporal decide qué pulsos pertenecen al informe.
| Registro | Etiqueta local | Instante UTC | Volumen |
|---|---|---|---|
| A | 01:30 −04:00 | 05:30Z | 8 m³ |
| B | 01:30 −05:00 | 06:30Z | 9 m³ |
| C | 23:45 −05:00 | 04:45Z de la fecha UTC siguiente | 7 m³ |
| Resultado | 00:00 a la siguiente 00:00 del sitio | 25 horas transcurridas | 24 m³ |
Los valores son aritmética hipotética, no mediciones de la fotografía ni especificaciones. A y B deben permanecer en el total. C pertenece al mismo día local aunque ya sea otra fecha UTC. Agrupar por los diez primeros caracteres de la cadena UTC lo colocaría en el informe equivocado.
6. Auditar cambios de zona y correcciones de reloj
Cambiar la zona de una finca debe modificar la presentación futura y las reglas, no reescribir los instantes almacenados. Conserve quién cambió el ajuste, zona anterior y nueva, vigencia, motivo y programas recalculados. Una corrección administrativa puede cambiar el informe al que pertenece una lectura aunque el valor del sensor no cambie.
No sobrescriba una marca bruta del controlador al limpiar datos. Si se corrige un error conocido, preserve valor de origen, método, desplazamiento aplicado, revisor e instante corregido. Una bandera de calidad permite distinguir un dato sincronizado de una reconstrucción estimada.
Cuando contribuyen varios sistemas, asigne la responsabilidad de convertir en cada interfaz. Un controlador puede emitir hora local, una pasarela añadir un desplazamiento y una API convertir de nuevo. Documente el contrato real y pruébelo con datos conocidos. Una doble conversión puede mover horas un evento y seguir produciendo una cadena válida.
Los números de secuencia y contadores acumulativos son evidencia complementaria, no sustitutos del tiempo. Pueden revelar observaciones perdidas o reordenadas cuando salta el reloj. Junto con las marcas brutas y corregidas crean una pista defendible para informes y alarmas.
7. Diseñar pantallas, exportaciones y API para dos públicos
En la pantalla del operador, muestre claramente hora y zona de la finca. En diagnóstico, ofrezca UTC, desplazamiento, estado del reloj de origen y demora de ingestión. Un panel multifinca no debe convertir silenciosamente todo a la zona del portátil del usuario. Si permite elegir zona de visualización, etiquétela.
En la API, use un formato documentado con desplazamiento y precisión uniforme. Declare inicio inclusivo y final exclusivo. Devuelva el identificador de zona cuando existan agrupaciones por día local o programas futuros. Una cadena localizada para pantalla no es un campo de integración.
En el CSV, incluya columnas legibles por máquina: observed_at_utc, observed_at_local_with_offset, site_time_zone, ingested_at_utc, clock_quality, record_id, valor y unidad. Así se ordena por UTC y se entiende al mismo tiempo el día agrícola.
Las alarmas necesitan la misma distinción. La frescura compara el instante actual con observed_at; el retraso de transporte compara ingested_at con observed_at. Una alarma creada desde un lote atrasado debe conservar la observación que la activó. La guía de diseño de alarmas de riego conecta luego la condición con una acción.
8. Ejecutar una prueba de aceptación centrada en transiciones
- Seleccione la zona real y registre versiones de controlador, pasarela y software.
- Cree observaciones simuladas seguras antes, durante y después de adelanto y retroceso.
- Incluya dos observaciones con la misma etiqueta local y desplazamientos distintos.
- Programe una hora inexistente y verifique la política documentada.
- Almacene datos sin conexión, entréguelos tarde y confirme que observed_at no cambia aunque ingested_at avance.
- Genere informes por día local, día UTC e intervalo personalizado y recalcule sus límites.
- Compruebe en la exportación ambos registros repetidos, desplazamientos, zona, unidades e identificadores.
- Cambie la zona de pantalla sin cambiar los instantes y revise la auditoría.
Defina los resultados esperados antes de ejecutar. Use simulación no operativa para cambios anormales salvo que exista un procedimiento autorizado y seguro. No cambie el reloj de un controlador de producción durante el riego solo para crear evidencia.
| Riesgo | Evidencia | Señal de fallo | Disposición |
|---|---|---|---|
| Hora repetida | Dos instantes e IDs sobreviven a pantalla, exportación y agregado | Desaparece un registro | Bloquear totales y corregir identidad |
| Hora inexistente | El programa cumple la política visible | Cambio, duplicado u omisión silenciosa | Corregir motor y repetir |
| Datos almacenados | Observación e ingestión siguen separadas | El lote antiguo parece nuevo | Corregir contrato y frescura |
| Informe diario | Límites locales mapean a instantes UTC exactos | Ventana fija de 24 h o medianoche doble | Recalcular desde datos brutos |
| Corrección de reloj | Original, corrección y revisor son auditables | Se sobrescribe el origen | Restaurar procedencia |
La aceptación solo cubre versiones, zona, interfaces e informes probados. Repita los casos afectados tras actualizar la base de zonas, sustituir controlador o pasarela o reescribir informes. Conserve los fallos y vincúlelos con la versión correctiva, en vez de reemplazarlos por una captura completamente verde.
9. Preguntas frecuentes
¿UTC basta para los datos de riego?
Identifica el instante, pero no reproduce el día civil de la finca ni un futuro horario de reloj. Conserve la zona con nombre y la regla de límites junto a los registros UTC.
¿Debe regar dos veces el controlador durante la hora repetida?
No hay una suposición universal segura. Defina primera ocurrencia, segunda, ambas o una sola según la regla documentada y verifique el equipo instalado en una prueba segura.
¿Por qué conservar la hora de ingestión?
La diferencia revela el retraso de transmisión y la historia almacenada. Permite detectar evidencia antigua sin cambiar cuándo se midió.
¿Puede una hoja de cálculo agrupar por fecha con seguridad?
Solo después de convertir cada instante a la zona prevista y definir los límites. Agrupar fechas UTC o cadenas locales desnudas puede mover registros nocturnos y colapsar la hora repetida.
