Observação: O formato utilizado nesta seção foi fortemente inspirado neste repositório, que faz um EXCELENTE trabalho explicando boas práticas de Testes de Integração em Node. Recomendo fortemente para todos que trabalham com essa tecnologia.
🏷 Tags: #boaspraticas
✅ O que fazer: Sua aplicação nunca deverá lidar com data separada de hora ou hora separada de data. Mesmo que para um caso de uso específico você precise apenas de uma das duas informações, sua vida ficará muito mais simples se você lidar apenas com variáveis de datahora (datetime). Isso significa que qualquer definição formal dentro do seu sistema como colunas de banco de dados, propriedades de classes, parâmetros de funções e etc devem ser do tipo datahora e conter ambas as partes desta informação.
👀 Alternativas: Definir variáveis que armazenam apenas a data de forma a simplificar algumas das suas operações, mas a custo de perda de flexibilidade e manutenibilidade já que qualquer pequena mudança de requisitos (ex: instituir internacionalização no sistema) pode fazer com que seja necessário grande volume de reescrita de código ❌;
🏷 Tags: #boaspraticas
✅ O que fazer: As datahoras do seu sistema devem ser armazenadas no seu back-end em formato UTC. É importante que todas as datahoras usem a mesma timezone para manter a consistência e facilitar os cálculos, e dado que podem haver modificações de fuso horário devido a novos tipos de usuários ou novas features, usar UTC prepara o sistema para operar de uma forma mais robusta e adaptável para qualquer contexto. Se feito corretamente, utilizar UTC não deve dificultar o desenvolvimento.
👀 Alternativas: Usar algum fuso horário em particular para as datas armazenadas. Não recomendado pois torna o sistema muito frágil e abre brecha para problemas de funcionamento advindos de pessoas utilizando seu sistema de áreas inesperadas (com diferentes fusos), ou coisas do tipo. ❌;
🏷 Tags: #boaspraticas
✅ O que fazer: Dado que as datahoras estarão num formato padronizado UTC armazenadas no back-end (dica #2), ao receber esses dados a nossa aplicação cliente (front-end) deve realizar uma conversão dessa data UTC para o fuso horário local do usuário antes de exibir a informação. Ao enviar requisições para o back-end, seu front deverá enviar a data local, seguindo um padrão pré-definido (ver dica #4) que estiver sendo usado, e será responsabilidade do back-end realizar a conversão de volta para o formato UTC antes de realizar quaisquer tipos de operação com os dados recebidos.
👀 Alternativas: Converter para os horários locais antes de retornar ao front-end. Pode ser muito mais difícil devido a dificuldade do servidor de saber com certeza em qual zona temporal cada cliente se encontra. ❌;
🏷 Tags: #boaspraticas
✅ O que fazer: Além de utilizar o formato UTC exclusivamente no back-end, precisamos definir algum formato padrão (ex: ISO 8601) a ser seguido para a exibição de datas no front-end. Essa decisão deve ser feita com a maior antecedência possível, e documentada de forma clara e fácil de ser consultada pelas pessoas desenvolvedoras do projeto.
👀 Alternativas: Permitir que os próprios desenvolvedores tentem acertar qual é o formato correto ❌;
As dicas presentes nesta seção vieram de uma junção da experiência de trabalho do "Core Team" de contribuidores deste projeto em conjunto com outros conteúdos em inglês presentes na web.
Para cada novo PR para esta lista de dicas, continuaremos exigindo as referências externas de forma a enriquecer a base de conhecimento e permitir que as pessoas consultem estas fontes de forma a aprofundar nos assuntos debatidos aqui.