Dans le manuel ( section 9.6 ):
Les valeurs actuelles des fuseaux horaires globaux et spécifiques au client peuvent être récupérées comme ceci:
mysql> SELECT @@global.time_zone, @@session.time_zone;
Modifier Ce qui précède revient SYSTEMsi MySQL est réglé sur esclave du fuseau horaire du système, ce qui est moins qu'utile. Puisque vous utilisez PHP, si la réponse de MySQL est SYSTEM, vous pouvez alors demander au système par quel fuseau horaire il utilise date_default_timezone_get. (Bien sûr, comme l'a souligné VolkerK, PHP peut s'exécuter sur un serveur différent, mais selon les hypothèses, en supposant que le serveur Web et le serveur de base de données avec lesquels il parle sont définis sur [sinon en fait dans ] le même fuseau horaire n'est pas un énorme saut.) Mais attention (comme avec MySQL), vous pouvez définir le fuseau horaire que PHP utilise (date_default_timezone_set), ce qui signifie qu'il peut signaler une valeur différente de celle utilisée par le système d'exploitation. Si vous contrôlez le code PHP, vous devez savoir si vous le faites et être d'accord.
Mais toute la question du fuseau horaire utilisé par le serveur MySQL peut être tangente, car demander au serveur dans quel fuseau horaire il ne vous dit absolument rien sur les données de la base de données. Lisez la suite pour plus de détails:
Discussion supplémentaire :
Si vous contrôlez le serveur, vous pouvez bien sûr vous assurer que le fuseau horaire est une quantité connue. Si vous ne contrôlez pas le serveur, vous pouvez définir le fuseau horaire utilisé par votre connexion comme ceci:
set time_zone = '+00:00';
Cela définit le fuseau horaire sur GMT, de sorte que toute autre opération (comme now()) utilise GMT.
Notez cependant que les valeurs d'heure et de date ne sont pas stockées avec les informations de fuseau horaire dans 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)
Donc , sachant le fuseau horaire du serveur est seulement important en termes de fonctions qui obtiennent le temps en ce moment, comme now(), unix_timestamp(), etc .; il ne vous dit rien sur le fuseau horaire utilisé par les dates dans les données de la base de données. Vous pouvez choisir de supposer qu'elles ont été écrites à l'aide du fuseau horaire du serveur, mais cette hypothèse pourrait bien être erronée. Pour connaître le fuseau horaire de toutes les dates ou heures stockées dans les données, vous devez vous assurer qu'elles sont stockées avec des informations de fuseau horaire ou (comme je le fais) qu'elles sont toujours en GMT.
Pourquoi l'hypothèse selon laquelle les données ont été écrites à l'aide du fuseau horaire du serveur est-elle défectueuse? Eh bien, d'une part, les données peuvent avoir été écrites à l'aide d'une connexion qui définit un fuseau horaire différent. La base de données a peut-être été déplacée d'un serveur à un autre, où les serveurs se trouvaient dans des fuseaux horaires différents (je suis tombé dessus lorsque j'ai hérité d'une base de données qui était passée du Texas à la Californie). Mais même si les données sont écrites sur le serveur, avec son fuseau horaire actuel, elles restent ambiguës. L'année dernière, aux États-Unis, l'heure d'été a été désactivée à 2h00 du matin le 1er novembre. Supposons que mon serveur se trouve en Californie en utilisant le fuseau horaire du Pacifique et que j'ai la valeur2009-11-01 01:30:00dans la base de données. Quand était-ce? Était-ce à 1 h 30 le 1er novembre HAP ou à 1 h 30 le 1er novembre HNP (une heure plus tard)? Vous n'avez absolument aucun moyen de le savoir. Moralité: stockez toujours les dates / heures au format GMT (qui ne fait pas l'heure d'été) et convertissez-les au fuseau horaire souhaité si / lorsque nécessaire.