タイムゾーンの問題に関するよくある質問

はじめに

タイムゾーンの設定に関するよくある質問にお答えします。

なぜ、カードの時間と日付が間違って表示されるのでしょうか？

• タイムゾーンを設定するを参照してください。

会社のタイムゾーン設定を使用する、またはしないことによる影響は何でしょうか？

カードのデータは、会社のタイムゾーン設定の変更を反映して変更されます。Domo に読み込まれるデータは全て UTC とみなされ、会社のタイムゾーンの設定に従い、データのタイムゾーンは UTC からそのタイムゾーンに調整されます。

異なるタイムゾーンでデータが Domo に入ってくる場合は、この問題を緩和するための 4 つの最も簡単なオプションは、以下のとおりです（その単純さの度合い順になっています）：

• UTC で正規化されるように Beast Mode を使ってデータを変換する

• UTC で正規化されるように、DataFlow 内でデータを変換する

• 顧客側でデータを修正する

• API を使ってデータをコードで改変する

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

例えば、所在地が米国の東部時間であってこの設定をオンにすると、Domo が時間単位を使うカードをプロットする際は、データの時間は UTC であると想定し、5 時間（または夏時間の場合は 4 時間）戻した時刻が可視化に反映されます。そのため、DataSet の時刻の値が既に現地時間になっているのにこのタイムゾーン機能をオンにすると、カードに表示される時刻は正しく表示されません。

次の表は、会社のタイムゾーンを設定するまたはしないことによる具体的な影響を明確にしています：

DataSet 内の全ての日付/時刻値が UTC であることが確認できた場合は、会社のタイムゾーン設定をオンにするだけで、カードは現地時間を反映して更新されます。

タイムゾーンの調整: BeastMode 対 DataFlow

タイムゾーン変換は、Beast Mode の計算でも DataFlow でもできますが、状況に応じてどちらかのほうが良い場合があります。

結果フィールドに次の要件がある場合は、タイムゾーン変換には Beast Mode を使うほうが適しています：

• カードのデータ範囲フィールドとして使用する必要がない（現在、データ範囲フィールドでは Beast Mode 計算が使用できないため）。

• 他の Beast Mode 計算で使用する必要がない（フィールドを使用する全ての場所で変換コードを複製する必要があるため）。

カードを起動している DataSet を作成するのに DataFlow を既に使用している場合は、既存の DataFlow にタイムゾーン調整を組み込むのが最善の方法です。この場合、出力フィールドはカード上で日付範囲フィールドとして使用できるようになり、また Beast Mode の計算でも使用できるようになります。

また、タイムゾーンの調整に使用されるコードは、Beast Mode と MySQL DataFlow では異なります。MySQL では、タイムゾーンの調整は CONVERT_TZ() 関数を使って行います。夏時間も自動で処理します。Beast Mode 計算を使う場合が、夏時間はコード内で考慮される必要があります。

夏時間を考慮して Beast Mode 機能を調整するにはどうすればよいでしょうか？

問題:

DataFlow のタイムスタンプ出力は、インスタンスの現地タイムゾーン設定に従ってタイムスタンプを生成します。変換のプレビューで UTC と表示されていても、出力を作成する際には設定した時間に変換されます。それに対し、Beast Mode のタイムスタンプ機能では UTC 時間を基準にスタンプします。

そのため、これらのフィールド/機能を使って Beast Mode 計算を行う場合、なおかつその州が夏時間を使用している場合は、重大な問題を引き起こす可能性があります。

解決策：

UTC を正しいタイムゾーンに変換し、同時に夏時間を処理するような Beast Mode 計算を作成します。

次の例でその方法を示します。具体的には、このスクリプトは、所在地が夏時間になっているかどうかに応じて、「日付」列の値をシフトします：

CASE

WHEN `date` >= ADDDATE(STR_TO_DATE(CONCAT(YEAR(`date`),'03','01'),'%Y%m%d'),(MOD(15 - DAYOFWEEK(STR_TO_DATE(CONCAT(YEAR(`date`),'03','01'),'%Y%m%d')),7) + 7))

AND `date` < ADDDATE(STR_TO_DATE(CONCAT(YEAR(`date`),'11','01'),'%Y%m%d'),MOD(1 - DAYOFWEEK(STR_TO_DATE(CONCAT(YEAR(`date`),'11','01'),'%Y%m%d')),7))

then DATE_SUB(`date`,INTERVAL 4 HOUR)

else DATE_SUB(`date`,INTERVAL 5 HOUR)

END

Connector が間違った時間に実行されるのはなぜでしょうか？

問題：

特定の時刻に更新するように DataSet をスケジュールしたのに、更新履歴には別の時刻に実行されていると表示されているとします。

解決策：

顧客が DataSet を更新する時刻を設定した際、その時刻は UTC 時間に基づいています。ところが、更新履歴に表示される時刻は、会社のタイムゾーン設定に基づいた実際の更新時刻が表示されます。ジョブが UTC を使った正しい時刻に設定されているかを確認します。夏時間が問題になる場合は、この変更を考慮して、年に 2 回 Connectorスケジュールを更新する必要があるかもしれません。

DataSet のタイムスタンプが設定通りの時間にならないのはどうしてでしょうか？

問題：

これは 2 つの問題が原因で発生します。一番よくある原因として、タイムゾーンが会社の設定で正しくないことが考えられます。次に考えられる原因として、データのアップロードが UTC 以外のタイムゾーンでスケジュールされており、会社の設定によりタイムスタンプが会社の設定で選択しているものに変更されてしまっていることが考えられます。そのため、本当はそうではないにもかかわらず、Domo がデータを UTC で来ているものと認識してしまいます。

可能性のある解決策：

• 会社の設定を調整する

• DataSet または Connector の更新スケジュールを調整する

• 異なるタイムゾーン間の差異を解決する Beast Mode または DataFlow 計算を作成する

 (Workbench) DataSet ジョブのタイムゾーンを Workbench 4 で設定するには、どのようにするのでしょうか？

Workbench 内に、DataSet ジョブのタイムゾーンを設定するオプションがあります。ジョブがDomoに送信されると、全ての日時データはそのタイムゾーンに設定されます。DataSetにタイムゾーンを適用するには、日付タイムゾーンのシフト変換を使用します。

DataSet ジョブのタイムゾーンを設定するには、次を行います：

1. アカウントペインで、タイムゾーンを設定したい DataSet ジョブを選択します。

2. Workbench ウィンドウ上部のボタンツールバーの変換グループで、新規に追加をクリックします。

3. 変換タイプメニューで、日付タイムゾーンをシフトを選択し、次へをクリックします。

4. 最後に、終了を選択します。
   この時点で、DataSet ジョブの変換に、日付タイムゾーンをシフトが追加されます。

5. 次に、変換の下の新しい日付タイムゾーンをシフトのアイテムを選択します。

6. データタイムゾーンメニューでタイムゾーンを選択します。

7. Workbench ウィンドウ上部、ボタンツールバーの DataSet ジョブグループで保存をクリックします。

MySQL DataFlow を使ってタイムゾーンを変換するには、どのようにしたらよいでしょうか？

MySQL の CONVERT_TZ 関数を使えば、DataFlow のタイムゾーンを変換することができます。この関数は、夏時間の調整にも使えるよう設計されています。

この関数を実行する方法は、お気に入りの MySQL リソースを参照してください。