Mysql
 sql >> Base de données >  >> RDS >> Mysql

Définir le fuseau horaire de la base de données MySQL sur GMT

Non, il n'est pas possible de modifier le fuseau horaire d'une seule base de données au sein d'une instance MySQL.

Nous pouvons récupérer le serveur et le client time_zone paramètres avec une requête, comme celle-ci :

SELECT @@global.time_zone, @@session.time_zone;

Nous pouvons également modifier le fuseau horaire du client pour une session ou modifier le fuseau horaire de l'ensemble de l'instance MySQL.

Mais nous devons être parfaitement conscients de l'implication que ce changement aura sur les connexions client existantes, et comment DATETIME et TIMESTAMP les valeurs déjà stockées dans l'instance seront interprétées.

Pour que le fuseau horaire du serveur soit défini au démarrage de l'instance MySQL, nous pouvons modifier le /etc/my.cnf fichier (ou partout où les paramètres d'initialisation de l'instance mysql sont lus), sous le [mysqld] rubrique :

[mysqld]
default-time-zone='+00:00' 

-- ou --

Il est également possible (moins souhaitable) d'ajouter le --default_time_zone='+00:00' option mysqld_safe

REMARQUE : La modification du paramètre de fuseau horaire sur le serveur MySQL ne modifie PAS les valeurs stockées dans les colonnes DATETIME ou TIMESTAMP existantes, MAIS puisqu'elle modifie effectivement le contexte dans lequel ces valeurs stockées sont interprétées, il semblera que toutes les valeurs SONT décalées. (Où 08h00 signifiait 8h00 CST, avec le fuseau horaire du serveur changé de CST à GMT, ce même "08h00" sera désormais considéré comme 8h00 GMT, ce qui serait effectivement 2h00 CST.

Gardez également à l'esprit que les colonnes TIMESTAMP sont toujours stockées en UTC, tandis que les colonnes DATETIME n'ont pas de fuseau horaire.http://dev.mysql.com/doc/refman/5.5/en/datetime.html

Chaque session client peut modifier le paramètre de fuseau horaire pour sa propre session :

SET time_zone='-06:00';

Mais rien de tout cela ne "résout" vraiment le problème de conversion du fuseau horaire, cela ne fait que déplacer le problème de conversion.

Il n'y a rien d'intrinsèquement "mauvais" avec la couche application qui gère les conversions de fuseau horaire ; parfois, c'est le meilleur endroit pour gérer. Cela doit juste être fait correctement et de manière cohérente.

(Ce qui est étrange dans la configuration que vous décrivez, c'est que l'application stocke les valeurs DATETIME comme si le fuseau horaire du serveur MySQL était défini sur GMT, mais que le fuseau horaire du serveur MySQL était défini sur autre chose.)