#環境
- MySQL 5.6
- PostgreSQL 12
- Grafana 7.0.0
- Windows
- DB,クライアントのタイムゾーンはAsia/Tokyo
内容
DATE型カラム(hogedate)に'2020-07-20'が入っている場合
MySQLでそのカラムをUNIX_TIMESTAMP(hogedate)すると2020-07-19 15:00:00のUNIX TIMESTAMPが得られる。
PostgreSQLでそのカラムをEXTRACT(EPOCH FROM hogedate)すると、2020-07-20 00:00:00のUNIX TIMESTAMPが得られる。
PostgreSQLは全体的にtimezoneを考慮しない方針の様子
SELECT EXTRACT(EPOCH FROM timestamp '2020-07-20 00:00:00')
=> 1595203200 (2020-07-20 00:00:00UTCのUNIX時間)
SELECT EXTRACT(EPOCH FROM timestamp with time zone '2020-07-20 00:00:00')
=> 1595170800 (2020-07-19 15:00:00UTCのUNIX時間)
試してないけど、普通にテーブルに入れて試しても同じ結果になるだろう。
日本国内に閉じたシステムであれば、 無理に考慮してくれない方が扱いやすい。
調べた経緯
GrafanaでMySQL内に入っている日時データを取得してグラフ表示しているが、どうも数が合わない。
DATEカラムを時間軸にするようなグラフを書く場合、$__timeGroupAlias(hogedatecol, '1d', 0)などとGrafanaマクロを使ってると、UNIX_TIMESTAMP(hogedatecol)が取られるが、この場合は、9時間前のUNIX時間が返ってしまう。
例)カラムの値が'2020-07-20'だと、MySQLでその値をUNIX_TIMESTAMP()すると、'2020-07-19 15:00:00'のUNIX時間が帰ってくる。そのあとで、上記例だと1日で丸めるために、86400(1日の秒数)で割って、掛け戻してるため、2020-7-19で丸められてしまう。。。
対応としてはどうするべきなのだろうか?
- Grafanaのマクロを使用しない
=> 基本これかな。面倒だけど。 - DBのタイムゾーンの設定をしない
=> 今回は扱う必要がないのでこれでもいいけど、DBがUTC、クライアントがAsia/Tokyoの場合の動きを確認? - PostgreSQLを使う
=> 今回はお遊びツールなのでこれでもいいけど、ちょっと今から返るの面倒だな。
プロダクトはMySQL/MariaDBなのでDBを2つ入れるのは非力マシンなので避けたいし。 - その他