Prática recomendada para armazenar o DateTime com base no fuso horário

Desenvolvimento de um aplicativo da web que permita ao usuário agendar compromissos com base no fuso horário. E estou armazenando o datetime do usuário agendado como datetime do servidor no campo do banco de dados. Ao mostrar as informações de agendamento, o valor do banco de dados foi recuperado e convertido no fuso horário do usuário. processamento na base de código Estou convertendo o DateTime com base no fuso horário do usuário. Sugira que esta é uma prática recomendada ou existe alguma maneira fácil?

Bem-vindo a um dos problemas mais difíceis da programação não computacional - representando corretamente datas e horas para os usuários finais.

Realisticamente, os carimbos de data e hora devem ser armazenados em uma única representação fixa, independentemente de como serão interpretados, porque, por mais que você tente, sempre terá casos ambíguos e não poderá resolvê-los sem uma representação fixa. E você escolheu um dos piores casos de uso - agendar um compromisso. O único pior caso de uso comum são as viagens aéreas, nas quais uma viagem pode começar em um fuso horário e terminar em outro, possível em um horário local anterior.

Sempre, sempre, SEMPRE armazene no UTC e exiba no fuso horário preferido ou especificado explicitamente pelo usuário. Se possível, faça com que o usuário diga em que fuso horário acredita que o carimbo de data / hora deve estar quando o inserir ( por exemplo , tenha um campo explícito de fuso horário e preencha-o previamente com sua zona preferida).

A maneira mais fácil de lidar com informações de data / hora depende dos requisitos do seu aplicativo.

Se a data e a hora forem inseridas pelo usuário e o servidor não processar essas informações de data / hora, exceto para armazená-las em um banco de dados e não houver expectativa de que a hora inserida seja adaptada ao local em que é exibida (por exemplo, , o usuário inseriu "20:00" e deve ser exibido como "20:00", independentemente do local em que for visualizado). A maneira mais fácil é armazenar o DateTime como horário local sem nenhuma informação de fuso horário.

Por outro lado, se o servidor precisar usar o DateTime inserido como um gatilho para fazer algo, ou se o horário deve ser ajustado corretamente para o fuso horário atual, sua melhor opção é armazenar o DateTime como horário UTC e ajustá-lo ao local hora (para o local atual do usuário) sempre que você o lê no banco de dados.

É importante que você não confunda dois conceitos relacionados.

Se você está manipulando um ponto no tempo real, ou seja, um horário específico em um dia específico, a única maneira de fazer isso é sempre usar o valor universal do horário UTC. Nunca tente armazenar isso como um valor relevante para o fuso horário. Ao exibir esse valor de hora para um usuário, sempre converta para o fuso horário do usuário naquele horário. (E não esqueça que a hora e a data dependem do fuso horário.)

O outro conceito é o de uma "expressão de tempo", como "20:00 toda terça-feira". Você mencionou especificamente permitir que as pessoas agendem compromissos e, se você tiver compromissos recorrentes, precisará de uma expressão como essa. Não conheço nenhuma linguagem de expressão padrão, mas, o que quer que você use, será relativo ao fuso horário da pessoa que a especificou. Seria melhor deixar isso explícito, por exemplo, "20:00 toda terça-feira no fuso horário do Pacífico". No caso de uma expressão de hora, você a armazena sempre como uma sequência e nunca envolve nenhum formato de hora do sistema.

Veja mais discussões sobre isso no meu blog

Muitas respostas aqui indicam o armazenamento como UTC. Mas tenha muito cuidado com isso. Por exemplo, se você agendar um compromisso às 12:00, mas o compromisso ocorrer após a alteração do horário de verão, o que acontecerá? O UTC não mantém nenhuma informação sobre se o dst estava ativo quando o compromisso foi armazenado. Muitos sistemas grandes e famosos cometeram esse erro, onde um usuário envia um email às 9h no verão e, no inverno, o horário enviado mostra 8h, porque o cálculo do UTC depende de quando você olha para a data e hora, não ligado quando a data e hora foram gravadas.

Muito melhor é assumir que seu usuário deseja ter os horários que escolheu sempre. Nenhuma conversão UTC, nenhuma conversão de tempo, nenhuma informação de fuso horário, nada. Marcar uma consulta das 08:00 às 12:00 de 21 de março de 2016 é exatamente isso. Não use a hora local ou a hora UTC, mas a hora não especificada (no json, isso não tem z nem +, basicamente, no .NET, ele tem DateTime.Kind = DateTimeKind.Unspecified).

Obviamente, se seu caso de uso é que você é uma empresa que realiza reuniões com alguém de fusos horários diferentes e deseja ver essas informações em, por exemplo, um calendário da empresa, mas permite que os usuários vejam a que horas é o fuso horário, fica mais complicado. O horário deve ser correto para pessoas diferentes em fusos horários diferentes (o fornecedor e o cliente).

Nesses casos, você pode até querer registrar quando o compromisso foi salvo no banco de dados, em que fuso horário e se isso incluía o dst ou não. Dessa forma, você sempre pode calcular a hora local para qualquer outra coisa, seja para o que seria agora ou para o que deveria ser historicamente. Como os fusos horários não são estáticos, tornando as coisas ainda mais complicadas.

Felizmente, é aqui que as bibliotecas como http://nodatime.org/ entram e são altamente recomendadas. Eles trabalham com datas de maneira muito mais consistente. Mesmo assim, eu recomendaria agrupar todas as suas variáveis ​​de data e hora e lógica em seus próprios wrappers, usando interfaces para que elas possam ser zombadas e, em seguida, você ainda poderá alternar a lógica posteriormente.