2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

MySQLとPostgreSQLでのtimezoneの取り扱いの違い

Posted at

#環境

  • 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つ入れるのは非力マシンなので避けたいし。
  • その他
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?