MySQL UTC_TIMESTAMP() ignorer le paramètre @@ time_zone

Question

J'ai deux serveurs Linux/MySQL au Royaume-Uni, le fuseau horaire actuel sur les deux rapports BST (GMT + 1) et pourtant j'ai trouvé une différence dans la sortie de MySQL.

La requête suivante:

SELECT version(), @@time_zone, @@system_time_zone, NOW(), UTC_TIMESTAMP() 

retours:

Server A: 5.0.27-community-nt | SYSTEM | GMT | 2010-10-12 12:17:01 | 2010-10-12 11:17:01 
Server B: 5.0.45-log | SYSTEM | GMT Daylight Time | 2010-10-12 12:17:51 | 2010-10-12 11:17:51 

Ainsi, le serveur A rapports, il est réglé sur GMT. Le processus de serveur a été démarré le 1er mars lorsque GMT était en vigueur, donc je m'y attendais. Toutefois, UTC_TIMESTAMP() a correctement (mais de façon inattendue) signalé UTC étant 1 heure avant localtime. Sur le serveur B, le processus MySQL a été démarré pendant l'été, il signale donc correctement GMT Daylight Time et signale à nouveau correctement UTC une heure plus tôt.

Ma question est, comment le serveur A a-t-il obtenu la "bonne" réponse? Et, sera-t-il toujours exact le 31 octobre lorsque l'heure locale reviendra à GMT + 0?

Answer 1

Je pense que ce qui se passe est que lorsque vous démarrez le serveur MySQL, il remplit la variable @@system_time_zone, mais même quand il change (par exemple en raison de DST), il n'est pas reflété dans la variable. Cependant, bien que le @@system_time_zone indique "GMT", quand le serveur MySQL évalue la date actuelle, et @@time_zone est le système, il demande au système la date et l'heure d'été affecte cela, peu importe ce que dit la variable system_time_zone. Donc, le seul "problème" ici est que la variable system_timezone ne change pas automatiquement, même si le fuseau horaire du système change.