Cómo almacenar una fecha y hora en MySQL con información de zona horaria

Esta es la contestación más acertada que encomtrarás aportar, sin embargo mírala pausadamente y valora si se adapta a tu trabajo.

Solución:

Tu dijiste:

Quiero que siempre aparezcan en la hora de Tanzania y no en las horas locales en las que se encuentran varios colaboradores.

Si este es el caso, entonces usted debe no usar UTC. Todo lo que necesita hacer es usar un DATETIME escriba en MySQL en lugar de un TIMESTAMP escribe.

De la documentación de MySQL:

MySQL convierte TIMESTAMP valores de la zona horaria actual a UTC para el almacenamiento, y de vuelta de UTC a la zona horaria actual para la recuperación. (Esto no ocurre con otros tipos como DATETIME.)

Si usted es ya usando un DATETIME escriba, entonces no debe configurarlo en la hora local para empezar. Deberá concentrarse menos en la base de datos y más en el código de su aplicación, que no mostró aquí. El problema y la solución variarán drásticamente según el idioma, así que asegúrese de etiquetar la pregunta con el idioma apropiado del código de su aplicación.

Ninguna de las respuestas aquí dio en el clavo.

Cómo almacenar una fecha y hora en MySQL con información de zona horaria

Usa dos columnas: DATETIMEy un VARCHAR para contener la información de la zona horaria, que puede estar en varias formas:

A zona horaria o ubicación tal como America/New_York es la más alta fidelidad de datos.

A abreviatura de zona horaria tal como PST es la siguiente fidelidad más alta.

A desplazamiento de tiempo tal como -2:00 es la menor cantidad de datos al respecto.

Algunos key puntos:

• Evitar TIMESTAMP porque está limitado al año 2038, y MySQL lo relaciona con la zona horaria del servidor, lo que probablemente no sea deseado.
• Un desplazamiento de tiempo no debe almacenarse ingenuamente en un INT campo, porque hay compensaciones de media hora y cuarto de hora.

---

Si es importante para su caso de uso tener MySQL comparar o clasificar estas fechas cronológicamente, DATETIME tiene un problema:

'2009-11-10 11:00:00 -0500' es antes '2009-11-10 10:00:00 -0700' en términos de “instante en el tiempo”, pero se clasificarían de otra manera cuando se insertaran en un DATETIME.

Puedes hacer tu propia conversión a UTC. En el ejemplo anterior, entonces tendría
'2009-11-10 16:00:00' y '2009-11-10 17:00:00' respectivamente, que ordenarían correctamente. Al recuperar los datos, usaría la información de la zona horaria para revertirlos a su forma original.

Una recomendación que me gusta bastante es tener Tres columnas:

• local_time DATETIME
• utc_time DATETIME
• time_zone VARCHAR(X) donde X es apropiado para el tipo de datos que está almacenando allí. (Yo elegiría 64 caracteres para la zona horaria/ubicación).

Una ventaja del enfoque de 3 columnas es que es explícito: con una sola DATETIME columna, no puede saber de un vistazo si se ha convertido a UTC antes de la inserción.

---

Con respecto al descenso de precisión a través de la zona horaria/abreviatura/offset:

• Si tiene la zona horaria/ubicación del usuario, como America/Juneau, puede saber con precisión cuál es la hora del reloj de pared para ellos en cualquier momento en el pasado o en el futuro (salvo cambios en la forma en que se maneja el horario de verano en esa ubicación). Los puntos de inicio/finalización del horario de verano, y si se usa o no, dependen de la ubicación, por lo que esta es la única forma confiable.
• Si tiene una abreviatura de zona horaria como MST, (hora estándar de la montaña) o una diferencia simple como -0700, no podrá predecir la hora de un reloj de pared en el pasado o en el futuro. Por ejemplo, en los Estados Unidos, Colorado y Arizona usan MST, pero Arizona no observa DST. Entonces, si el usuario sube la foto de su gato en 14:00 -0700 durante los meses de invierno, ¿estaba en Arizona o en California? Si sumaste seis meses exactamente a esa fecha, ¿sería 14:00 o 13:00 para el usuario?

Es importante tener en cuenta estas cosas cuando su aplicación tiene tiempo, fechas o programación como función principal.

---

Referencias:

• Referencia de fecha/hora de MySQL
• La forma correcta de manejar múltiples zonas horarias en MySQL
  ^{(Divulgación: no leí todo este artículo).}

Todos los síntomas que describe sugieren que nunca le diga a MySQL qué zona horaria usar, por lo que se establece de manera predeterminada en la zona del sistema. Piénsalo: si todo lo que tiene es '2011-03-13 02:49:10'¿cómo puede adivinar que es una fecha local de Tanzania?

Hasta donde yo sé, MySQL no proporciona ninguna sintaxis para especificar la información de la zona horaria en las fechas. Tienes que cambiarlo por conexión; algo como:

SET time_zone = 'EAT';

Si esto no funciona (para usar zonas con nombre, necesita que el servidor haya sido configurado para hacerlo y, a menudo, no es el caso), puede usar las compensaciones UTC porque Tanzania no observa el horario de verano en el momento de la escritura, pero por supuesto no es la mejor opción:

SET time_zone = '+03:00';

Aquí puedes ver las reseñas y valoraciones de los lectores

Más adelante puedes encontrar las aclaraciones de otros usuarios, tú asimismo tienes la libertad de insertar el tuyo si lo deseas.

---

---

Utiliza Nuestro Buscador