Lição 5
Armadilhas comuns de timestamp
Y2038, segundos fracionários, unidades erradas e strings de data ambíguas.
Mesmo quando os formatos parecem simples, timestamps falham de formas previsíveis. Reconhecer o padrão economiza horas de depuração.
Y2038 e limites de inteiro
O overflow clássico de time_t assinado de 32 bits ocorre por volta de 2038-01-19. Sistemas embarcados legados e binários antigos ainda podem usar segundos de 32 bits. Servidores 64 bits modernos em geral evitam isso no armazenamento, mas CSVs exportados e clientes antigos podem não.
Date em JavaScript usa doubles em milissegundos — faixa enorme, mas inteiros muito grandes colados em parsers ainda podem falhar.
Off-by-1000 (segundos vs milissegundos)
Sintomas:
- Data perto de 1970-01-01 → tratou segundos como milissegundos (valor pequeno demais)
- Data no ano 50000+ → tratou milissegundos como segundos
Sempre pergunte: “Este campo está documentado como sec ou ms?”
Strings locais ambíguas
2024-06-01 00:30 sem fuso significa instantes diferentes em Tóquio vs Toronto. Parsear como “local do servidor” vs “local do usuário” vs “UTC” muda relatórios de bug drasticamente.
Lacunas e repetições de horário de verão
Em dias de transição de DST, horários de parede locais podem repetir ou pular. Agendar “2:30 da manhã local” no dia de volta pode ser inválido ou ambíguo. Armazene instantes UTC para alarmes e cobrança.
Surpresas de locale em strings
03/04/2024 é 4 de março nos EUA e 3 de abril na UE. Prefira ISO 2024-03-04 em campos legíveis por máquina.
Conclusão
A maioria dos bugs de timestamp é confusão de unidade, fuso ausente ou limites legados de largura — não matemática exótica. Verifique esses três primeiro.