DateTime64 类型还可以存储整个列统一的 时区,这会影响 DateTime64 类型的值以文本 format 显示的方式,以及将字符串形式指定的值 (‘2020-01-01 05:00:01.000’) parse 的方式。时区 不存储在表的行中 (或结果集中) ,而是存储在列元数据中。详见 DateTime。
支持的值范围:[0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999]
小数点后的位数取决于 精度 参数。
注意:上述完整范围适用于最高 7 的精度。由于 ticks 存储在 Int64 中,更高的精度会覆盖更窄的范围:当精度为 8 时,最大值约为 4892-10-07;当使用 9 位数字 (纳秒) 的最大精度时,UTC 中支持的范围为 1677-09-21 00:12:44 到 2262-04-11 23:47:16。
示例
- 创建一个包含
DateTime64类型列的表,并向其中插入数据:
- 以数值形式插入 datetime 时,会像
DateTime一样将其视为以秒为单位的 Unix 时间戳 (UTC) 。1546300800表示 UTC 的'2019-01-01 00:00:00'。但由于timestamp列指定了Asia/Istanbul(UTC+3) 时区,因此以字符串形式输出时,该值会显示为'2019-01-01 03:00:00'。插入带小数部分的数值时,处理方式相同:小数点前的部分是以秒为单位的 Unix 时间戳,小数点后的部分则根据列的精度提供子秒级精度。 (在 26.8 版本之前,JSON和Values/Quoted输入路径中的无引号整数——后者涵盖所有使用Quoted转义规则解析字段的格式: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格式中,旧版流式 parser 会拒绝带小数部分的数值,随后会回退到 SQL expression 求值并按秒读取——这与 26.8 之前的版本相同。在JSONExtract和JSON数据类型中,带小数部分的值会通过Float64解析,因此位数超过Float64可保留范围的时间戳可能会舍入为相邻值;而行输入格式会精确解析原始文本。制表符分隔、CSV 及其他转义文本输入格式不受此设置控制,并会保留其对无引号数值的现有解释:较大的值将按 ticks 读取。) - 以字符串形式插入 datetime 值时,会将其视为采用列时区。
'2019-01-01 00:00:00'会被视为采用Asia/Istanbul时区,并存储为1546290000000。
- 过滤
DateTime64值
DateTime 不同,DateTime64 类型的值不会自动由 String 转换而来。
toDateTime64 函数会将数值参数视为秒数,因此子秒级精度需在小数点后给出。
- 获取
DateTime64类型值的时区:
- 时区转换