Mi sitio web tiene eventos programados regularmente por el usuario. En este momento estamos usando nuestra zona horaria EDT (o EST) como la zona horaria base para todos los eventos en el sitio. Siento que esto es 1) incorrecto o 2) muy confuso. Actualmente, tenemos usuarios en todo Estados Unidos y Europa.
¿Es el método adecuado para localizar las horas en función de la zona horaria de los clientes? usa UTC / GMT?
Gracias
Respuestas:
Honestamente, este es un problema que se ve con frecuencia cuando se utiliza un sitio web en varias zonas horarias. Hay una larga lista de formas de superar la batalla. Para resumir badp, hay muchos factores que contribuyen a cómo se procesan las diferentes zonas horarias.
La mayoría de los sitios web optan por una de dos soluciones diferentes para abordar este problema:
1) Almacene cualquier cosa que implique una fecha como UTC en la base de datos ... y permita una configuración definida por el usuario para que los usuarios de su sitio web elijan en qué zona horaria se encuentran ... o haga un poco de magia de búsqueda de geo-ip para averiguar en qué parte del mundo se encuentran y encontrar la zona horaria adecuada ... y luego cada vez que muestre la fecha ... asegúrese de llamar a cualquier función necesaria para la localización. Casi todos los lenguajes de programación tienen algún método para mostrar fechas usando una zona horaria específica. También debería hacer esto a la inversa para los usuarios que insertan fechas. (tome la hora local y vuelva a convertir a UTC para el almacenamiento de DB) Este es probablemente el enfoque más común. Esto también le ahorrará mucho tiempo al tratar de "reinventar la rueda". En cuanto a los visitantes anónimos ... puede A) quedarse con EST / EDT (utilizando llamadas a funciones incorporadas para mostrar según corresponda) o B) volver al aspecto de Búsqueda de IP-Geo y elegir una zona horaria basada en una suposición informada. También es una buena idea especificar siempre la zona horaria en la que se muestra la fecha / hora. Es decir, nunca diga "12:00" ... asegúrese de que diga "12:00 EDT"
o 2) Siga el modelo de stackexchange (y muchos otros) para mostrar la diferencia entre ahora y cuando se creó la publicación. es decir, en lugar de "publicado en fecha x" ... haría "hace x horas" o "hace x días x horas", etc ... o para fechas futuras ... "en 6 días 14 horas ..." Esto se está volviendo cada vez más común en muchas situaciones ... pero no es tan ideal para horarios tipo calendario.
Por supuesto ... aún puede adoptar algún tipo de híbrido de los dos ... y es posible que deba ir un paso más allá y almacenar las fechas como utc ... pero también almacenar una zona horaria específica para un evento. En definitiva, la decisión es tuya.
Aquí está el problema: la UE y los EE. UU. No activan y desactivan el horario de verano al mismo tiempo; Este marzo, hubo una diferencia de tres semanas entre estos eventos.
Esto es lo que sucede durante este período. Supongamos que tiene un evento todos los días a la misma hora y, dado que reside en los EE. UU., Ajustará los horarios con el horario de verano de EE. UU.
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
Analicemos todas las posibilidades:
Si muestra la hora en una zona horaria global y la llama UTC , lo que parece ser lo correcto, confundirá a sus clientes estadounidenses, que verán diferentes horas UTC (ayer 8 p.m., hoy 7 p.m.) para la misma hora del reloj de pared (ayer a las 3 p.m., hoy a las 3 p.m. de nuevo), y luego a sus clientes con sede en la UE, que no ven el cambio del reloj de tiempo publicado y, sin embargo, deben cambiar la hora del evento del reloj de pared.
Si muestra la hora en una zona horaria global y la llama GMT , además de confundir a los clientes de EE. UU., También confundirá a los clientes del Reino Unido que cambian de GMT a BST. Es contradictorio entender que EDT 1500 y EST 1400 son el mismo momento en el tiempo; ahora traduzca eso a BST / GMT (con el problema adicional de que no va a mostrar tiempos BST en ninguna parte del sitio).
Si muestra la zona horaria en una zona horaria de la UE (usé CET / CEST para evitar la confusión GMT / UTC), eso obviamente será muy confuso para sus clientes de EE. UU. la hora del reloj cambia ellos mismos. Si bien sus clientes estadounidenses pueden estar preparados para el primer cambio (después de todo, tienen que cambiar sus relojes de pared el mismo día), estos últimos les sorprenderán.
Si muestra la zona horaria en la zona horaria de EE. UU. (Como EST / EDT ), tendrá la situación exacta explicada anteriormente, ¡pero reflejada!
¡Esto parece una situación desesperada! Así es como llegué a abordarlo después de cuatro años de pasar por este rigmarole (dos veces al año, obviamente): "inventar una zona horaria".
Estoy exactamente en la situación que se muestra arriba, así que inventé "NYT" (zona horaria de Nueva York) para poder escribir "1500 NYT" que significa "3pm en cualquier zona horaria que Nueva York esté usando".
Esto tiene la ventaja de que, siempre que el usuario sepa que el vals DST está sucediendo, tiene una forma muy sencilla de convertir de ida y vuelta a su propia zona horaria: google " hora en Nueva York " para ver qué hora es en Nueva York , luego resuélvelo desde allí. Incluso puede ser elegante y usar servicios basados en geolocalización como time.is/15:00_in_New_York .
Tenga en cuenta que, si bien puede usar nombres de abreviaturas de zona horaria en time.is, le insto a que no lo haga, ya que están bastante confundidos al respecto: EST tiene el mismo tiempo que EDT‽
Puede notificar a los usuarios sobre el horario de verano con un breve resumen, vinculando a un servicio web de conversión de tiempo apropiado para ayudar a las personas. Idealmente, todas las marcas de tiempo deberían tener una opción para convertirse a la hora local.
Cuando todo está dicho y hecho, debes darte cuenta de que he estado ignorando al elefante en la habitación todo el tiempo, y esa es la solución de "cuenta regresiva" que ya has implementado. No hay nada confuso sobre "en 1 día 2 horas 45 minutos 47 segundos" (y si cree que no necesita tanta precisión, es posible que desee volver a pensar ).
Claro, en mi experiencia nunca tuve el lujo de algo que no fuera texto estático, así que tuve que manejar el increíble desastre que se muestra arriba (¡y eso es solo el comienzo ! ¿Qué tal el emisario sur, que hace el DST al revés?) , pero para su caso de uso, parece la solución con el menor potencial de confusión. Es posible que reciba dos hilos al año preguntando sobre eventos "en 23 horas" y "en 25 horas", mientras que normalmente cuenta regresivamente desde "en 24 horas", pero eso es todo.