Fusos horários e sensibilidade

1) Princípios básicos

UTC como transporte e armazenamento. Todos os horários de servidor e chaves de triagem estão em UTC. A conversão para tempo de aço local está na borda (edge/UI) ou em um serviço de formatação especialmente selecionado.
«Europe/Kyiv» não é apenas «UTC + 02:00». Guarde os ID IANA (tzdb) no perfil do usuário/objeto em vez de «+ 03:00».
Uma clara diferença de relógio.

Wall clock (tempo humano, sujeito a DST).
UTC clock (escala universal).
Monotonic clock (para medição de longas e temporizações). Nunca calculem os horários do relógio.
Idempotidade e tolerância ao tremor do tempo. Os sistemas devem passar corretamente por pequenas quedas NTP/deslocamento.

2) Modelo de dados e contratos API

Eventos: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), opcionalmente 'wall _ time' (local que mantém o deslocamento durante a criação).
Períodos: use intervalos semiabertos '[start, end)' em UTC; Para agendamentos humanos, guarde a expressão original + área.
Regras recorrentes: Seriado como RRULE/cron-equivalente + IANA-zona. Programe delegar um motor que entenda DST.
Formato de tempo na API: ISO 8601/RFC 3339 com «Z» ou deslocamento explícito, como «2025-10-31T17: 00: 00Z». Não passe linhas flutuantes sem deslocamento.
Versioning: Mudança nas regras de tempo do negócio (por exemplo, mudança do país para UTC + 1 permanente) - migração de configurações e reajuste de horários; leve em consideração nos esquemas de versão.

3) Horário de Verão (DST): ambiguitas e passagens

Tempos locais duplicados. «02:30» pode acontecer duas vezes no outono. O planejador da área deve distinguir entre '2025-10-26T02: 30 + 03' e '2025-10-26T02: 30 + 02'.
Tempos locais perdidos. Na primavera, não existem intervalos de minutos (por exemplo, '02: 00-03: 00'). O programador deve definir uma estratégia para «03:00», omitir ou executar «o mais rápido possível».
Recomendação: guarde a tarefa como «regra local + zona» e materialize as instâncias reais no UTC com antecedência (rolling window), fixando a política selecionada em DST.

4) Leap seconds и time smear

Leap second. Um segundo adicional às vezes é inserido no UTC. A maioria dos processos não deve «ver» 23:59:60.
Smear (amassar). Alguns ambientes distribuem suavemente o ajuste para a janela (por exemplo, por exemplo, £12 horas) para evitar o salto.
Prática: Alinhe uma única política de tempo para todo o cluster (NTP/smir), regue-a em metadados e mantenha-a no runbook.

5) Planejadores e cron-patters

O perigo do simples cron. Cron clássico não conhece DST nem áreas IANA. Use os motores onde a programação está ligada à área (Classe Quartz, Serviços Scheduler na nuvem, Kubernetes CronJob com área através do controlador/adição).
A materialização dos horários. Para ser confiável, materialize os próximos N de lançamentos em UTC (por exemplo, de 7 a 30 dias), armazene o cursor e defina a política em DST.
Idempotidade de tarefas. Ключ deduplication: `(job_id, scheduled_at_utc)`; a reativação não deve duplicar efeitos secundários.
Deslizamento de horas. Em casos de pausas/incidentes prolongados, decida se você pode fazer catch-up (executar omissão) ou skip. Configure per-job.

6) Tempo em protocolos e filas

Pneus de evento (Kafka/Pulsar). Guarde 'event _ time' e 'ingest _ time' separadamente. Use «event _ time» para redefinir.
Consumidores Idumpotentes. Quando você voltar a entregar, direcione-se para a chave de evento e 'event _ time', em vez de se deslocar para a partição.
Triagem e janelas. As janelas «24 horas no horário local da loja» calculem como intervalos UTC obtidos a partir de regras locais de uma área específica em uma data específica.

7) Logs, traçados, métricas

Padrão de tempo único: todos os logs técnicos e métricas em UTC (com «Z»). A exibição em dashboards é localizada para o usuário.
Traçados: passe 'trace _ start _ utc', 'duration _ ms' em relógios monotônicos. Nunca subtraiam os times.
Relatórios de negócios: produza «24 horas» em uma área de domínio (por exemplo, «Europe/Paris» para imposto francês) em vez de UTC. Documentem claramente.

8) Perfis e conteúdo personalizados

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Entidades multibilionárias: para comandos/organizações, guarde «área de domínio» (por exemplo, loja/direito) independentemente da área pessoal do participante.
Notificações: calcule o «relógio silencioso» na área de utilizador; enviar um shedulite de uma janela UTC com segurança para DST.

9) Anti-pattern

Armazenar apenas tempo local sem deslocamento/zona.
Pedir com força o deslocamento '+ hh: mm' em vez do ID IANA.
Contar as durações através da diferença de dois times «estampados».
Planejar por cron sem suporte para áreas/DST.
Fazer análise «por dia» na UTC, quando a norma requer área local.
Supor a permanência das regras da zona (os países mudam a política do tempo).

10) Testes de tempo

Relógio controlado. Insinua o «relógio» no código (Clock/TimeProvider) para testes determinados.

• Mudança para horário de verão/inverno (duplos/passagens).
• Mover o usuário entre as zonas (mudar 'preferred _ timezone').
• Altere as regras no tzdb (atualização da base - testes de regressão).
• Deslocamentos NTP, entrega de eventos atrasada.
• Testes de Fazzi. Zonas aleatórias, datas, formatos; comparação com a biblioteca de referência.

11) Observabilidade e exploração

Alerts: NTP de descolonização, tzdb de atualização atrasado, tarefas de cron não cumpridas em DST.
Dashboards: distribuição de eventos por zona/dia local; contadores catch-up/skip.
Runbook: procedimentos para mudança de regras de tempo na jurisdição; ordem de atualização do tzdb; Comunicação com os donos dos horários.

12) Pattern de implementação

Time Normalization Gateway. Serviço fino que normaliza os tempos entrantes do RFC 3339 UTC, valida áreas (IANA) e contexto complementar.
Local-Day Builder. Biblioteca/serviço que, a partir do «dia local» e da zona, constrói exatos limites UTC '[start _ utc, end _ utc', considerando DST.
Schedule Materializer. O planejador que armazena regras como «expressão local + zona» materializa futuras instâncias em UTC e controla conflitos/omissões.
Dual-Timestamp Events. Eventos com os campos 'occurred _ at _ utc', 'wall _ time _ local', 'timezone'. Para a UI é atribuído o local, para os sistemas é UTC.

13) Folha de cheque do arquiteto

1. O UTC está armazenado em todo o lado?
2. As entidades da área IANA e a política de dados do domínio?
3. O planejador compreende o DST e materializa as instâncias na UTC?
4. Logs/métricas - em UTC; relatórios - na área de domínio?
5. Timeouts/retrai em relógios monotônicos?
6. A atualização tzdb é automatizada e monitora?
7. Os testes cobrem mudanças de regras, duplicações/omissões de minutos?

14) Mini-receitas (pseudocode)

Converter «dia de trabalho» local em 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)

Materializar agendamento repetitivo

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 }

Chave Idimpotente para iniciar a tarefa

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

15) Segurança e conformidade

Auditoria: guarde ambas as projeções de tempo (UTC e local) para alinhar as reclamações do usuário («me prometeram até 23h00 em Lima») com a cronologia do servidor.
Regulação: os períodos de relatório são formados em áreas necessárias (impostos, limites de jogo responsáveis, restrições de marketing «por relógio»).
Privacidade: fuso horário - configurações pessoais, mas não dados precisos de identificação; processa dentro de políticas gerais de privacidade.

Conclusão

«Sensibilidade ao tempo» não é sobre o formato da data, mas sobre os limites arquitetônicos da responsabilidade: onde armazenar, onde converter, como planejar e como provar a correção. Unificação em nível UTC, áreas IANA explícitas, planejadores bem educados, times duplos e relógios monotônicos transformam o tempo de fonte de incidentes em um serviço previsível de infraestrutura.

• GeoDNS e geo-rotação; Balanceamento de carga; Observação de eventos no tempo; Cron-pattern e materialização dos horários; Limitações regionais e 24 horas locais de relatórios.