問(wèn)題描述
有誰(shuí)知道MySQL中是否有這樣的功能?
Anyone knows if there is such a function in MySQL?
更新
這不會(huì)輸出任何有效信息:
This doesn't output any valid info:
mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM | SYSTEM |
+--------------------+---------------------+
或者M(jìn)ySQL本身不能準(zhǔn)確知道使用的time_zone
,沒(méi)關(guān)系,我們可以在此處涉及PHP
,只要我能得到有效信息而不是<代碼>系統(tǒng)代碼>...
Or maybe MySQL itself can't know exactly the time_zone
used,that's fine, we can involve PHP
here, as long as I can get valid info not like SYSTEM
...
推薦答案
來(lái)自手冊(cè) (第 9.6 節(jié)):
全局和客戶(hù)端特定時(shí)區(qū)的當(dāng)前值可以這樣檢索:
<代碼>mysql>選擇@@global.time_zone,@@session.time_zone;
The current values of the global and client-specific time zones can be retrieved like this:
mysql> SELECT @@global.time_zone, @@session.time_zone;
Edit 如果 MySQL 設(shè)置為使用系統(tǒng)的時(shí)區(qū),則上面返回 SYSTEM
,這沒(méi)有幫助.由于您使用的是 PHP,如果 MySQL 的答案是 SYSTEM
,那么您可以通過(guò) 詢(xún)問(wèn)系統(tǒng) 它是 使用的時(shí)區(qū).net/manual/en/function.date-default-timezone-get.php" rel="noreferrer">date_default_timezone_get
.(當(dāng)然,正如 VolkerK 指出的那樣,PHP 可能運(yùn)行在不同的服務(wù)器上,但根據(jù)假設(shè),假設(shè) Web 服務(wù)器和它與之通信的數(shù)據(jù)庫(kù)服務(wù)器 設(shè)置為 [如果實(shí)際上不是 >in] 相同的時(shí)區(qū)并不是一個(gè)巨大的飛躍.)但要注意(與 MySQL 一樣),您可以設(shè)置 PHP 使用的時(shí)區(qū)(date_default_timezone_set
),這意味著它可能會(huì)報(bào)告一個(gè)與操作系統(tǒng)使用的值不同.如果您可以控制 PHP 代碼,您應(yīng)該知道自己是否在這樣做并且沒(méi)問(wèn)題.
Edit The above returns SYSTEM
if MySQL is set to use the system's timezone, which is less than helpful. Since you're using PHP, if the answer from MySQL is SYSTEM
, you can then ask the system what timezone it's using via date_default_timezone_get
. (Of course, as VolkerK pointed out, PHP may be running on a different server, but as assumptions go, assuming the web server and the DB server it's talking to are set to [if not actually in] the same timezone isn't a huge leap.) But beware that (as with MySQL), you can set the timezone that PHP uses (date_default_timezone_set
), which means it may report a different value than the OS is using. If you're in control of the PHP code, you should know whether you're doing that and be okay.
但是關(guān)于 MySQL 服務(wù)器使用哪個(gè)時(shí)區(qū)的整個(gè)問(wèn)題可能是一個(gè)切線,因?yàn)樵?xún)問(wèn)服務(wù)器它所在的時(shí)區(qū)告訴您完全沒(méi)有關(guān)于數(shù)據(jù)庫(kù)中的數(shù)據(jù).繼續(xù)閱讀以了解詳情:
But the whole question of what timezone the MySQL server is using may be a tangent, because asking the server what timezone it's in tells you absolutely nothing about the data in the database. Read on for details:
進(jìn)一步討論:
如果您在控制服務(wù)器,當(dāng)然可以確保時(shí)區(qū)是已知數(shù)量.如果您無(wú)法控制服務(wù)器,您可以像這樣設(shè)置連接使用的時(shí)區(qū):
If you're in control of the server, of course you can ensure that the timezone is a known quantity. If you're not in control of the server, you can set the timezone used by your connection like this:
set time_zone = '+00:00';
將時(shí)區(qū)設(shè)置為 GMT,以便任何進(jìn)一步的操作(如 now()
)都將使用 GMT.
That sets the timezone to GMT, so that any further operations (like now()
) will use GMT.
但是請(qǐng)注意,時(shí)間和日期值不與 MySQL 中的時(shí)區(qū)信息一起存儲(chǔ):
Note, though, that time and date values are not stored with timezone information in 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)
所以知道服務(wù)器的時(shí)區(qū)只對(duì)獲取當(dāng)前時(shí)間的函數(shù)很重要,例如now()
、unix_timestamp()
等.;它不會(huì)告訴您有關(guān)數(shù)據(jù)庫(kù)數(shù)據(jù)中日期使用的時(shí)區(qū)的任何信息.您可以選擇假設(shè)它們是使用服務(wù)器的時(shí)區(qū)編寫(xiě)的,但這種假設(shè)很可能是有缺陷的.要了解存儲(chǔ)在數(shù)據(jù)中的任何日期或時(shí)間的時(shí)區(qū),您必須確保它們與時(shí)區(qū)信息一起存儲(chǔ),或者(像我一樣)確保它們始終采用 GMT.
So knowing the timezone of the server is only important in terms of functions that get the time right now, such as now()
, unix_timestamp()
, etc.; it doesn't tell you anything about what timezone the dates in the database data are using. You might choose to assume they were written using the server's timezone, but that assumption may well be flawed. To know the timezone of any dates or times stored in the data, you have to ensure that they're stored with timezone information or (as I do) ensure they're always in GMT.
為什么假設(shè)數(shù)據(jù)是使用服務(wù)器的時(shí)區(qū)寫(xiě)入的?嗯,一方面,數(shù)據(jù)可能是使用設(shè)置不同時(shí)區(qū)的連接寫(xiě)入的.數(shù)據(jù)庫(kù)可能已從一臺(tái)服務(wù)器移動(dòng)到另一臺(tái)服務(wù)器,其中服務(wù)器位于不同的時(shí)區(qū)(當(dāng)我繼承從德克薩斯州移動(dòng)到加利福尼亞州的數(shù)據(jù)庫(kù)時(shí)遇到了這種情況).但是即使數(shù)據(jù)寫(xiě)在服務(wù)器上,用它的當(dāng)前時(shí)區(qū),它仍然是不明確的.去年,在美國(guó),夏令時(shí)在 11 月 1 日凌晨 2:00 關(guān)閉.假設(shè)我的服務(wù)器位于加利福尼亞,使用太平洋時(shí)區(qū),并且我在數(shù)據(jù)庫(kù)中有 2009-11-01 01:30:00
值.那是什么時(shí)候?那是太平洋標(biāo)準(zhǔn)時(shí)間 11 月 1 日凌晨 1 點(diǎn) 30 分,還是太平洋標(biāo)準(zhǔn)時(shí)間 11 月 1 日凌晨 1 點(diǎn) 30 分(一小時(shí)后)?你完全沒(méi)有辦法知道.道德:始終以格林威治標(biāo)準(zhǔn)時(shí)間(不執(zhí)行夏令時(shí))存儲(chǔ)日期/時(shí)間,并在必要時(shí)轉(zhuǎn)換為所需的時(shí)區(qū).
Why is assuming the data was written using the server's timezone flawed? Well, for one thing, the data may have been written using a connection that set a different timezone. The database may have been moved from one server to another, where the servers were in different timezones (I ran into that when I inherited a database that had moved from Texas to California). But even if the data is written on the server, with its current time zone, it's still ambiguous. Last year, in the United States, Daylight Savings Time was turned off at 2:00 a.m. on November 1st. Suppose my server is in California using the Pacific timezone and I have the value 2009-11-01 01:30:00
in the database. When was it? Was that 1:30 a.m. November 1st PDT, or 1:30 a.m. November 1st PST (an hour later)? You have absolutely no way of knowing. Moral: Always store dates/times in GMT (which doesn't do DST) and convert to the desired timezone as/when necessary.
這篇關(guān)于如何獲取 MySQL 的當(dāng)前時(shí)區(qū)?的文章就介紹到這了,希望我們推薦的答案對(duì)大家有所幫助,也希望大家多多支持html5模板網(wǎng)!