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

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

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

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

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

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

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

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

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

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而言，客戶端的時區(qū)信息可以這樣獲取：

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

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

對于純js：

new Date().getTimezoneOffset()/60;

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

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

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