Del manual ( sección 9.6 ):
Los valores actuales de las zonas horarias globales y específicas del cliente pueden recuperarse así:
mysql> SELECT @@global.time_zone, @@session.time_zone;
Editar Lo anterior se devuelve SYSTEMsi MySQL está configurado como esclavo de la zona horaria del sistema, lo que no es útil. Como está utilizando PHP, si la respuesta de MySQL es SYSTEM, puede preguntarle al sistema qué zona horaria está utilizando a través de date_default_timezone_get. (Por supuesto, como señaló VolkerK, PHP puede estar ejecutándose en un servidor diferente, pero según los supuestos, suponiendo que el servidor web y el servidor DB con el que está hablando están configurados en [si no está realmente en ] la misma zona horaria no es un gran salto.) Pero cuidado (como con MySQL), puedes configurar la zona horaria que usa PHP (date_default_timezone_set), lo que significa que puede informar un valor diferente al que usa el sistema operativo. Si tienes el control del código PHP, debes saber si lo estás haciendo y estar bien.
Pero toda la cuestión de qué zona horaria está usando el servidor MySQL puede ser tangente, porque preguntarle al servidor en qué zona horaria se encuentra le dice absolutamente nada sobre los datos en la base de datos. Siga leyendo para más detalles:
Discusión adicional :
Si tiene el control del servidor, por supuesto, puede asegurarse de que la zona horaria sea una cantidad conocida. Si no tiene el control del servidor, puede configurar la zona horaria utilizada por su conexión de esta manera:
set time_zone = '+00:00';
Eso establece la zona horaria en GMT, de modo que cualquier otra operación (como now()) usará GMT.
Sin embargo, tenga en cuenta que los valores de hora y fecha no se almacenan con información de zona horaria en MySQL:
mysql> create table foo (tstamp datetime) Engine=MyISAM;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into foo (tstamp) values (now());
Query OK, 1 row affected (0.00 sec)
mysql> set time_zone = '+01:00';
Query OK, 0 rows affected (0.00 sec)
mysql> select tstamp from foo;
+---------------------+
| tstamp |
+---------------------+
| 2010-05-29 08:31:59 |
+---------------------+
1 row in set (0.00 sec)
mysql> set time_zone = '+02:00';
Query OK, 0 rows affected (0.00 sec)
mysql> select tstamp from foo;
+---------------------+
| tstamp |
+---------------------+
| 2010-05-29 08:31:59 | <== Note, no change!
+---------------------+
1 row in set (0.00 sec)
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2010-05-29 10:32:32 |
+---------------------+
1 row in set (0.00 sec)
mysql> set time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec)
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2010-05-29 08:32:38 | <== Note, it changed!
+---------------------+
1 row in set (0.00 sec)
Por lo que conocer la zona horaria del servidor sólo es importante en términos de funciones que hacen que el tiempo en este momento, como por ejemplo now(), unix_timestamp(), etc .; no le dice nada sobre qué zona horaria están usando las fechas en los datos de la base de datos. Puede optar por suponer que se escribieron utilizando la zona horaria del servidor, pero esa suposición puede ser errónea. Para conocer la zona horaria de cualquier fecha u hora almacenada en los datos, debe asegurarse de que estén almacenados con información de la zona horaria o (como lo hago yo) asegurarse de que siempre estén en GMT.
¿Por qué se supone que los datos se escribieron usando la zona horaria del servidor defectuosa? Bueno, para empezar, los datos pueden haberse escrito utilizando una conexión que establece una zona horaria diferente. La base de datos puede haberse movido de un servidor a otro, donde los servidores estaban en diferentes zonas horarias (me encontré con eso cuando heredé una base de datos que se había mudado de Texas a California). Pero incluso si los datos se escriben en el servidor, con su zona horaria actual, siguen siendo ambiguos. El año pasado, en los Estados Unidos, el horario de verano se apagó a las 2:00 am del 1 de noviembre. Supongamos que mi servidor está en California usando la zona horaria del Pacífico y tengo el valor2009-11-01 01:30:00en la base de datos. ¿Cuando fue? ¿Era la 1:30 am del 1 de noviembre PDT o la 1:30 am del 1 de noviembre PST (una hora después)? No tienes absolutamente ninguna forma de saberlo. Moraleja: siempre almacene fechas / horas en GMT (que no hace DST) y convierta a la zona horaria deseada cuando sea necesario