> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > Документация по типу данных DateTime64 в ClickHouse, который хранит временные метки с точностью до долей секунды # DateTime64 Позволяет хранить момент времени, который можно представить в виде календарной даты и времени суток, с заданной точностью до долей секунды Размер тика (precision): 10-precision секунды. Допустимый диапазон: \[ 0 : 9 ]. Обычно используются значения: 3 (миллисекунды), 6 (микросекунды), 9 (наносекунды). Значение по умолчанию: 3 (миллисекунды). **Синтаксис:** ```sql theme={null} DateTime64(precision, [timezone]) ``` Внутренне хранит данные как количество 'тиков' с начала эпохи (1970-01-01 00:00:00 UTC) в виде Int64. Разрешение тиков определяется параметром precision. Кроме того, тип `DateTime64` может хранить часовой пояс, общий для всего столбца, что влияет на то, как значения типа `DateTime64` отображаются в текстовом формате, и на то, как разбираются значения, заданные в виде строк ('2020-01-01 05:00:01.000'). Часовой пояс не хранится в строках таблицы (или в наборе результатов), а хранится в метаданных столбца. Подробности см. в [DateTime](/docs/ru/reference/data-types/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`.
## Примеры
1. Создание таблицы со столбцом типа `DateTime64` и вставка в неё данных: ```sql theme={null} CREATE TABLE dt64 ( `timestamp` DateTime64(3, 'Asia/Istanbul'), `event_id` UInt8 ) ENGINE = MergeTree; ``` ```sql theme={null} -- 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; ``` ```text theme={null} ┌───────────────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`. 2. Фильтрация значений `DateTime64` ```sql theme={null} SELECT * FROM dt64 WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Asia/Istanbul'); ``` ```text theme={null} ┌───────────────timestamp─┬─event_id─┐ │ 2019-01-01 00:00:00.000 │ 3 │ └─────────────────────────┴──────────┘ ``` В отличие от `DateTime`, значения `DateTime64` автоматически не преобразуются из `String`. ```sql theme={null} SELECT * FROM dt64 WHERE timestamp = toDateTime64(1546300800.123, 3); ``` ```text theme={null} ┌───────────────timestamp─┬─event_id─┐ │ 2019-01-01 03:00:00.123 │ 1 │ │ 2019-01-01 03:00:00.123 │ 2 │ └─────────────────────────┴──────────┘ ``` Как и при вставке числа, функция `toDateTime64` интерпретирует числовой аргумент как количество секунд, поэтому дробную часть секунды необходимо указывать после десятичной точки. 3. Получение часового пояса для значения типа `DateTime64`: ```sql theme={null} SELECT toDateTime64(now(), 3, 'Asia/Istanbul') AS column, toTypeName(column) AS x; ``` ```text theme={null} ┌──────────────────column─┬─x──────────────────────────────┐ │ 2023-06-05 00:09:52.000 │ DateTime64(3, 'Asia/Istanbul') │ └─────────────────────────┴────────────────────────────────┘ ``` 4. Преобразование часовых поясов ```sql theme={null} SELECT toDateTime64(timestamp, 3, 'Europe/London') AS lon_time, toDateTime64(timestamp, 3, 'Asia/Istanbul') AS istanbul_time FROM dt64; ``` ```text theme={null} ┌────────────────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 │ └─────────────────────────┴─────────────────────────┘ ``` **См. также** * [Функции преобразования типов](/docs/ru/reference/functions/regular-functions/type-conversion-functions) * [Функции для работы с датами и временем](/docs/ru/reference/functions/regular-functions/date-time-functions) * [Настройка `date_time_input_format`](/docs/ru/reference/settings/formats/date-time#date_time_input_format) * [Настройка `date_time_output_format`](/docs/ru/reference/settings/formats/date-time#date_time_output_format) * [Параметр конфигурации сервера `timezone`](/docs/ru/reference/settings/server-settings/settings/other#timezone) * [Настройка `session_timezone`](/docs/ru/reference/settings/session-settings/other#session_timezone) * [Операторы для работы с датами и временем](/docs/ru/reference/operators/index#operators-for-working-with-dates-and-times) * [Тип данных `Date`](/docs/ru/reference/data-types/date) * [Тип данных `DateTime`](/docs/ru/reference/data-types/datetime)