内容

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