Executando verificação de segurança...
2

Realmente lidar com isso é extremamente complicado. Eu vou só dar uma pincelada superficial.

Se vai trabalhar com datas, não use horário junto. Se fizer isso não terá muitos problemas. Se a tecnologia usada não tem data sozinha, azar, você terá que pelo menos na manipulação desconsiderar e zera o horário sempre, aí não dá problema com fuso horário.

Utilize sempre tipos prontos para lidar com isso, a não ser que não tenha outra forma. Em geral é mais bem feito do que você poderá fazer. O assunto é complexo demais, e cheio de armadilhas para você tentar reproduzir. Dá muito trabalho e provavelmente será bugado. Isso vale até para banco de dados, não se deve inventar maneira de armazenar (o SQLite não tem data, tem que usar uma forma de timestamp e definir regras).

Para problemas de fuso, tem solução relativamente simples. A não ser que tenha uma indicação para fazer diferente deve-se trabalhar com UTC, ou seja, fuso horário neutro. Assim não dá problema. Somente na interação com o cliente é que o fuso deve ser considerado (se fizer sentido), então quando o usuário escolhe um horário ou vai mostra para ele é feita uma conversão entre UTC e o fuso que se sabe que ele usa. E o ideal é usar algo pronto e não tentar reinventar a roda que é difícil. A maior parte das soluções que as pessoas apresentam são gambiarras.

Eu acho que o kht dará uma resposta mais completa, já que ele tem até livro publicado sobre o assunto.

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
1

Isso mesmo, maniero. Nos casos de atributos que representam o momento exato (como data de criação do post) eu sempre uso epoch number. Daí realmente não há problemas e a data sempre será exibida corretamente no navegador do usuário, não importando o timezone. A armadilha mesmo é em datas onde o timezone não pode alterar a exibição, como a data de nascimento.

Eu deixei de usar tipos nativos de bancos de dados (date, timestamp, timestampz, etc), pois alguns têm e outros não, e eventualmente se você está em um ambiente de microsserviços onde cada um usa um banco diferente (incluindo ai bancos não relacionais), isso pode ser um problema. Sem contar questões de performance (campos do tipo numérico tem uma indexação muito mais rápida que tipos nativos como date ou timestamp). Eu procuro sempre adotar somente os tipos mais primitivos possíveis na persistência, o que acaba ficando restrito a strings, números e booleano, e colocar no espaço das regras de domínio a forma como eles podem ser criados, alterados, etc.

Mas como eu disse, não há um certo ou um errado, são apenas formas diferentes de abordar o problema!

Obrigado pela sua contribuição à discussão!!