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

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

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

服務器端是以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而言，客戶端的時區信息可以這樣獲?。?/p>

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

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

對于純js：

new Date().getTimezoneOffset()/60;

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

原文地址：mysql按天分組支持時區, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com