タイムスタンプ型データの時差問題(例:UTC-JSTの9時間時差)と対処方法
データの型に「タイムスタンプ型」というものがあります。「2022年12月16日 20:16」のように日付と時刻両方を保持する型です。
Domoでタイムスタンプ型のデータを扱うときには、協定世界時(UTC)と日本標準時(JST)の時差9時間に注意する必要があるので解説します。
解説
日本はイギリスと比べて+9時間の誤差があるということを学校で習いましたが、
Domoでタイムスタンプ型を扱うときにその影響を受けてしまいます。
世界標準時(UTC)の解説をされているサイトがあったので引用します。
現在時刻 協定世界時(UTC) 日本標準時(JST)
気象データなどで、『2016/08/30 15:00(UTC)』『日時は協定世界時(UTC)に準拠』などという表記を見かけることがあります。(『10:37:19 GMT』なども)
- 協定世界時(UTC)は、世界各国標準時の基礎となるもので、セシウム原子時計によって刻まれる国際原子時を基に国際的に管理されています。
- 以前は、世界標準時としてグリニッジ標準時(GMT)が広く使われていましたが、現在は協定世界時(UTC)に役割を譲っています。
- 世界各地の標準時は協定世界時(UTC)を基準として定められており、日本標準時(JST)は、協定世界時より9時間進んでいます(東経135度分の時差)。このことから、日本標準時は「+0900(JST)」と表記されます。 [Wikipedia ]
- 協定世界時:UTC = Coordinated Universal Time
- 日本標準時:JST = Japan Standard Time
- 日本標準時(JST)は、協定世界時(UTC)のプラス9時間( UTC + 9 )ですので
…- UTC が午前0時の時、JST は午前9時です。
- UTC が午後3時(15時)の時、JST は翌日の午前0時です。
どこで影響を受けるかというと、Magic ETL 、SQL DataFlowFです。
データ加工で現在の時刻を取得したいときに、CURRENT_TIME()などの関数を使いますが、
このような結果が返ってきます。
Magic ETL - 2022/9/1 AM8:55に実行した結果
SQL Dataflow - 2022/9/1 AM8:48に実行した結果
Beast Mode - 2022/9/1 AM8:54に実行した結果
SQL DataFlowと同様の内容をBeast Modeで書いた結果がこちら
日本では17:40でも、UTCだとマイナス9時間されるために、8:40という結果が返ってくるわけですね。
実際に私がこれでやらかした例をご紹介します。
ある処理を毎月初1日の早朝に行う必要があり、その中でCURRENT_TIMESTAMP()を使っていたのですが、
実行されるのがAM7:00ゴごろだったために前の月の最終日だと勘違いされ、
意図とは全く違うデータが出来上がったしまいました。
同じ日で9時間ずれるだけなら問題ない場合もあるかもしれませんが、
処理によっては日単位、月単位で変わってしまうために注意が必要です。
タイムスタンプ型を使うときはくれぐれもご注意ください。
・会社のデータをもっと有効活用をしたい
・BIツールを導入したい
・BIツールに取り込みたいデータソースがある
・BIツールの効果的な可視化についてもっと知りたい
・組織においてのBIツールの定着化をもっと推進したい
・新しいKPIを作りたいが、自信がない
アタラにはBIツールのエキスパートが多数在籍しております。このような課題をお持ちの方は、アタラ合同会社のBIツール導入コンサルティングサービスへお気軽にお問い合わせください。
この記事をシェアする
まずはお気軽にご相談ください
BIシステムの導入からデータ活用の自走化まで支援いたします