時區問題總是個比較麻煩的問題，客戶端與服務器的時區不一致自然是理所當然的事情，而對于多臺服務器或者分布式再或者炙手可熱的云，時區不統一也很正常，而且也不需要統一，還好有個時間戳的概念，通過時間戳就可以保證交互的過程中始終討論的是同一個時間

時區問題總是個比較麻煩的問題，客戶端與服務器的時區不一致自然是理所當然的事情，而對于多臺服務器或者分布式再或者炙手可熱的云，時區不統一也很正常，而且也不需要統一，還好有個時間戳的概念，通過時間戳就可以保證交互的過程中始終討論的是同一個時間。

但是有些時候時間戳并不能滿足要求，比如對于一個按天統計的報表，日期范圍的選擇來自于客戶端，通過時間戳我們可以保證服務端返回的數據是屬于客戶端選擇的日期范圍中的，但是按天做統計就出現問題了。

服務器端是以mysql作為數據庫，其中一張表名為session，其中記錄時間戳的字段為ts，在做按日期分組查詢時，主要的依據就是ts。

通過很簡單的分組GROUP BY date(from_unixtime(ts))就可以統計到每天的記錄數。

而這里from_unixtime得到的日期對象是以格林尼治時間為準的，也就是時區為+00:00

例如客戶端需要展現2011年1月1日零時至2011年1月10日零時(不包含)的按天統計報表，客戶端時區為+08:00，服務器處理此請求時，查詢的結果可能會多出2011-01-10這個分組，原因是此時的分組時區不是客戶端所期望的。

mysql提供了時區轉換的函數CONVERT_TZ，通過它將from_unixtime得到的日期轉換為客戶端指定的時區就可以解決上面的問題了。

下面通過對比可以看出，統計出的結果是有很大區別的，而后者才是正確的。

SELECT from_unixtime(ts), count(*) AS num FROM session GROUP BY date(from_unixtime(ts))

2011-11-25 06:01:35 2011-11-25 14:01:35 105

2011-11-26 01:42:27 2011-11-26 09:42:27 28

2011-11-27 00:12:32 2011-11-27 08:12:32 39

2011-11-28 00:43:40 2011-11-28 08:43:40 70

SELECT from_unixtime(ts), count(*) AS num FROM session GROUP BY date(CONVERT_TZ(from_unixtime(ts),’+00:00′,’+08:00′))

2011-11-25 06:01:35 2011-11-25 14:01:35 95

2011-11-25 16:54:23 2011-11-26 00:54:23 22

2011-11-26 16:26:29 2011-11-27 00:26:29 33

2011-11-27 16:50:08 2011-11-28 00:50:08 92

對于extjs而言，客戶端的時區信息可以這樣獲取：

Ext.Date.getGMTOffset(new Date());

返回’+0800′，使用時需要處理一下。

對于純js：

new Date().getTimezoneOffset()/60;

返回-8，為什么呢？有空去查一下看看。

總結

以上是生活随笔為你收集整理的mysql支持的时区列表_mysql按天分组支持时区的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。