Fechas y zonas horarias en inventario: evitar promociones y movimientos fuera de tiempo

Tres horas distintas para el mismo evento

En una integración de inventario conviven al menos tres momentos: cuándo ocurrió la operación en el piso, cuándo la registró el dispositivo y cuándo la recibió el sistema central. Un operador que cierra una recepción a las 18:55 sin conexión y la sincroniza a las 21:10 genera un evento cuya hora real y cuya hora de registro difieren. Si el sistema usa solo la hora de llegada, el movimiento aparecerá en el turno equivocado.

Algo parecido sucede con promociones en etiquetas electrónicas: si la promoción debe comenzar a las 00:00 locales de cada tienda y el sistema calcula con la zona del servidor, algunas tiendas cambiarán de precio horas antes o después de lo previsto.

UTC, desfase y zona IANA: para qué sirve cada uno

El formato de intercambio de fechas de Internet descrito en el RFC 3339 permite expresar un instante con el sufijo Z (UTC) o con un desfase numérico, y define una convención para cuando se conoce la hora UTC pero no el desfase local. Úsalo para el instante exacto; guarda la zona IANA como dato aparte de la ubicación.

Cómo lo plantea EPCIS

La norma EPCIS 2.0 separa los conceptos con claridad: eventTime identifica el momento de forma independiente de la zona; eventTimeZoneOffset indica el desfase vigente en el lugar donde ocurrió, útil para saber, por ejemplo, si pasó en horario laboral o para mostrarlo en hora local; y recordTime es el momento en que el repositorio lo registró, sin relación con el mundo físico. Es un buen modelo mental aunque no uses el estándar: conserva hora del evento, desfase local y hora de registro como campos separados.

Reglas de horario: no las asumas, verifícalas

Las reglas de zona horaria cambian por decisiones políticas. La base de datos pública que mantiene IANA como Time Zone Database existe justamente para reflejar esos cambios en fronteras de zonas, desfases UTC y reglas de horario de verano; sus versiones se publican periódicamente y el software de usuarios las recibe por medio de sistemas operativos y proveedores. Esto implica una tarea de TI concreta: saber qué versión usan tus servidores, PDA, plataforma de ESL y base de datos, y actualizarla con un proceso.

Este artículo no afirma qué reglas de horario rigen hoy en México: si tu cálculo depende de ello, confirma la regla vigente en fuente oficial y la versión de la base de zonas que usan tus sistemas. Mejor aún, diseña de modo que un cambio de regla no obligue a reescribir datos históricos.

Ejemplo hipotético: promoción a las 00:00 locales en dos tiendas

Ejemplo ilustrativo. Una promoción debe comenzar a las 00:00 locales del primer día de un mes en dos tiendas, cada una con su zona IANA, y cuyas reglas de horario pueden diferir entre sí o cambiar con el tiempo. Si el planificador guarda un desfase fijo (por ejemplo “00:00 UTC−X”) para ambas tiendas, la que tenga otro desfase, o cuya regla cambie, comenzará la promoción a una hora local equivocada.

La forma robusta es almacenar: fecha y hora locales de inicio, la zona IANA de cada tienda y un cálculo de instante UTC en el momento de programar, que se vuelve a calcular si cambia la base de zonas. El sistema envía a las etiquetas el instante UTC o el comando en el momento correcto, y el registro de auditoría guarda ambas horas, local y UTC.

Relojes de dispositivos y eventos desordenados

Un dispositivo puede tener el reloj desajustado, sobre todo si estuvo sin sincronizar. Por eso las guías de registro, como la hoja de OWASP sobre logging, recomiendan sincronizar la hora entre servidores y dispositivos y, cuando no es posible, medir el desfase o registrar un nivel de confianza en la marca de tiempo. Aplica el mismo principio: guarda la hora del dispositivo, la hora de recepción y la diferencia estimada.

• No ordenes eventos solo por hora de llegada.
• Rechaza o marca eventos con fechas futuras o demasiado antiguas según un umbral definido por ti.
• Registra el desajuste detectado al sincronizar para poder auditarlo.

Pruebas mínimas

• Cambiar la hora del dispositivo 20 minutos hacia atrás y enviar un evento.
• Enviar una promoción programada para dos tiendas con zonas distintas y comprobar la hora local real de cambio.
• Simular un reenvío de eventos con horas del turno anterior.
• Verificar la versión de la base de zonas en cada componente y documentarla.

Si alguno de estos casos no puede ejecutarse en pruebas, déjalo como riesgo explícito del proyecto.

Siguiente paso

Haz un inventario de todos los lugares donde se guarda una fecha: PDA, middleware, WMS, ERP, plataforma ESL. Anota qué formato usan y si guardan zona. Con eso se decide dónde hay más riesgo. Para revisar el flujo con ARKCOM, puedes escribir desde garkcom.com/contact.