A partir du manuel ( section 9.6 ):
Les valeurs actuelles des fuseaux horaires globaux et spécifiques au client peuvent être récupérées comme suit :
mysql> SELECT @@global.time_zone, @@session.time_zone;
Modifier Les résultats ci-dessus SYSTEM
si MySQL est configuré pour utiliser le fuseau horaire du système, ce qui est loin d'être utile. Puisque vous utilisez PHP, si la réponse de MySQL est SYSTEM
vous pouvez alors demander au système quel fuseau horaire c'est par l'intermédiaire de date_default_timezone_get
. (Bien sûr, comme VolkerK l'a souligné, PHP peut être exécuté sur un autre serveur, mais en supposant que le serveur web et le serveur de base de données auxquels il communique sont des serveurs de type "web", il est possible de faire des suppositions. réglé sur [si ce n'est pas le cas sur Le fait d'être dans le même fuseau horaire n'est pas é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 rapporter une valeur différente de celle utilisée par le système d'exploitation. Si vous contrôlez le code PHP, vous devriez savoir si vous faites cela et vous en sortir.
Mais la question du fuseau horaire utilisé par le serveur MySQL peut être une tangente, car demander au serveur quel est le fuseau horaire dans lequel il se trouve vous permet d'obtenir les informations suivantes absolument rien sur les données de la base de données. Lisez la suite pour en savoir plus :
Poursuite de la discussion :
Si vous avez le contrôle du serveur, vous pouvez bien sûr vous assurer que le fuseau horaire est connu. Si vous n'avez pas le contrôle du serveur, vous pouvez définir le fuseau horaire utilisé par votre serveur. connexion comme ça :
set time_zone = '+00:00';
Cela définit le fuseau horaire à GMT, de sorte que toutes les autres opérations (telles que now()
) utilisera l'heure GMT.
Notez cependant que les valeurs d'heure et de date sont no stocké avec des informations sur le 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)
La connaissance du fuseau horaire du serveur n'est donc importante que pour les 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 de la base de données. Vous pouvez choisir de supposez ils ont été écrits en utilisant le fuseau horaire du serveur, mais cette hypothèse peut ê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 sur le fuseau horaire ou (comme je le fais) vous assurer qu'elles sont toujours en GMT.
Pourquoi l'hypothèse que les données ont été écrites en utilisant le fuseau horaire du serveur est-elle erronée ? Eh bien, d'une part, les données peuvent avoir été écrites en utilisant une connexion qui définit un fuseau horaire différent. La base de données peut avoir été déplacée d'un serveur à un autre, où les serveurs se trouvaient dans des fuseaux horaires différents (j'ai rencontré ce problème lorsque j'ai hérité d'une base de données qui avait été déplacée du Texas à 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é supprimée le 1er novembre à 2 heures du matin. Supposons que mon serveur se trouve en Californie et utilise 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 du matin le 1er novembre PDT, ou 1 h 30 du matin 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 tient pas compte de l'heure d'été) et convertissez-les dans le fuseau horaire souhaité lorsque cela est nécessaire.
4 votes
"Nous pouvons faire intervenir PHP ici" - et cette instance de php serait-elle toujours sur la même machine que le serveur MySQL ?
0 votes
Oui, ils seront sur la même machine.
17 votes
Essayez
@@system_time_zone
comme indiqué dans ma réponse ci-dessous.0 votes
Depuis que la question a été posée, d'autres réponses ont été ajoutées, peut-être faudrait-il reconsidérer la réponse acceptée ?
2 votes
Même si le serveur MySQL et PHP sont sur le même serveur, ils peuvent capter des fuseaux horaires différents en fonction de leurs paramètres. Et ces heures peuvent être différentes de celles affichées par votre système d'exploitation et par PHP/MySQL.
0 votes
Il affiche des informations valides, il vous indique que le fuseau horaire de mysql est le même que celui de votre système.
0 votes
Chez stackoverflow.com/questions/930900 est expliqué comment remplacer le SYSTÈME dans le fichier de configuration
my.cnf
. Sous l'article[mysqld]
ajouterdefault-time-zone='Pacific/Chatham'
.