Sobre Datas É Correto Afirmar Que

Como entender datas de verdade, não só a teoria da escola

A maioria das pessoas acha que saber datas é coisa simples. O calendário que você vê no celular não mente, certo? Errado. Trabalhando com sistemas e processamento de informação, eu vi gente perder horas porque assumiu que todo mundo vive na mesma fuso horário. Que ano tem 365 dias. Que mês tem sempre a mesma quantidade de dias. O problema real começa quando você precisa comparar, ordenar ou calcular intervalos entre datas. Aí aparecem os erros. Eu já passei por uma situação em que um relatório financeiro estava com dias errados porque alguém converteu datasUTC para horário local sem considerar o horário de verão que existia na época. O sistema pensava que estava em janeiro, mas na verdade era dezembro do ano anterior.

sobre datas é correto afirmar que

elas são conceitos que variam conforme o contexto e o sistema utilizado. Na prática, isso significa que uma data pode ser armazenada de formas completamente diferentes. Formato ISO 8601 mostra uma coisa, timestamp UNIX mostra outra, e dependendo da biblioteca ou linguagem que você usa, o resultado final pode divergir. Um dos erros mais comuns é assumir que datas são apenas números. Elas não são. Data envolve calendário, timezone, horário de verão e regras históricas que mudam. O Brasil mudou o horário de verano várias vezes, às vezes no meio do ano, às vezes suspendeu por decreto. Se seu código não leva isso em conta, os cálculos ficam errados. Outro ponto que muita gente não considera é a diferença entre data e timestamp. Data é um conceito humano. Timestamp é uma contagem de segundos desde janeiro de 1970. Quando você converte um timestamp para data, o resultado depende do timezone. Quando converte data para timestamp, o resultado também depende do timezone. Dois timestamps iguais podem representar datas diferentes se estiverem em fusos distintos.

Na minha experiência, o melhor workaround foi parar de confiar em funções nativas de conversão e passar a usar bibliotecas especializadas. No início eu achava que a função Date do JavaScript ou o datetime do Python eram suficientes. Até que um cliente relatou que os agendamentos apareciam com dia errado quando o usuário estava em Manaus. A solução foi adotar a biblioteca momento.js com extensões de timezone, e depois migrar para a alternativa @fullcalendar/core que lida melhor com essas variações. Limitações importantes existem. Mesmo com boas bibliotecas, datas históricas antes de 1970 ou após 2038 podem causar problemas. O Unix timestamp tem limite de 32 bits em alguns sistemas antigos, o que gera o chamado "bug do ano 2038". Bancos de dados também tratam datas de formas diferentes. MySQL guarda com timezone do servidor, PostgreSQL permite escolher o tipo de dato com ou sem timezone. Migrar dados entre eles sempre gera dor de cabeça. Uma dica prática que pouca gente menciona é: se você trabalha com dados que cruzam fronteiras, nunca armazene datas sem timezone explícito. Use UTC internamente. Converta para o timezone do usuário apenas na exibição. Isso evita aproximadamente 90 por cento dos erros que vejo em produção.

Para quem quer aprofundar, existe uma diferença entre calendar date e ordinal date que muitos ignoram. Calendar date é o formato que usamos no dia a dia, como 15 de março de 2024. Ordinal date é o dia do ano, como 074 para 15 de março. Alguns sistemas usam ordinal para evitar ambiguidades em culturas que não padronizam o formato mês/dia/ano. O campo de datas também envolve leap seconds, que são ajustes adicionados ocasionalmente para manter a sincronia entre o tempo atômico e a rotação da Terra. A maioria dos sistemas ignora isso, mas em aplicações de alta precisão, como trading ou sincronização de servidores, o salto pode causar descompassos se não for tratado corretamente. No final, a melhor prática que encontrei foi criar uma camada de abstração própria para manipulação de datas. Isso significa ter funções utilitárias para conversão, comparação e formatação que já embedam as regras de negócio do seu domínio. Pode parecer trabalho extra no começo, mas economiza horas de debugging quando o sistema cresce.

Se precisar de referências técnicas, a especificação ISO 8601 é o padrão mais completo. Também recomendo consultar a documentação das bibliotecas que você usa, porque muitas têm comportamentos surpresos que não são óbvios. Testes de integração com datas em diferentes fusos horários valem mais do que qualquer explicação teórica.