問題:資料查不出來,查詢資料少了 8 小時
從 InfluxDB查詢資料發現目前資料查不出來,分析發現少了 8 小時。 是以在查詢語句中減去了 8 小時,雖然資料可以查出來了,但是 group by 時,顯示的資料會多一天。
先了解一下時區有助于了解下面查詢結果, RFC3339詳細定義了網際網路上日期/時間的偏移量表示:
2017-12-08T00:00:00.00Z
這個代表了UTC時間的2017年12月08日零時:
2017-12-08T00:08:00.00+08:00
東八區的本地時間比零時區的本地時間快了8個小時。
在背景管理系統上輸入的是東八區時間。
查了一下代碼是這麼寫的’2019-10-18T00:00:00Z’,這樣比實際時間多了 8 小時。通常是把查詢條件減去8 小時就大吉大利了:
SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00Z' and time < '2019-10-23T00:00:00Z' group by time(1d)
name: user_day
time count
---- -----
2019-10-18T00:00:00Z 7522
2019-10-19T00:00:00Z 7355
2019-10-20T00:00:00Z 7740
2019-10-21T00:00:00Z 5997
2019-10-22T00:00:00Z 5430
減去 8 小時候後查詢的結果如下:
SELECT count(user_id_val) FROM user_day where time >= '2019-10-17T16:00:00Z' and time < '2019-10-22T16:00:00Z' group by time(1d)
2019-10-17T00:00:00Z 7641
2019-10-22T00:00:00Z 0
顯示的結果中,最後一天沒有資料,誤以為錯了,此處省略……… 最後一天顯示 0,終于知道那個叫暈的小夥伴為什麼把結果減了 1.這樣隻是把 顯示 零的問題消除了,導緻結果偏移了一天。 既然減去了8 小時顯示結果中的日期也是少了 8 小時,加上就自然對了。 感覺這樣不完美,壓根就不想讓這個多餘的 0 出現。因為查詢的調條件跨越了 8 小時導緻查詢的結果比預期的多了天。
下面是用東八區格式查詢的資料與R3339 查詢的結果一樣。都是因為跨越了8 小時導緻多查了一天:
SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00+08:00' and time < '2019-10-23T00:00:00+08:00' group by time(1d)
找到了原因如何查詢呢?那個叫暈的小夥伴提供了如下查詢方式,influxddb 查詢時指定時區。大吉大利!:
SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00+08:00' and time < '2019-10-23T00:00:00+08:00' group by time(1d) TZ('Asia/Shanghai')
time count
---- -----
2019-10-18T00:00:00+08:00 7641
2019-10-19T00:00:00+08:00 7522
2019-10-20T00:00:00+08:00 7355
2019-10-21T00:00:00+08:00 7740
2019-10-22T00:00:00+08:00 5997
本地時間隻包括目前的時間,不包含任何時區資訊。同一時刻,東八區的本地時間比零時區的本地時間快了8個小時。在不同時區之間交換時間資料,除了用純數字的時間戳,還有一種更友善人類閱讀的表示方式:标準時間的偏移量表示方法。
RFC3339詳細定義了網際網路上日期/時間的偏移量表示:
2017-12-08T00:08:00.00+08:00
時區知識點
這個代表了同一時刻的,東八區中原標準時間(CST)表示的方法 上面兩個時間的時間戳是等價的。兩個的差別,就是在本地時間後面增加了時區資訊。Z表示零時區。+08:00表示UTC時間增加8小時。 這種表示方式容易讓人疑惑的點是從标準時間換算UTC時間。以CST轉換UTC為例,沒有看文檔的情況下,根據 +08:00 的結尾,很容易根據直覺在本地時間再加上8小時。正确的計算方法是本地時間減去多增加的8小時。+08:00減去8小時才是UTC時間,-08:00加上8小時才是UTC時間。