[go: up one dir, main page]
メインコンテンツまでスキップ
メインコンテンツまでスキップ

DateTime

カレンダーの日付と1日の時間として表現できる瞬時の時間を保存することができます。

構文:

DateTime([timezone])

サポートされている値の範囲: [1970-01-01 00:00:00, 2106-02-07 06:28:15]。

解像度: 1秒。

Speed​

Dateデータ型は、ほとんど の条件下でDateTimeよりも高速です。

Date型は2バイトのストレージを必要とし、DateTimeは4バイトを必要とします。しかし、圧縮中に、DateとDateTimeのサイズの違いはより顕著になります。この増幅は、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型のカラムを持つテーブルを作成し、そのデータを挿入する:

CREATE TABLE dt
(
    `timestamp` DateTime('Asia/Istanbul'),
    `event_id` UInt8
)
ENGINE = TinyLog;

-- Parse DateTime
-- - from string,
-- - from integer interpreted as number of seconds since 1970-01-01.
INSERT INTO dt VALUES ('2019-01-01 00:00:00', 1), (1546300800, 2);

SELECT * FROM dt;

┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
│ 2019-01-01 03:00:00 │        2 │
└─────────────────────┴──────────┘
  • 整数としてdatetimeを挿入すると、それはUnix タイムスタンプ（UTC）として扱われます。1546300800は'2019-01-01 00:00:00' UTCを表します。しかし、timestampカラムにはAsia/Istanbul（UTC+3）タイムゾーンが指定されているため、文字列として出力される際には値は'2019-01-01 03:00:00'として表示されます。
  • 文字列値をdatetimeとして挿入する場合、それはカラムのタイムゾーンであるとみなされます。'2019-01-01 00:00:00'はAsia/Istanbulタイムゾーンであると見なされ、1546290000として保存されます。

2. DateTime値のフィルタリング

SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Asia/Istanbul')

┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
└─────────────────────┴──────────┘

DateTimeカラムの値は、WHERE述語内の文字列値を使用してフィルタリングできます。自動的にDateTimeに変換されます:

SELECT * FROM dt WHERE timestamp = '2019-01-01 00:00:00'

┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
└─────────────────────┴──────────┘

3. DateTime型のカラムのタイムゾーンを取得:

SELECT toDateTime(now(), 'Asia/Istanbul') AS column, toTypeName(column) AS x

┌──────────────column─┬─x─────────────────────────┐
│ 2019-10-16 04:12:04 │ DateTime('Asia/Istanbul') │
└─────────────────────┴───────────────────────────┘

4. タイムゾーン変換

SELECT
toDateTime(timestamp, 'Europe/London') AS lon_time,
toDateTime(timestamp, 'Asia/Istanbul') AS mos_time
FROM dt

┌───────────lon_time──┬────────────mos_time─┐
│ 2019-01-01 00:00:00 │ 2019-01-01 03:00:00 │
│ 2018-12-31 21:00:00 │ 2019-01-01 00:00:00 │
└─────────────────────┴─────────────────────┘

タイムゾーン変換はメタデータのみを変更するため、計算コストはありません。

Limitations on time zones support​

一部のタイムゾーンは完全にはサポートされていない場合があります。いくつかのケース:

UTCからのオフセットが15分の倍数でない場合、時間と分の計算が不正確になることがあります。例えば、リベリアのモンロビアのタイムゾーンは、1972年1月7日以前はUTC -0:44:30でした。モンロビアタイムゾーンでの歴史的時刻に対する計算を行うと、時間処理関数が不正確な結果を返す可能性があります。しかし、1972年1月7日以降の結果は正確なものになります。

もしタイムの変化（夏時間やその他の理由による）が15分の倍数でない時点で実施された場合、この特定の日に不正確な結果が返されることもあります。

非単調カレンダー日付。例えば、Happy Valley - Goose Bayでは、2010年11月7日00:01:00に、時間が1時間戻された。（真夜中の1分後）したがって、11月6日が終了した後、人々は11月7日の1分間を観察し、その後11月6日の23:01に戻され、さらに59分後に11月7日が再び始まった。ClickHouseはこのような処理を（まだ）サポートしていません。これらの日の結果は、時間処理関数で若干の不正確さが生じるかもしれません。

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）を選択するため、時間間隔を加算すると予期しない結果になります。
SELECT '2023-10-29 01:30:00'::DateTime('Europe/London') AS time, time + toIntervalHour(1) AS one_hour_later

┌────────────────time─┬──────one_hour_later─┐
│ 2023-10-29 01:30:00 │ 2023-10-29 01:30:00 │
└─────────────────────┴─────────────────────┘

同様に、標準時間から夏時間への遷移中、ある時間がスキップしているように見えることがあります。

例えば：

  • 2023年3月26日、00:59:59に時計が02:00:00（GMT → BST）にジャンプします。
  • 時間01:00:00 - 01:59:59は存在しません。
SELECT '2023-03-26 01:30:00'::DateTime('Europe/London') AS time, time + toIntervalHour(1) AS one_hour_later

┌────────────────time─┬──────one_hour_later─┐
│ 2023-03-26 00:30:00 │ 2023-03-26 02:30:00 │
└─────────────────────┴─────────────────────┘

この場合、ClickHouseは存在しない時間2023-03-26 01:30:00を2023-03-26 00:30:00に戻します。

See Also​