> ## Documentation Index
> Fetch the complete documentation index at: https://domoinc-bradley-turek-pfilter-operators-reference.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# タイムゾーンのフォーマット
## はじめに
Domoには、個人と会社の2種類のタイムゾーンがあります。誰でもDomoで個人のタイムゾーンを定義して、アラート、通知、スケジュールレポートを受け取るタイミングを決定できます。管理者レベルのユーザーは、インスタンス全体の会社のタイムゾーンを定義して、可視化の表示方法を標準化できます。
\*\*注記：\*\*この記事で使用する時間関連の略語は以下の通りです。
* UTC（協定世界時）
* EST（米国東部標準時）
* PST（太平洋標準時）
***
## 個人のタイムゾーン
ユーザー設定で個人のタイムゾーンを定義し、通知、アラート、スケジュールレポートがいつ配信されるかを管理できます。
## 個人のタイムゾーンを定義する
個人のタイムゾーンを設定するには、以下の手順に従います。
1. ナビゲーションで、自分のプロフィール画像を選択します。
2. \*\*［設定］\*\*を選択します。
3. \*\*［ローカライゼーション］\*\*タブに進みます。
4. （条件付き）\*\*［タイムゾーン］\*\*では、独自のタイムゾーンを選択するか、会社のタイムゾーンを使用するかを選択できます。
* ドロップダウンを展開し、タイムゾーンを選択します。
確認ダイアログで、\*\*［OK］\*\*を選択して変更を保存します。
* \*\*［タイムゾーン］**ドロップダウンで会社のタイムゾーンを確認し、**［タイムゾーンに設定］\*\*を選択します。
* 確認ダイアログで、\*\*［OK］\*\*を選択して変更を保存します。
\*\*注記：\*\*個人のタイムゾーンを更新しても、Domoに表示されているDATETIMEデータが、個人のタイムゾーンで表示されるよう補正されるわけではありません。会社のタイムゾーンを更新した場合のみ、すべてのDATETIMEデータが補正されます。詳細については、「[DomoにおけるDATETIMEに関する検討事項](#domoにおけるdatetimeに関する検討事項)」を参照してください。
## 会社のタイムゾーン
会社のタイムゾーンは、インスタンス全体のデフォルトです。デフォルトでは、会社のタイムゾーンはUTCです。必ずしも会社のタイムゾーンを定義する必要はありません。Domoデータがすべて同じタイムゾーンにある場合は、会社のタイムゾーンを設定する必要はありません。会社のタイムゾーンを定義する場合と定義しない場合の違いについては、追加の検討事項があります。後述のリストを参照してください。
\*\*重要：\*\*Domo内の自分のデータがすべて同じタイムゾーンにある場合は、タイムゾーンを設定する必要はありません。
## 必要な許可
会社のタイムゾーンを設定するには、管理者であるか、以下の許可が有効になっているカスタマイズされた権限を持っている必要があります。
**（管理者レベル）全てのカンパニー設定を管理** **—** この許可により、ユーザーは会社のメタデータ、認証ルール、セキュリティ、公開などを管理できます。
## 会社のタイムゾーンを定義する場合と定義しない場合
必ずしも会社のタイムゾーンを定義する必要はありませんが、注意すべき検討事項がいくつかあります。
\*\*重要：\*\*Domoでは、Domoに読み込まれたDATETIMEデータは読み込み時には*すべて*UTCであると想定されます。
例えば、Domoに読み込まれたDataSetにPSTのDATETIMEの値がある場合、Domoはこれを登録しません。変換（会社のタイムゾーンなど）は、データがUTCであるかのように適用されます。この例では、データはPST -8:00（PSTとUTCの時差）としてレンダリングされます。
***会社のタイムゾーンが定義されている場合は、以下のようになります。***
* Domoでは、読み込まれたDATETIMEデータはすべてUTCであると想定されるため、会社のタイムゾーンが定義されている場合、データはUTCから選択したタイムゾーンに合わせて調整されます。読み込まれたデータがUTCでない場合、可視化でのDATETIMEデータの表示方法に問題が発生します。データ自体は変更されません。
* データに以下の処理が行われる場合、会社のタイムゾーンとUTCの時差がすべてのDATETIMEの値に必ず加算または減算されます。
* DataSetプレビューでの表示のためにレンダリングされる。
* カードでの表示のためにレンダリングされる。
* 計算で使用される。
* カードとダッシュボードの日付単位（日/週/月）は、定義された会社のタイムゾーンに従います。
* 日は、会社のタイムゾーンの午前0時から始まります。
* 会社のタイムゾーンはDomoのすべてのDataSetに適用され、データ内の標準の日付と時刻の値には影響しません。DATETIMEの値にのみ影響します。
***会社のタイムゾーンが定義されていない場合は、以下のようになります。***
すべてのデータはUTCで表示され、DATETIMEフィールドをグローバルコーポレートタイムに変換する方法はありません。DATETIMEデータは、例えば「2014-08-14 15:05:30」のようになります。
例えば、7月にニューヨーク市にいて、日付がUTCで表示されている場合、UTCは夏時間の時期にはニューヨーク市（米国東部標準時）より4時間早くなるため、日付は午後8時に変更されます。
12月の同じシナリオでは、UTCはESTの5時間前であるため、日付は午後7時に変更されます。
詳細については、後述の「[DATETIMEに関する検討事項](#domoにおけるdatetimeに関する検討事項)」を参照してください。
## 会社のタイムゾーンを定義する
必要な許可を持っている管理者およびほかのユーザーは、以下の手順に従って、会社のタイムゾーンを定義できます。
1. 管理者設定に移動します。
2. \*\*［カンパニー設定］**で**［会社概要］\*\*を選択します。
3. \*\*［フォーマット］**で**［タイムゾーン］\*\*ドロップダウンからオプションを選択します。
4. \*\*［保存］\*\*を選択して変更を保存します。
## DomoにおけるDATETIMEに関する検討事項
***
## データを接続する
Domoでは入力DATETIMEの値はすべてUTCであると想定されているため、以下の点に注意してください。
* ユーザーが自分で管理するタイプのDataSet（Excel、Box、Googleスプレッドシート、アップロードファイルなど）をインポートしても、DATETIMEの値がUTCに変換されることはありません。そのため、こうしたDataSetをインポートする前に、DataSet内のデータをUTC形式で保存する必要があります。
* 特定のコネクター（Qualtrics、Adobe Analytics、SurveyMonkeyなど）からデータをインポートしても、DATETIMEの値がUTCに変換されることはありません。ただし、ほとんどのコネクターからは、デフォルトでUTC形式の値が提供されます。
\*\*重要：\*\*タイムゾーンの変換を正しく行うため、コネクターからインポートするデータのDATETIMEの値がUTC形式になっているか必ず確認してください。
\*\*注記：\*\*DATETIME列を、DATETIMEタイプではなく文字列データタイプとしてDomoに取り込んだ場合、そのDATETIME列がタイムゾーン設定にもとづいて自動的に変換されることはありません。
## DataFlowと変換
DataFlowは、変換後の値ではなく、データベース内の未加工データの値にもとづいて動作します。DataFlowのDATETIMEフィールドの値（未加工の値）を使用して値をグループ化すると、変換後の値を使用してカード上の値をグループ化した場合とは異なる計算結果になります。
DataFlowと計算の動的な日付と時刻の値の関数が、インスタンス内のタイムゾーン設定に影響を受けることはありません。以下に示す関数は、日付と時刻の値として必ずUTCを参照します。
* * `CURDATE()`
* `CURRENT_DATE()`
* `CURRENT_TIME()`
* `CURRENT_TIMESTAMP()`
* `CURTIME()`
* `NOW()`
* `SYSDATE()`
\*\*ヒント：\*\*Beast Modeで`SUBDATE`関数または`ADDDATE`関数を使用すると、日付と時刻の値を手動で調整することができます。詳細については、「[Beast Mode関数リファレンスガイド](/s/article/360043429933)」を参照してください。
## 計算またはDataFlowでタイムゾーンを変換する
タイムゾーンの変換は、計算でもDataFlowでも可能ですが、どちらのソリューションがより適しているかは状況しだいであることに注意してください。
### 計算で変換する
出力フィールドが以下の要件を満たしている場合は、計算でタイムゾーンを変換する方が適しています。
* 出力フィールドをカードの日付範囲フィールドとして使用する必要がない（現在、日付範囲フィールドに計算を使用できないため）。
* 出力フィールドをほかの計算で使用する必要がない（フィールドが使用されるすべての場所で変換コードを複製する必要が出てくる）。
#### 夏時間の計算を調整する
DataFlowのタイムスタンプ出力は、インスタンスの会社のタイムゾーン設定に従います。変換のプレビューにUTCが表示されていても、出力の生成時に設定した時刻に変換されます。ただし、計算のタイムスタンプ関数では、UTC時間に従ってスタンプされます。
そのため、これらのフィールド/関数から計算を行い、なおかつ、その州が夏時間を採用している場合、問題が発生する可能性があります。夏時間を考慮しながらUTCを適切なタイムゾーンに変換する計算を作成できます。以下の例を参照してください。
具体的には、このスクリプトでは、夏時間に入っているかどうかに応じてシフトされた「Date」列の値を指定します。
\*\*注記：\*\*米国の夏時間は3月の第2日曜日の午前2時に始まり、11月の第1日曜日の午前2時に終了します。
```
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
```
#### DataFlowで変換する
カードを起動するDataSetを作成するために既にDataFlowが使用されている場合、既存のDataFlowにタイムゾーンを調整するのが最善の方法です。その後、出力フィールドをカードまたは計算のデータ範囲フィールドとして使用できます。
#### タイムゾーンをMySQL DataFlowで変換する
MySQLの`CONVERT_TZ`関数を使用して、DataFlowのタイムゾーンを変換できます。この関数は、夏時間（DST）の調整にも対応できるように設計されています。
例えば、DATETIME列を協定世界時（UTC）から太平洋標準時（PST）に変換するには、以下の関数を使用します。
``CONVERT_TZ(`Date`, 'UTC', 'PSTUS/Pacific')``
Domoでは、MySQL関数の使用に関する詳細な資料は提供していません。インターネット上には多くの資料があります。
### DataSetおよびDataFlowのスケジュールを設定する
会社のタイムゾーンが定義されている場合でも、DataSetのスケジュールはUTCの値を使用して指定されます。スケジュールフィールドには、UTCラベルが表示されます。
DataSetとDataFlowの\*\*［履歴］\*\*タブに表示される実行時間は、常に閲覧しているコンピューターのタイムゾーンで表示されます。
## コードエンジン
コードエンジンエディターは、実行中にUTCを想定します。
## Workbench
日付タイムゾーンのシフト変換がDataSetジョブに適用されていない場合、WorkbenchをアップロードしてもDATETIMEの値はUTCには変換されません。「[Workbench 5ジョブのタイムゾーンを設定する](/s/article/360042932854)」を参照してください。
\*\*注記：\*\*Workbench DataSetジョブに対してスケジュールされている実行時間は、Workbenchがインストールされているマシンのクロックに従います。そのため、会社のタイムゾーン設定がWorkbenchのスケジュールに影響することはありません。
## よくある質問
これは、入力データと会社のタイムゾーンが競合していることが原因である可能性があります。前述の「会社のタイムゾーン」を参照してください。
DomoによるDATETIMEデータの処理方法については、[こちら](#domodatetime)も参照してください。
DataSetの更新のスケジュールを設定すると、スケジュールはUTCにもとづいて設定されます。ただし、更新履歴に表示されている時刻は、定義した会社のタイムゾーンにもとづいた実際の更新時刻です。スケジュール設定された時刻と表示された時刻の間に矛盾がある場合は、UTCを使用してジョブのスケジュールが正しく設定されていることを確認します。
夏時間が問題となる場合は、夏時間による変更を考慮して、コネクタースケジュールの更新を年2回行う必要があるかもしれません。「夏時間の計算を調整する」を参照してください。
これには、以下の2つの原因が考えられます。
a）最もよくある原因は、会社のタイムゾーンが正しく定義されていないことです。前述の「会社のタイムゾーンを定義する」を参照してください。
b）もう1つのよくある原因は、DataSetがUTC以外のタイムゾーンにアップロードされるようにスケジュール設定されており、定義された会社のタイムゾーンに合わせてタイムスタンプがシフトされていることです。つまり、アップロードされるデータがそうではなくても、DomoがデータはUTCで入力されるものと認識しているためです。
これを解決するには、DataSetやコネクターの更新スケジュールを調整するか、計算またはDataFlowを作成してタイムゾーン間の競合を解決します。