DateTime64

Позволяет хранить момент времени, который можно представить в виде календарной даты и времени суток, с заданной точностью до долей секунды Размер тика (precision): 10^-precision секунды. Допустимый диапазон: [ 0 : 9 ]. Обычно используются значения: 3 (миллисекунды), 6 (микросекунды), 9 (наносекунды). Значение по умолчанию: 3 (миллисекунды). Синтаксис:

DateTime64(precision, [timezone])

Внутренне хранит данные как количество ‘тиков’ с начала эпохи (1970-01-01 00:00:00 UTC) в виде Int64. Разрешение тиков определяется параметром precision. Кроме того, тип DateTime64 может хранить часовой пояс, общий для всего столбца, что влияет на то, как значения типа DateTime64 отображаются в текстовом формате, и на то, как разбираются значения, заданные в виде строк (‘2020-01-01 05:00:01.000’). Часовой пояс не хранится в строках таблицы (или в наборе результатов), а хранится в метаданных столбца. Подробности см. в DateTime. Поддерживаемый диапазон значений: [0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999] Количество цифр после десятичной точки зависит от параметра precision. Примечание: полный диапазон выше доступен для значений precision до 7. Поскольку тики хранятся в Int64, более высокие значения precision охватывают более узкий диапазон: при precision 8 максимальное значение составляет примерно 4892-10-07, а при максимальной точности в 9 цифр (наносекунды) поддерживаемый диапазон в UTC — от 1677-09-21 00:12:44 до 2262-04-11 23:47:16.

Примеры

Создание таблицы со столбцом типа DateTime64 и вставка в неё данных:

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 в виде числа оно интерпретируется как Unix-временная метка (UTC) в секундах, как и DateTime. 1546300800 соответствует '2019-01-01 00:00:00' UTC. Однако, поскольку для столбца timestamp указан часовой пояс Asia/Istanbul (UTC+3), при выводе в виде строки значение будет показано как '2019-01-01 03:00:00'. Вставка числа с дробной частью работает так же: часть до десятичной точки — это Unix-временная метка в секундах, а часть после неё задаёт точность до долей секунды в соответствии с точностью столбца. (До версии 26.8 целое число без кавычек во входных путях JSON и Values/Quoted — последний охватывает все форматы, разбирающие поля с правилом экранирования Quoted: Values, MySQLDump и Template/CustomSeparated/Regexp, настроенные с экранированием полей Quoted, — вместо этого интерпретировалось как необработанное внутреннее значение с точностью столбца, поэтому 1546300800000 при точности 3 означало '2019-01-01 00:00:00'. Чтобы восстановить прежнее поведение в этих путях, задайте input_format_read_datetime_number_as_raw_value = 1 (или SET compatibility = '26.7'); это также влияет на функцию JSONExtract и тип данных JSON. Настройка совместимости регулирует только целое число без кавычек: в формате Values дробное число, которое устаревший потоковый парсер отклоняет, передаётся на вычисление SQL-выражения и читается как секунды — так же, как в версиях до 26.8. В JSONExtract и типе данных JSON дробное значение разбирается через Float64, поэтому временная метка с большим количеством цифр, чем может сохранить Float64, может округлиться до соседнего значения, в отличие от построчных входных форматов, которые точно разбирают исходный текст. Входные форматы с экранированным текстом, разделённые табуляцией, CSV и другие, не регулируются этой настройкой и сохраняют существующую интерпретацию числа без кавычек: большое значение читается как тики.)
При вставке строкового значения в datetime оно интерпретируется в часовом поясе столбца. '2019-01-01 00:00:00' будет интерпретироваться как значение в часовом поясе Asia/Istanbul и сохранено как 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 │
└─────────────────────────┴─────────────────────────┘

См. также

Справочник по SQL

Типы данных

Движки

Функции

Форматы

Настройки

Системные таблицы

Озёра данных

Примеры

​Примеры

Примеры