Set up docs MCP指定した秒未満の精度で、暦日と時刻で表せる時点を格納できます
ティックサイズ (精度) : 10-精度 Seconds。有効範囲: [ 0 : 9 ]。 通常は 3 (ミリ秒) 、6 (マイクロ秒) 、9 (ナノ秒) が使用されます。
デフォルト値: 3 (ミリ秒)。
構文:
DateTime64(precision, [timezone])内部的には、epoch の開始時点 (1970-01-01 00:00:00 UTC) からの 'tick' 数としてデータを Int64 で格納します。tick の resolution は 精度 パラメータによって決まります。さらに、DateTime64 型にはカラム全体で共通の timezone を格納できます。これは、DateTime64 型の値がテキストフォーマットでどのように表示されるか、および文字列として指定された値 ('2020-01-01 05:00:01.000') がどのように parse されるかに影響します。timezone は table の行 (または resultset) には格納されず、カラムのメタデータに格納されます。詳細は DateTime を参照してください。
サポートされる値の範囲: [0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999]
小数点以下の桁数は 精度 パラメータによって決まります。
注: 上記の完全な範囲は、精度が 7 までの場合に利用できます。tick は Int64 に格納されるため、より高い精度では扱える範囲が狭くなります。精度 8 の場合の最大値はおよそ 4892-10-07 で、最大精度の 9 桁 (ナノ秒) の場合、サポートされる範囲は UTC で 1677-09-21 00:12:44 から 2262-04-11 23:47:16 です。
例
DateTime64型のカラムを持つ table を作成し、データを挿入する:
CREATE TABLE dt64
(
`timestamp` DateTime64(3, 'Asia/Istanbul'),
`event_id` UInt8
)
ENGINE = MergeTree;-- Parse DateTime64
-- - from an integer interpreted as the number of seconds since 1970-01-01 (like DateTime),
-- - from a decimal interpreted as the number of seconds, the fractional part giving sub-second precision,
-- - from a string.
INSERT INTO dt64
VALUES
(1546300800, 1),
(1546300800.123, 2),
('2019-01-01 00:00:00', 3);
SELECT * FROM dt64;┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 03:00:00.000 │ 1 │
│ 2019-01-01 03:00:00.123 │ 2 │
│ 2019-01-01 00:00:00.000 │ 3 │
└─────────────────────────┴──────────┘- datetime を数値として insert すると、
DateTimeと同様に秒単位の Unix Timestamp (UTC) として扱われます。1546300800は UTC の'2019-01-01 00:00:00'を表します。ただし、timestampカラムにはAsia/Istanbul(UTC+3) の timezone が指定されているため、文字列として出力すると、値は'2019-01-01 03:00:00'と表示されます。小数部を持つ数値を insert する場合も同様です。小数点より前の部分は秒単位の Unix Timestamp、小数点より後の部分はカラムの精度に応じた秒未満の精度を表します。 (バージョン 26.8 より前では、JSONおよびValues/Quotedの入力パスにおける引用符なしの整数 (後者は、Quotedエスケープルールでフィールドを parseするすべてのフォーマット、すなわちValues、MySQLDump、およびQuotedフィールドエスケープを設定したTemplate/CustomSeparated/Regexpを対象とします) は、カラム精度における生の基礎値として解釈されていたため、精度 3 の1546300800000は'2019-01-01 00:00:00'を意味していました。これらのパスで以前の動作を復元するには、input_format_read_datetime_number_as_raw_value = 1(またはSET compatibility = '26.7') を設定します。これはJSONExtract関数およびJSONデータ型にも影響します。互換性設定が適用されるのは引用符なしの整数のみです。Valuesフォーマットでは、レガシー streaming parser が受け付けない小数値は SQL 式評価にフォールバックし、秒として読み取られます。これは 26.8 より前のバージョンと同じです。JSONExtractおよびJSONデータ型では、小数値はFloat64を通じて parseされるため、Float64が保持できる桁数を超えるタイムスタンプは、元のテキストを正確に parseする行入力フォーマットとは異なり、隣接する値に丸められる可能性があります。タブ区切り、CSV、およびその他のエスケープされたテキスト入力フォーマットはこの設定の対象外であり、引用符なしの数値について既存の解釈を維持します。つまり、大きな値は ticks として読み取られます。) - 文字列値を datetime として insert すると、カラムの timezone の時刻として扱われます。
'2019-01-01 00:00:00'はAsia/Istanbultimezone の時刻として解釈され、1546290000000として保存されます。
DateTime64の値に対するフィルタリング
SELECT * FROM dt64 WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Asia/Istanbul');┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00.000 │ 3 │
└─────────────────────────┴──────────┘DateTime とは異なり、DateTime64 の値は String から自動では変換されません。
SELECT * FROM dt64 WHERE timestamp = toDateTime64(1546300800.123, 3);┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 03:00:00.123 │ 1 │
│ 2019-01-01 03:00:00.123 │ 2 │
└─────────────────────────┴──────────┘数値を挿入する場合と同様に、toDateTime64 関数は数値引数を秒数として扱うため、秒未満の
精度は小数点以下で指定する必要があります。
DateTime64型の値のタイムゾーンを取得する:
SELECT toDateTime64(now(), 3, 'Asia/Istanbul') AS column, toTypeName(column) AS x;┌──────────────────column─┬─x──────────────────────────────┐
│ 2023-06-05 00:09:52.000 │ DateTime64(3, 'Asia/Istanbul') │
└─────────────────────────┴────────────────────────────────┘- タイムゾーン変換
SELECT
toDateTime64(timestamp, 3, 'Europe/London') AS lon_time,
toDateTime64(timestamp, 3, 'Asia/Istanbul') AS istanbul_time
FROM dt64;┌────────────────lon_time─┬───────────istanbul_time─┐
│ 2019-01-01 00:00:00.123 │ 2019-01-01 03:00:00.123 │
│ 2019-01-01 00:00:00.123 │ 2019-01-01 03:00:00.123 │
│ 2018-12-31 21:00:00.000 │ 2019-01-01 00:00:00.000 │
└─────────────────────────┴─────────────────────────┘関連項目