Domo実験室-タイムゾーンの問題に関するよくある質問を検証してみた

今回は「2022/1/1 9:00:00」のように年月日に時分秒も付加したタイムスタンプ型を用いたカラムで日次集計したり、BeastModeの日時関連の関数を使用すると、意図しない結果になる場合を解説いたします。

タイムスタンプ型を用いて日次集計する場合の考慮点

上図のようなデータをDomoに取り込むと下図のように時間が存在するdateTimeカラムに9時間足されます。そのためdateTimeカラムの3レコード目が取込み前は「2022/01/05 16:00:01」だったのが取込後「2022年1月6日 1:00:01 午前」になります。

上図をdateカラムで日次集計すると2022年1月5日が3レコードあるので金額は300円です。datetimeカラムで日次集計すると 2022年1月5日は2レコードになりますので200円となります。

Domo社のKnowledge Base「タイムゾーンの問題に関するよくある質問」によりますと

Domo はデータの日付/時刻の値が毎回 UTC として入ってくるものとして仮定しているため、タイムゾーンの設定を変更することは、要するに日付/時刻の値を、UTC と選択したタイムゾーンの間の時間オフセットを用いて前後に調整するよう Domo に指示することになります。

との記述があります。

Domoを日本国内で用いる場合、多くのユーザーはカンパニー設定でタイムゾーンを日本時間であるAsia/Tokyoに設定していると思います。取り込んだデータは協定世界時であるUTC（いわゆる世界標準時刻）として取り込むので、取り込んだデータを日本時間であるAsia/Tokyoにして表示しようとし、UTCと日本時間との差である9時間を足してしまいます。

「2022/1/5」のような日付のみのカラムでは9時間を足しはしないので、日次集計する場合は日付のみのカラムで実施すると混乱しないで済みます。ですが年月日時分秒が存在するタイムスタンプ型カラムのみ集計に利用出来ない場合はETLで9時間引いた「日本時間カラム」を作ると回避案の一つとして分かり易いかもしれません。

BeastModeの日時関連の関数使用の考慮点

BeastModeの日付/時間に関連した関数を用いる場合もUTCとAsia/Tokyoとの時間差9時間の考慮が「運用によっては」必要です。下図は1月6日の朝8時になろうとしているところで、BeastMode関数で年月日と年月日時分秒を取得するカードを表示したスクリーンショットです。

日本時間では既に1月6日でもUTCは9時間差がありますので、昨日である1月5日であり、時刻は22:59ぐらいで、あと1時間程度経過するとUTCでも1月6日になる事が分かります。Domo社のコミュニティーサイトDojoに「Beast Mode にて今日を指定する関数 [ CURRENT_DATE() など ] のタイムゾーンに関する注意点」によりますと

厳密に日本時間で日付を変更する場合には、9時間を足して計算する必要があります。
例：CURRENT_TIMESTAMP()に9時間（32400秒）追加する
DATE_FORMAT(ADDTIME(CURRENT_TIMESTAMP(),32400),'%Y-%m-%d')

年月日だけが必要であれば、朝の9:00以前に参照しなければ無害に思えますが、24時間データ更新と参照を行っている場合は、考慮が必要と考えます。

ソリューション・サービス

クラウド・サービス

IBM i 関連

ブログ

タイムスタンプ型を用いて日次集計する場合の考慮点

BeastModeの日時関連の関数使用の考慮点

関連リンク