Dias entre Datas: por que construir a data com ano/mês/dia, não parsear a string diretamente
Calcular a diferença entre duas datas parece uma subtração simples,
mas esconde uma armadilha real de fuso horário se implementado
ingenuamente. Esta calculadora constrói cada data explicitamente a
partir de ano, mês e dia (new Date(ano, mes - 1, dia),
que o JavaScript interpreta em horário local do
navegador), em vez de passar a string de data diretamente para o
construtor Date (que interpreta strings no formato
ISO como 2026-03-15 em UTC, não em
horário local) — essas duas abordagens podem produzir datas
diferentes em um dia inteiro, dependendo do fuso horário de quem está
usando a ferramenta, se misturadas incorretamente.
Por que a diferença de interpretação causa bugs reais de "um dia a menos"
O bug clássico que essa escolha de implementação evita: se uma data é parseada como string ISO (interpretada em UTC) e depois exibida ou comparada usando métodos que retornam componentes em horário local, alguém num fuso horário atrás de UTC (como o Brasil, UTC-3) pode ver a data exibida como um dia anterior ao que foi digitado — um sintoma real e documentado, não hipotético, de código JavaScript de manipulação de data em produção. Construir a data explicitamente com os três componentes numéricos (ano, mês, dia) evita essa ambiguidade de interpretação desde o início, sem depender de o string parser interpretar corretamente a intenção de fuso.
Por que a divisão é por 86.400.000, não por um número redondo mais simples
A diferença entre duas datas em milissegundos, dividida por
86.400.000 (o número de milissegundos em um dia — 1000ms × 60s ×
60min × 24h), produz a diferença em dias completos. Esse cálculo
funciona de forma confiável exatamente porque, construídas como
horário local à meia-noite dos dois lados, as duas datas não têm
componente de hora residual que complicaria a divisão — se uma das
datas tivesse um componente de hora diferente de meia-noite, a
divisão poderia produzir um resultado fracionário que precisaria de
arredondamento adicional (daí o Math.round() aplicado ao
resultado, uma proteção extra contra pequenas imprecisões de ponto
flutuante, não uma necessidade estrutural do cálculo em si).