DateTime
時刻を保存でき、カレンダーの日付と日の時間として表現できます。
構文：
サポートされる値の範囲： [1970-01-01 00:00:00, 2106-02-07 06:28:15]。
解像度：1秒。
Speed
Dateデータ型は、ほとんど の条件下で DateTime よりも高速です。
Date型は2バイトのストレージを必要とし、DateTimeは4バイトを必要とします。しかし、データベースが圧縮される際、この差は増幅されます。この増幅は、DateTimeの分と秒が圧縮しにくいためです。Dateをフィルタリングおよび集約する方がDateTimeよりも速いです。
Usage Remarks
時点は、タイムゾーンや夏時間に関係なく、Unixタイムスタンプとして保存されます。タイムゾーンは、DateTime型の値がテキスト形式でどのように表示されるか、また文字列として指定された値がどのように解析されるか（例：'2020-01-01 05:00:01'）に影響を与えます。
タイムゾーンに依存しないUnixタイムスタンプはテーブルに保存され、タイムゾーンはデータのインポート/エクスポート中にテキスト形式に変換するために、または値に対してカレンダー計算を行うために使用されます（例：toDate、toHour関数など）。タイムゾーンはテーブルの行（または結果セット）には保存されませんが、カラムのメタデータに保存されます。
サポートされているタイムゾーンのリストは、IANAタイムゾーンデータベースで確認でき、SELECT * FROM system.time_zonesを実行することでも照会できます。リストもWikipediaにあります。
テーブルを作成する際に DateTime型のカラムのタイムゾーンを明示的に設定できます。例：DateTime('UTC')。タイムゾーンが設定されていない場合、ClickHouseはサーバ設定のtimezoneパラメーターの値や、ClickHouseサーバの起動時のオペレーティングシステム設定の値を使用します。
clickhouse-clientは、データ型を初期化する際にタイムゾーンが明示的に設定されていない場合、デフォルトでサーバのタイムゾーンを適用します。クライアントタイムゾーンを使用するには、--use_client_time_zoneパラメーターを使用してclickhouse-clientを実行します。
ClickHouseは、date_time_output_format設定の値に応じて値を出力します。デフォルトではYYYY-MM-DD hh:mm:ssテキスト形式です。さらに、formatDateTime関数を使用して出力を変更できます。
ClickHouseにデータを挿入する際、date_time_input_format設定の値に応じて、異なる日付および時間形式の文字列を使用できます。
Examples
1. DateTime型のカラムを持つテーブルを作成し、データを挿入します：
- 整数として日付時刻を挿入すると、それはUnixタイムスタンプ（UTC）として扱われます。
1546300800は'2019-01-01 00:00:00'UTCを表します。しかし、timestampカラムにはAsia/Istanbul（UTC+3）タイムゾーンが指定されているため、文字列として出力される時は'2019-01-01 03:00:00'として表示されます。 - 文字列値として日付時刻を挿入すると、それはカラムのタイムゾーン内にあるものとして扱われます。
'2019-01-01 00:00:00'はAsia/Istanbulタイムゾーンにあるものとして扱われ、1546290000として保存されます。
2. DateTime値でのフィルタリング
DateTimeカラムの値は、WHERE述語で文字列値を使用してフィルタリングできます。自動的にDateTimeに変換されます：
3. DateTime型カラムのタイムゾーンの取得：
4. タイムゾーンの変換
タイムゾーンの変換はメタデータのみを変更するため、計算コストはかかりません。
Limitations on time zones support
一部のタイムゾーンは完全にはサポートされていない場合があります。いくつかのケースがあります：
UTCからのオフセットが15分の倍数でない場合、時間と分の計算が不正確になる可能性があります。たとえば、リベリアのモンロビアのタイムゾーンは、1972年1月7日以前はUTC -0:44:30のオフセットを持っていました。モンロビアタイムゾーンで歴史的な時間の計算を行っている場合、時間処理関数は不正確な結果を返す可能性があります。ただし、1972年1月7日以降の結果は正しいです。
時間遷移（夏時間のためやその他の理由による）が15分の倍数でない時点で実施された場合、その特定の日には不正確な結果が得られる可能性があります。
非単調なカレンダー日付。たとえば、ハッピーバレー - グースベイでは、2010年11月7日の00:01:00に1時間遡ります。したがって、6日が終了すると、人々は7日のまる1分を観測し、その後、時間は23:01 6日に戻り、さらに59分後に7日が再び始まりました。ClickHouseはこのような事例を（まだ）サポートしていません。このような日には、時間処理関数の結果がわずかに不正確になる可能性があります。
2010年のケースィ南極基地にも同様の問題があります。彼らは2010年3月5日02:00に3時間戻しました。南極基地で作業している場合は、ClickHouseを使用することを恐れないでください。ただし、タイムゾーンをUTCに設定するか、不正確さを認識していることを確認してください。
複数日にわたる時間シフト。一部の太平洋の島々は、タイムゾーンオフセットをUTC+14からUTC-12に変更しました。それは問題ありませんが、変換の日における歴史的なタイムポイントの計算時に不正確さが生じる可能性があります。
Handling Daylight Saving Time (DST)
ClickHouseのDateTime型は、特に次の場合に夏時間（DST）遷移中に予期しない動作を示すことがあります：
date_time_output_formatがsimpleに設定されている場合。- 時計が後ろに動く（「秋に戻る」）場合、1時間の重複が発生します。
- 時計が前に動く（「春に前進」）場合、1時間のギャップが発生します。
デフォルトでは、ClickHouseは常に重複する時間の早い時点を選択し、前方シフト中に存在しない時間を解釈する可能性があります。
たとえば、夏時間（DST）から標準時間への遷移を考えてみます。
- 2023年10月29日02:00:00に時計が01:00:00に戻ります（BST → GMT）。
- 01:00:00 - 01:59:59の時間が2回表示されます（1回はBST、1回はGMT）。
- ClickHouseは常に最初の発生（BST）を選択します。このため、時間間隔を加算する際に予期しない結果が生じます。
同様に、標準時間から夏時間への遷移中には、1時間がスキップされるように見えることがあります。
たとえば：
- 2023年3月26日、
00:59:59に時計が02:00:00にジャンプします（GMT → BST）。 01:00:00-01:59:59の時間は存在しません。
この場合、ClickHouseは存在しない時間2023-03-26 01:30:00を2023-03-26 00:30:00にシフトします。
