Z podręcznika (punkt 9.6 ):
Bieżące wartości stref czasowych globalnych i specyficznych dla klienta można pobrać w następujący sposób:mysql> SELECT @@global.time_zone, @@session.time_zone;
Edytuj Powyższe zwraca SYSTEM jeśli MySQL jest ustawiony na używanie strefy czasowej systemu, co jest mniej niż pomocne. Ponieważ używasz PHP, jeśli odpowiedź MySQL to SYSTEM , możesz następnie zapytać system, jaka jest strefa czasowa za pomocą date_default_timezone_get
. (Oczywiście, jak zauważył VolkerK, PHP może działać na innym serwerze, ale zgodnie z założeniami, zakładając, że serwer WWW i serwer DB, z którym się komunikuje, są ustawione na [jeśli nie faktycznie w ] ta sama strefa czasowa nie jest wielka skok.) Ale uważaj, że (tak jak w przypadku MySQL), możesz ustawić strefę czasową używaną przez PHP (date_default_timezone_set
), co oznacza, że może zgłosić inną wartość niż system operacyjny. Jeśli masz kontrolę nad kodem PHP, powinieneś wiedzieć, czy to robisz i być w porządku.
Ale całe pytanie o strefę czasową używaną przez serwer MySQL może być styczne, ponieważ pytanie serwera, w jakiej strefie czasowej się znajduje, absolutnie nic nie mówi o danych w bazie danych. Czytaj dalej, aby uzyskać szczegółowe informacje:
Dalsza dyskusja :
Jeśli kontrolujesz serwer, oczywiście możesz upewnić się, że strefa czasowa jest znana. Jeśli nie masz kontroli nad serwerem, możesz ustawić strefę czasową używaną przez Twoje połączenie tak:
set time_zone = '+00:00';
To ustawia strefę czasową na GMT, więc wszelkie dalsze operacje (takie jak now() ) użyje GMT.
Pamiętaj jednak, że wartości czasu i daty nie przechowywane z informacjami o strefie czasowej w 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)
Tak więc znajomość strefy czasowej serwera jest ważna tylko w przypadku funkcji, które pobierają czas w tej chwili, takich jak now() , unix_timestamp() itp.; nie mówi nic o strefie czasowej, której używają daty w danych bazy danych. Możesz założyć zostały napisane przy użyciu strefy czasowej serwera, ale to założenie może być błędne. Aby poznać strefę czasową dowolnych dat lub godzin przechowywanych w danych, musisz upewnić się, że są one przechowywane z informacjami o strefie czasowej lub (tak jak ja) upewnić się, że są one zawsze w GMT.
Dlaczego założenie, że dane zostały zapisane przy użyciu strefy czasowej serwera, jest wadliwe? Cóż, po pierwsze, dane mogły zostać zapisane przy użyciu połączenia, które ustawia inną strefę czasową. Baza danych mogła zostać przeniesiona z jednego serwera na drugi, gdzie serwery znajdowały się w różnych strefach czasowych (wpadłem na to, gdy odziedziczyłem bazę danych, która została przeniesiona z Teksasu do Kalifornii). Ale nawet jeśli dane są zapisywane na serwerze, z aktualną strefą czasową, nadal są niejednoznaczne. W zeszłym roku w Stanach Zjednoczonych czas letni został wyłączony 1 listopada o godzinie 2:00. Załóżmy, że mój serwer znajduje się w Kalifornii i używa strefy czasowej Pacyfiku i mam wartość 2009-11-01 01:30:00 w bazie danych. Kiedy to było? Czy to była godzina 1:30 pierwszego listopada PDT, czy 1:30 pierwszego listopada PST (godzinę później)? Absolutnie nie masz możliwości dowiedzenia się. Morał:Zawsze przechowuj daty/godziny w GMT (co nie obejmuje czasu letniego) i konwertuj na żądaną strefę czasową w razie potrzeby.
