Zonas horarias y sensibilidad

1) Principios básicos

UTC como transporte y almacenamiento. Todos los temporizadores de servidor y las claves de clasificación están en UTC. La conversión a tiempo de pared local es en el borde (edge/UI) o en un servicio de formato dedicado específicamente.
La zona ≠ el desplazamiento. ' Europe/Kyiv ' es no simplemente ' UTC+02:00 ': las reglas se cambian con el tiempo. Almacene los identificadores IANA (tzdb) en el perfil de usuario/objeto en lugar de «+ 03:00».
Una clara distinción de horas.

Wall clock (tiempo humano, sujeto al DST).
Clock UTC (escala universal).
Clock monotónico (para medir duraciones y tiempos de espera). Nunca calcule los tiempos de espera en un reloj de pared.
Idempotencia y tolerancia al temblor del tiempo. Los sistemas deben sobrevivir correctamente a pequeños saltos de NTP/desplazamientos.

2) Modelo de datos y contratos API

Eventos: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), opcionalmente 'wall _ time' (local con el desplazamiento guardado al crear).
Períodos: utilizar intervalos semicerrados '[start, end)' en UTC; para los horarios humanos, almacene la expresión original + zona.
Reglas repetitivas: serializar como zona RRULE/cron-equivalente + IANA. La planificación delega en un motor que entienda el DST.
Formato de tiempo en API: ISO 8601/RFC 3339 con explícito 'Z' o desplazamiento, por ejemplo '2025-10-31T17: 00: 00Z'. No pase cadenas «flotantes» sin desplazamiento.
Versioning: cambiar las reglas de tiempo del negocio (por ejemplo, cambiar un país a un UTC + 1 permanente) es migrar configuraciones y volver a calcular horarios; tenga en cuenta en los esquemas de versiones.

3) Horario de verano (DST): ambiciones y pases

Tiempos locales duplicados. En otoño, la «02:30» local puede suceder dos veces. El planificador en la zona debe distinguir entre '2025-10-26T02: 30 + 03' y '2025-10-26T02: 30 + 02'.
Tiempos locales perdidos. En primavera, intervalos de minutos «saltan» (por ejemplo, '02: 00-03: 00' no existe). El planificador tiene la obligación de definir la estrategia: trasladar a '03:00', omitir o ejecutar «cuanto antes».
Recomendación: guarde el trabajo como «regla local + zona» y materialice las instancias reales en UTC de antemano (ventana de desplazamiento), con la fijación de la política seleccionada en DST.

4) Leap seconds и time smear

Leap second. A veces se inserta un segundo adicional en UTC. La mayoría de los procesos de negocio no deben «ver» 23:59:60.
Smear (desenfoque). Algunos ambientes distribuyen suavemente el ajuste a la ventana (por ejemplo, ± 12 horas) para evitar el salto.
Práctica: conciliar una única política de tiempo para todo el clúster (NTP/Smear), lógica en metadatos y guarda en runbook.

5) Planificadores y patrones cron

El peligro de "cron' simple. El cron clásico no conoce las zonas DST y IANA. Utilice los motores donde el horario está enlazado a la zona (Quartz-class, servicios de Scheduler en la nube, Kubernetes CronJob con la zona a través del controlador/almission).
La materialización de los horarios. Para obtener fiabilidad, materialice los lanzamientos N más cercanos en UTC (por ejemplo, de 7 a 30 días), almacene cursor y determine la política en DST.
Idempotencia de las tareas. Ключ deduplication: `(job_id, scheduled_at_utc)`; el reinicio no debe duplicar los efectos secundarios.
Deslizamiento del reloj. En pausas/incidentes prolongados, decida si hacer un catch-up (realizar lo que falta) o un skip. Configure per-job.

6) Tiempo en protocolos y colas

Neumáticos de evento (Kafka/Pulsar). Almacene 'event _ time' e 'ingest _ time' por separado. Para cálculos retrospectivos, utilice 'event _ time'.
Consumidores idempotentes. Cuando vuelva a entregar, centre su atención en la clave de evento y 'event _ time' y no en el desplazamiento en el lote.
Ordenamiento y ventanas. Las ventanas «24 horas por hora local de la tienda» calculan como intervalos UTC derivados de las reglas locales de una zona específica en una fecha específica.

7) Registros, rastreos, métricas

Estándar de tiempo único: todos los registros técnicos y métricas en UTC (indicando 'Z'). Visualización en dashboards - localizada para el usuario.
Tracks: pasa 'trace _ start _ utc', 'duration _ ms' en un reloj monotónico. Nunca reste los temporizadores de «pared».
Informes de negocios: forme un «día» en la zona de dominio (por ejemplo, 'Europe/Paris' para el impuesto francés) y no en UTC. Documente claramente.

8) Perfiles y contenido personalizados

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Entidades multisonas: para equipos/organizaciones, almacene una «zona de dominio» (por ejemplo, una tienda/yurlitz) independientemente de la zona personal del participante.
Notificaciones: calcular «relojes silenciosos» en la zona del usuario; envío a shedulita desde la ventana UTC, con seguridad bajo DST.

9) Anti-patrones

Almacenar sólo tiempo local sin desplazamiento/zona.
Escriba rígidamente el desplazamiento '+ hh: mm' en lugar del identificador IANA.
Contar la duración a través de la diferencia de dos temporizadores «de pared».
Planifique por cron sin soporte de zona/DST.
Hacer análisis «por días» en UTC cuando la norma requiere una zona local.
Asumir la inmutabilidad de las reglas de zona (los países cambian la política de tiempo).

10) Pruebas de tiempo

Reloj controlado. Inyecte el «reloj» en el código (Clock/TimeProvider) para las pruebas deterministas.

• Cambio al horario de verano/invierno (tomas/pases).
• Mueve al usuario entre zonas (cambio de 'preferred _ timezone').
• Cambio de reglas en tzdb (actualización de base - pruebas de regresión).
• Desplazamientos de NTP, entrega de eventos retrasada.
• Pruebas de fase. Zonas aleatorias, fechas, formatos; comparación con la biblioteca de referencia.

11) Observabilidad y explotación

Alertas: resincronización de NTP, retraso en la actualización de tzdb, ráfagas de tareas cron «pendientes» en DST.
Dashboards: distribución de eventos por zonas/días locales; contadores catch-up/skip.
Runbook: procedimientos para cambiar las reglas de tiempo en la jurisdicción; orden de actualización tzdb; comunicación con los propietarios de horarios.

12) Patrones de implementación

Time Normalization Gateway. Un servicio sutil que normaliza los tiempos entrantes a la RFC 3339 UTC, validando las zonas (IANA) y complementando el contexto.
Local-Day Builder. Biblioteca/servicio que, desde el «día local» y la zona, construye los límites UTC exactos '[start _ utc, end_utc)', dado el DST.
Schedule Materializer. El planificador, que almacena las reglas como «expresión local + zona», materializa las instancias futuras en UTC y administra los conflictos/pases.
Dual-Timestamp Events. Eventos con los campos 'occurred _ at _ utc', 'wall _ time _ local', 'timezone'. Para UI, se sustituye por local, para sistemas, por UTC.

13) Check-list del arquitecto

1. ¿Hay UTC en todas partes?
2. ¿Tienen las entidades de la zona IANA y la política de datos del dominio?
3. ¿El planificador entiende el DST y materializa las instancias en UTC?
4. Registros/métricas - en UTC; informes - en la zona de dominio?
5. ¿Los taimautas/retraídos están en un reloj monotónico?
6. ¿La actualización de tzdb está automatizada y monitorizada?
7. ¿Las pruebas cubren el cambio de reglas, tomas/pases de minutos?

14) Mini recetas (pseudocódigo)

Convertir un «día de trabajo» local en un intervalo UTC

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

Materialización de la programación repetitiva

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

Clave de inicio de tareas idempotente

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15) Seguridad y cumplimiento

Auditoría: almacena ambas proyecciones de tiempo (UTC y local) para conciliar las reclamaciones de los usuarios («me prometieron hasta las 23:00 hora de Lima») con la cronología del servidor.
Regulaciones: los períodos de reportes se forman en las zonas requeridas (impuestos, límites de juego responsables, restricciones de marketing «por horas»).
Privacidad: zona horaria - configuración personal, pero no datos de identificación exactos; procesar como parte de las políticas generales de privacidad.

Conclusión

«Sensibilidad al tiempo» no se trata de un formato de fecha, sino de los límites arquitectónicos de la responsabilidad: dónde almacenar, dónde transformar, cómo planificar y cómo probar la corrección. La unificación a nivel UTC, las zonas IANA explícitas, los planificadores competentes, los temporizadores dobles y los relojes monotónicos convierten el tiempo de una fuente de incidentes a un servicio de infraestructura predecible.

• GeoDNS y geo-routing; Equilibrio de carga; Observabilidad de eventos en el tiempo; Patrones Cron y materialización de horarios; Restricciones regionales y días de informes locales.