Aniversário Do Mundo Bita

Calendando aniversários de forma que não quebre no fim do ano

Muita gente acha que calcular um aniversário é só somar 365 dias num timestamp. Funciona na maior parte das vezes, até você precisar lidar com an bissextos, fusos horários e datas que não existem todo ano. Quando eu montei meu primeiro sistema de gerenciamento de eventos para uma plataforma brasileira, a gente subestimou completamente como aniversário do mundo bita poderia virar um problema real de negócio. Não é o conceito romântico de "hoje todos nós nascemos no mesmo dia". É isso, mas em escala de milhares de usuários, múltiplos fusos, e regras de negócio que você não previa.

Por que aniversários de aniversário mundial são mais chatos do que parecem

O conceito básico é simples: 1º de janeiro às 00:00 UTC é o ponto de partida. Todo ser humano vivo nasceu depois disso. O problema aparece quando você precisa calcular aniversários relativos, notificações, ou qualquer coisa que dependa de data/hora precisa em produção. A primeira vez que eu vi um bug relacionado a isso, foi porque um usuário no horário de verão brasileiro recebeu a notificação de aniversário com um dia de atraso. O sistema estava usando UTC, o usuário estava em Brasília, e a transição de fuso tinha feito o timestamp "pular" sem eu perceber. Minha solução foi trocar toda a lógica para trabalhar internamente com data local do usuário, só convertendo para UTC na persistência. E garantir que eu nunca guardasse um timestamp UTC esperando que ele se traduzisse corretamente de volta para o fuso do usuário sem ter registrado o fuso original.

Como implementar sem perder horas debugando

Você precisa de três coisas que a maioria dos desenvolvedores iniciantes esquece: 1. Armazene o fuso horário junto com a data. Não basta salvar "29 de fevereiro de 2024". Precisa saber que aquele dia pertence a qual timezone. Quando você chamar uma biblioteca de manipulação de data sem passar o fuso, ela vai assumir o fuso do servidor. Se o servidor estiver em São Paulo e o usuário em Nova York, seu aniversário vai estar errado. 2. Use bibliotecas matureiras, não make-shift. Moment.js tá morto. Date-fns ou a API nativa do navegador são opções razoáveis. O problema é que até elas têm edge cases. A API nativa do JavaScript, por exemplo, não lida bem com datas inexistentes. Criar um objeto Date para 29 de fevereiro de 2023 não falha — ele "roda" para março. Isso parece conveniente até você perceber que seu sistema de lembretes de aniversário está notificando pessoas erradas.

3. Teste com anos bissextos e transições de DST. Eu tenho um conjunto de testes de integração que rodava todas as combinações possíveis de nascimento em anos bissextos, em fusos com e sem horário de verão, em datas de transição. Leva uns 4 minutos pra rodar. Se passar, você dorme tranquilo.

O problema que ninguém conta sobre aniversário do mundo bita

Existe uma diferença enorme entre tratar o aniversário como um conceito filosófico e tratar como um campo num banco de dados. O primeiro não tem constraint. O segundo precisa decidir o que acontece quando o aniversário cai em 29 de fevereiro e o ano não é bissexto. Alguns sistemas tratam isso como 28 de fevereiro, outros como 1º de março. Eu preferi deixar isso configurável por usuário, porque não existe resposta certa. Outro problema real: o conceito de "aniversário do mundo" como evento cultural. Se você vai notificar usuários sobre isso, precisa considerar que nem todo mundo celebra data religiosa ou culturalmente neutra. E mesmo numa abordagem secular, há usuários que simplesmente não querem receber notificações de aniversário. Implementar um flag de permissão e respeitar de verdade economiza bastante suporte depois. A parte mais chatinha que eu encontrei na prática foi com usuários de regiões que não usam o calendário gregoriano. Se o seu sistema só lida com datas no padrão ocidental, você vai perder uma fatia considerável da base ou simplesmente mostrar datas erradas. A solução prática que eu vi funcionar foi manter o gregoriano como padrão mas permitir cadastro de datas alternativas em campos separados, sem misturar os dois calendários na mesma lógica.

Se o seu projeto é pequeno e você não precisa de notificações em escala, fazer isso na mão com um script simples resolve. Se vai crescer, invista na estrutura correta desde o início. A segunda versão do meu sistema levou metade do tempo de desenvolvimento porque eu não tinha que reescrever a camada de data depois que o bug apareceu.