Från manualen (avsnitt 9.6 ):
De aktuella värdena för de globala och klientspecifika tidszonerna kan hämtas så här:
mysql> SELECT @@global.time_zone, @@session.time_zone;
Redigera Ovanstående returnerar SYSTEM om MySQL är inställt på att använda systemets tidszon, vilket är mindre användbart. Eftersom du använder PHP, om svaret från MySQL är SYSTEM , kan du sedan fråga systemet vilken tidszon det är använder via date_default_timezone_get
. (Naturligtvis, som VolkerK påpekade, kan PHP köras på en annan server, men som antaganden går, förutsatt att webbservern och DB-servern den pratar med är inställd på [om inte faktiskt i ] samma tidszon är inte en stor språng.) Men se upp att (som med MySQL) kan du ställa in tidszonen som PHP använder (date_default_timezone_set
), vilket innebär att det kan rapportera ett annat värde än vad operativsystemet använder. Om du har kontroll över PHP-koden bör du veta om du gör det och vara okej.
Men hela frågan om vilken tidszon MySQL-servern använder kan vara en tangent, för att fråga servern vilken tidszon den är i säger dig absolut ingenting om uppgifterna i databasen. Läs vidare för detaljer:
Ytterligare diskussion :
Om du har kontroll över servern kan du naturligtvis se till att tidszonen är en känd kvantitet. Om du inte har kontroll över servern kan du ställa in tidszonen som används av din anslutning så här:
set time_zone = '+00:00';
Det ställer in tidszonen till GMT, så att eventuella ytterligare operationer (som now() ) kommer att använda GMT.
Observera dock att tids- och datumvärden inte är lagras med tidszonsinformation i 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)
Så att veta serverns tidszon är bara viktigt när det gäller funktioner som får tiden just nu, såsom now() , unix_timestamp() , etc.; det säger ingenting om vilken tidszon datumen i databasdata använder. Du kan välja att anta de skrevs med hjälp av serverns tidszon, men det antagandet kan mycket väl vara felaktigt. För att veta tidszonen för alla datum eller tider som lagras i data måste du se till att de lagras med tidszonsinformation eller (som jag gör) se till att de alltid är i GMT.
Varför är det felaktigt att anta att data skrevs med hjälp av serverns tidszon? Tja, för det första kan data ha skrivits med hjälp av en anslutning som ställde in en annan tidszon. Databasen kan ha flyttats från en server till en annan, där servrarna var i olika tidszoner (jag stötte på det när jag ärvde en databas som hade flyttat från Texas till Kalifornien). Men även om data skrivs på servern, med dess aktuella tidszon är den fortfarande tvetydig. Förra året, i USA, stängdes sommartid av klockan 02:00 den 1 november. Anta att min server är i Kalifornien och använder Pacific-tidszonen och att jag har värdet 2009-11-01 01:30:00 i databasen. När var det? Var det 01:30 den 1 november PDT eller 01:30 den 1 november PST (en timme senare)? Du har absolut inget sätt att veta. Moral:Lagra alltid datum/tider i GMT (som inte gör sommartid) och konvertera till önskad tidszon vid behov.