Você pode querer pegar algumas ideias da minha implementação das datas de Início/Fim de Vouchers na caixa de diálogo Novo Voucher em um e-commerce em que estou trabalhando:
Outro exemplo para demonstrar a flexibilidade e como evitamos ambiguidades em intervalos de datas na interface do usuário:
Detalhe técnico: Em nosso aplicativo, sempre salvamos datas como “timestamp com fuso horário” (postgres), portanto, nenhuma configuração de banco de dados ou configuração de conexão pode afetar o timestamp real armazenado. Mesmo que o Postgres não recomende, nós o fazemos porque isso garante 100% de correção da data em qualquer situação e em qualquer consulta SQL. Você pode operar com fusos horários de data diretamente no postgres usando suas funções de data/hora/fuso horário e ter certeza de que funcionará 100% corretamente sempre. Nós confiamos nisso.
E então temos uma configuração de fuso horário para todos os tipos de entidades que precisam dela: perfis de usuário, mercados, vouchers, relatórios para contadores, e assim por diante - para que possamos traduzir quaisquer datas para quaisquer fusos horários instantaneamente, sem hesitação.
As principais conclusões aqui são:
- Sempre armazene data e hora com fuso horário.
- Sempre armazene a preferência de fuso horário.
- Seja muito explícito sobre as datas na interface do usuário, não faça nenhuma mágica.
- Deixe o usuário ver as datas reais no fuso horário escolhido antes de clicar em “Salvar”.