1. Inicio
  2. Pregunta y respuesta
  3. Javascript/PHP y zonas horarias

Javascript/PHP y zonas horarias

2010-02-23 23 views
6

Me gustaría poder adivinar el desplazamiento de la zona horaria del usuario y si se aplica o no el horario de verano. Actualmente, el código más definitivo que he encontrado para esto es aquí:Javascript/PHP y zonas horarias

http://www.michaelapproved.com/articles/daylight-saving-time-dst-detect/

Así que esto me da el desplazamiento junto con el indicador de DST.

Ahora, quiero usar esto en mis scripts PHP para poder mostrar la fecha/hora local para el usuario ... pero, ¿qué es lo mejor para esto? Me imagino que tengo 2 opciones:

a) Elija una zona horaria aleatoria que tenga el mismo ajuste de compensación y horario de verano de la salida de timezone_abbreviations_list(). Luego, llame a date_timezone_set() con esto para aplicar el tratamiento correcto a la hora.

b) Continúe tratando la fecha como UTC pero solo agregue algunas marcas de tiempo para agregar el número apropiado de horas.

Mi sensación es que la opción B es la mejor manera. La razón de esto es que con A, podría estar usando una zona horaria que, aunque es correcta en términos de desplazamiento/dst, puede tener algunas reglas oscuras detrás de la escena que podrían dar resultados sorprendentes (no conozco ninguna, pero no obstante No creo que pueda descartarlo).

Volvería a verificar la zona horaria con Javascript al inicio de cada sesión para capturar cuando la zona horaria del usuario cambia (muy poco probable) o pasan al período DST.

Disculpe por el vuelco del cerebro: en realidad me acaba de asegurar que los enfoques anteriores son válidos.

Gracias,

James.

Fuente

2010-02-23 James

Respuesta

7

Para determinar con firmeza la zona horaria de un usuario mediante javascript. Consulte jsTimezoneDetect.

Le dará una clave de base de datos de zona horaria de Olsen que puede usar para los cálculos de fecha y hora del lado del servidor.

Fuente

2010-12-29 11:52:08

3

Si esta es una encuesta, entonces "b" es mi voto.

En primer lugar, todos los tiempos deben almacenarse en UTC. Esto es dogma Es un dogma muy sensato, del tipo sobre el que terminas diciendo "ojalá hubiera seguido eso", después de que tu proyecto se vuelve más complicado. Entre otras cosas, es la única manera inequívoca y consistente de almacenar todos los puntos en el tiempo. Cualquier zona horaria con horario de verano tiene referencias de tiempo ambiguas alrededor del interruptor (1:30 a.m. generalmente ocurre dos veces, por ejemplo). Además, al convertir entre zonas horarias, la mayoría de las veces terminas usando UTC como intermediario de todos modos.

En segundo lugar, debe decidir si su sitio es internacional o no. De lo contrario, establezca reglas para las seis zonas horarias de EE. UU. Y finalice. Con tres navegadores que informan las marcas de tiempo en sus propias maneras extravagantes, solo son 18 casos, y debería ser posible manejarlos. Cualquier cosa más allá de eso, y debe suponer que requiere un grado avanzado para anticipar las diferencias de horario de verano. Los tiempos cambian en diferentes días en diferentes lugares.

Su mayor problema con b es que, si se trata de una aplicación similar a un calendario, la programación seguirá siendo un problema si no puede determinar con precisión en qué zona horaria se encuentra alguien. Por ejemplo, suponga que es febrero. Nadie está en horario de verano. Alguien programa algo para las 6pm (local) del 5 de mayo. Usted ve que el desplazamiento es UTC-4. ¿Cómo sabe si esa persona está en New Brunswick, que observa DST (en cuyo caso el tiempo significa es 2100 UTC), o Puerto Rico, que no (en cuyo caso el tiempo significa es 2200 UTC? una pregunta difícil. This post puede tener alguna ayuda.

Fuente

2010-02-23 16:00:11

+0

Hola David, Muchas gracias por su respuesta. Su punto sobre la programación ha desatado una gran cantidad de conversación aquí muy apreciada. Revisando ese enlace ahora ... James. – James

1

Si desea confiar en javascript, puede simplemente enviar la hora/indicación de hora utc hacia adelante y hacia atrás y dejar que el cliente la convierta a su representación de hora local.

edición: ejemplo sencillo autónomo (usando jQuery)

<html> 
    <head> 
    <title>...</title> 
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script> 
    <script type="text/javascript"> 
     function foo(){ 
     $('.time').each(function() { 
      var t = $(this); 
      var d = new Date(Date.parse(t.text())); 
      t.text(d.toLocaleString()); 
     }); 
     } 
    </script> 
    </head> 
    <body> 
    <div class="time"><?php echo gmdate(DateTime::RFC1123); ?></div> 
    <button onclick="foo()">local time</button> 
    </body> 
</html>

Si Javascript no está disponible el usuario sigue viendo una fecha/hora, aunque es en UTC.
edit2: Y hay una biblioteca javascript (¿o era incluso un plugin jquery?) Que hace este tipo de cosas además de algunas conversiones ingeniosas como "hace una hora", "la semana pasada" ... algo así. Pero se me olvidó el nombre :(

Fuente

2010-02-23 16:00:21 VolkerK

1

Creo que sin conocer la zona horaria exacta, siempre habrá una posibilidad de que se pierda en alguna regla oscura.
Al igual que con la mayoría de los problemas de internacionalización, hay reglas tienden más oscuros de los esperados .0 Sin embargo, iría por la opción A: "elegir una zona horaria probable con el desplazamiento correcto", precisamente porque las cosas de la zona horaria suelen ser más complicadas de lo que cabría esperar, especialmente cuando se tienen en cuenta los cambios en el horario de verano. para la opción A, puede usar las funciones estándar proporcionadas por PHP.

Puede combinar esto con otras métricas para mejorar su calidad de predicción; por ejemplo:

  • Según las estadísticas de los visitantes: seleccione la zona horaria de donde provienen la mayoría de los visitantes;
  • Basado en accept_headers: haga coincidir el idioma con una zona horaria;
  • basado en la geolocalización IP: coincide con el país en la zona horaria correcta.

La combinación de lo anterior debería dar una estimación bastante razonable. Pero el 100% de certeza no se puede lograr.

Fuente

2010-02-23 16:02:22 Jacco

Cuestiones relacionadas

 Cuestiones relacionadas