Meu site tem eventos programados regularmente pelo usuário. No momento, estamos usando nosso fuso horário EDT (ou EST) como o fuso horário base para todos os eventos no site. Eu sinto que isso é 1) errado ou 2) muito confuso. Atualmente, temos usuários em todos os EUA e Europa.
O método adequado para localizar horários é baseado no fuso horário dos clientes? usar UTC / GMT?
obrigado
Honestamente, esse é um problema frequentemente visto ao ter um site usado por vários fusos horários. Há uma longa lista de maneiras de superar a batalha. Para resumir o badp, há muitos fatores que contribuem para o processamento de diferentes fusos horários.
A maioria dos sites opta por uma das duas soluções diferentes para solucionar esse problema:
1) Armazene qualquer coisa que envolva uma data como UTC no banco de dados ... e permita uma configuração definida pelo usuário para os usuários do seu site escolherem em que fuso horário eles estão ... ou faça alguma mágica de pesquisa geográfica-ip para descobrir onde estão no mundo e encontre o fuso horário apropriado ... e sempre que exibir a data ... chame qualquer função necessária para a localização. Quase toda linguagem de programação possui algum método para exibir datas usando um fuso horário especificado. Você também teria que fazer isso ao contrário para os usuários que inserem datas. (pegue a hora local e converta novamente para UTC para armazenamento em banco de dados) Essa é provavelmente a abordagem mais comum. Isso também pouparia muito tempo de tentar "reinventar a roda". Tanto quanto os visitantes anônimos vão ... você pode A) ficar com o EST / EDT (usando chamadas de função integradas para exibição conforme apropriado) ou B) reverter para a coisa de Geo-IP-Lookup e escolher um fuso horário com base em um palpite. Também é uma boa idéia especificar sempre o fuso horário em que você está exibindo a data / hora. Ou seja, nunca diga "12:00" ... verifique se diz "12:00 EDT"
ou 2) Siga o modelo da stackexchange (e muitos outros) de exibir a diferença entre agora e quando a postagem foi criada. ou seja, em vez de "publicado na data x" ... você faria "x horas atrás" ou "x dias x horas atrás" etc ... ou em datas futuras ... "em 6 dias 14 horas ..." está rapidamente se tornando mais comum em muitas situações ... mas não é o ideal para agendas do tipo calendário.
Claro ... você ainda pode adotar algum tipo de híbrido dos dois ... e pode precisar ir um pouco além e armazenar datas como utc ... mas também armazenar um fuso horário específico para um evento. Em última análise, a decisão é sua.
Aqui está o problema: a UE e os EUA não ligam e desativam o horário de verão ao mesmo tempo; em março, houve uma diferença de três semanas entre esses eventos.
Aqui está o que acontece durante esse período. Digamos que você tenha um evento todos os dias no mesmo horário e, como está nos EUA, você ajustará os horários usando o horário de verão dos EUA.
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
Vamos analisar todas as possibilidades:
Se você exibir a hora em um fuso horário global e chamá-la de UTC , que parece a coisa certa a fazer, você confundirá seus clientes americanos, que verão horários diferentes da UTC (ontem às 20h, hoje às 19h) para o a mesma hora do relógio de parede (ontem às 15:00, hoje às 15:00 novamente) e, em seguida, aos clientes da UE, que não vêem o relógio publicado mudar e ainda precisam alterar o horário do evento.
Se você exibir a hora em um fuso horário global e chamá-la de GMT , além de confundir os clientes dos EUA, também confundirá os clientes do Reino Unido que mudam de GMT para BST. É contra-intuitivo entender que EDT 1500 e EST 1400 são o mesmo momento no tempo; agora traduza isso para o BST / GMT (com o problema adicional de que você não mostrará os horários do BST em nenhuma parte do site).
Se você exibir o fuso horário em um fuso horário da UE (usei CET / CEST para evitar confusão GMT / UTC), isso obviamente será super confuso para seus clientes nos EUA, que vêem o horário do evento alternar duas vezes e ainda não experimentam parede a hora do relógio muda. Embora seus clientes nos EUA possam estar preparados para a primeira troca (depois de tudo o que precisam trocar de relógio de parede no mesmo dia), eles ficarão surpresos com a segunda.
Se você exibir o fuso horário no fuso horário dos EUA (como EST / EDT ), terá a situação exata explicada acima, mas espelhada!
Parece uma situação desesperadora! Eis como cheguei a resolvê-lo depois de quatro anos passando por esse truque (duas vezes por ano, obviamente): "invente um fuso horário".
Estou exatamente na situação mostrada acima, então criei "NYT" (fuso horário de Nova York) para poder escrever "1500 NYT" para significar "15:00 em qualquer fuso horário em que Nova York estiver usando".
Isso tem a vantagem de que, desde que o usuário saiba que a valsa DST está acontecendo, ele tem uma maneira muito simples de converter o seu fuso horário: google " time in new york " para ver que horas são em NY , então trabalhe a partir daí. Você pode até gostar e usar serviços baseados em geolocalização, como time.is/15:00_in_New_York .
Observe que, embora você possa usar nomes de abreviação de fuso horário em time.is, exorto a não fazê-lo, pois eles mesmos são bastante confusos: a EST tem o mesmo tempo que a EDT‽
Você pode notificar os usuários sobre o horário de verão com algumas informações curtas, vinculando-as a um serviço da web de conversão de horário apropriado para ajudar as pessoas. Idealmente, todos os registros de data e hora devem ter uma opção para serem convertidos em horário local.
Quando tudo estiver dito e feito, você deve perceber que eu tenho ignorado o elefante na sala o tempo todo, e essa é a solução de "contagem regressiva" que você já implementou. Não há nada de confuso sobre "em 1 dia 2 horas 45 minutos 47 segundos" (e se você acredita que não precisa de tanta precisão, convém pensar novamente ).
Claro, na minha experiência, nunca tive o luxo de nada que não fosse texto estático, então tive que lidar com a bagunça incrível na foto acima (e isso é apenas o começo ! E o emisfério sul, que faz o DST ao contrário?) , mas para o seu caso de uso, parece a solução com o menor potencial de confusão. Você pode receber dois tópicos por ano perguntando sobre os eventos "em 23 horas" e "em 25 horas", enquanto a contagem normalmente é reduzida de "em 24 horas", mas é isso.