Du 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 renvoie SYSTEM si MySQL est configuré pour utiliser le 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 ensuite demander au système de quel fuseau horaire il s'agit en utilisant via date_default_timezone_get
. (Bien sûr, comme l'a souligné VolkerK, PHP peut être exécuté sur un serveur différent, mais selon les hypothèses, en supposant que le serveur Web et le serveur de base de données auquel il parle sont définis sur [si ce n'est pas réellement dans ] le même fuseau horaire n'est pas un énorme saut.) Mais attention (comme avec MySQL), vous pouvez définir le fuseau horaire utilisé par PHP (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 que tout va bien.
Mais toute la question de savoir quel fuseau horaire le serveur MySQL utilise peut être une tangente, car demander au serveur dans quel fuseau horaire il se trouve ne vous dit absolument rien sur les données de la base de données. Lisez la suite pour plus de détails :
Poursuite de la discussion :
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() ) utilisera GMT.
Notez, cependant, que les valeurs d'heure et de date ne sont pas stocké 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, connaître le fuseau horaire du serveur n'est important qu'en termes de fonctions qui obtiennent l'heure actuelle, telles que 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 ils ont été écrits en utilisant le 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) vous assurer qu'elles sont toujours en GMT.
Pourquoi supposer que les données ont été écrites en utilisant le fuseau horaire du serveur est erroné ? 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 (j'ai rencontré cela lorsque j'ai hérité d'une base de données qui avait été déplacée du Texas vers la Californie). Mais même si les données sont écrites sur le serveur, avec son fuseau horaire actuel, c'est toujours ambigu. L'année dernière, aux États-Unis, l'heure d'été a été désactivée à 2 heures 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 valeur 2009-11-01 01:30:00 dans la base de données. Quand était-ce? Était-ce 1 h 30 le 1er novembre PDT ou 1 h 30 le 1er novembre PST (une heure plus tard) ? Vous n'avez absolument aucun moyen de le savoir. Moralité :stockez toujours les dates/heures en GMT (qui ne fait pas l'heure d'été) et convertissez-les dans le fuseau horaire souhaité si nécessaire.
