Перейти к основному содержанию
Перейти к основному содержанию

DateTime

Тип DateTime позволяет хранить момент времени, который может быть выражен как календарная дата и время суток.

Синтаксис:

DateTime([timezone])

Поддерживаемый диапазон значений: [1970-01-01 00:00:00, 2106-02-07 06:28:15].

Точность: 1 секунда.

Скорость​

Тип данных Date работает быстрее, чем DateTime в большинстве случаев.

Тип Date занимает 2 байта, тогда как DateTime — 4. Однако при сжатии разница в размере между Date и DateTime становится более заметной. Это связано с тем, что минуты и секунды в DateTime хуже поддаются сжатию. Фильтрация и агрегация по Date вместо DateTime также выполняются быстрее.

Замечания по использованию​

Момент времени сохраняется в виде Unix timestamp, независимо от часового пояса или перехода на летнее время. Часовой пояс влияет на то, как значения типа DateTime отображаются в текстовом формате и как разбираются значения, заданные в виде строк ('2020-01-01 05:00:01').

Независимый от часового пояса Unix timestamp хранится в таблицах, а часовой пояс используется для преобразования его в текстовый формат или обратно при импорте/экспорте данных, а также для выполнения календарных вычислений над значениями (например, функциями toDate, toHour и т. д.). Часовой пояс не хранится в строках таблицы (или в результатах запроса), а хранится в метаданных столбца.

Список поддерживаемых часовых поясов можно найти в IANA Time Zone Database, а также получить запросом SELECT * FROM system.time_zones. Список также доступен в Википедии.

Вы можете явно задать часовой пояс для столбцов типа DateTime при создании таблицы. Пример: DateTime('UTC'). Если часовой пояс не задан, ClickHouse использует значение параметра timezone в настройках сервера или настройки операционной системы на момент запуска сервера ClickHouse.

По умолчанию clickhouse-client использует часовой пояс сервера, если часовой пояс явно не задан при инициализации типа данных. Чтобы использовать часовой пояс клиента, запустите clickhouse-client с параметром --use_client_time_zone.

ClickHouse выводит значения в зависимости от значения настройки date_time_output_format. По умолчанию используется текстовый формат YYYY-MM-DD hh:mm:ss. Кроме того, вы можете изменить формат вывода с помощью функции formatDateTime.

При вставке данных в ClickHouse вы можете использовать различные форматы строк даты и времени в зависимости от значения настройки date_time_input_format.

Примеры​

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

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

-- Парсинг DateTime
-- - из строки,
-- - из целого числа, интерпретируемого как количество секунд с 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 timestamp (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 ist_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 │
└─────────────────────┴─────────────────────┘

Поскольку преобразование часового пояса затрагивает только метаданные, эта операция не требует вычислительных ресурсов.

Ограничения поддержки часовых поясов​

Некоторые часовые пояса могут поддерживаться не полностью. Возможны следующие случаи:

Если смещение от UTC не кратно 15 минутам, вычисление часов и минут может быть некорректным. Например, часовой пояс в Монровии (Либерия) имел смещение UTC −0:44:30 до 7 января 1972 года. Если вы выполняете вычисления с историческим временем в часовом поясе Монровии, функции обработки времени могут выдавать некорректные результаты. Тем не менее результаты после 7 января 1972 года будут корректными.

Если переход времени (из‑за летнего времени или по другим причинам) был выполнен в момент времени, не кратный 15 минутам, вы также можете получить некорректные результаты в этот конкретный день.

Немонотонные календарные даты. Например, в Happy Valley - Goose Bay время было переведено на один час назад в 00:01:00 7 ноября 2010 года (через одну минуту после полуночи). Таким образом, после окончания 6 ноября люди наблюдали целую одну минуту 7 ноября, затем время было изменено обратно на 23:01 6 ноября, и после следующих 59 минут 7 ноября началось снова. ClickHouse (пока) не поддерживает такие особенности. В эти дни результаты работы функций обработки времени могут быть слегка некорректными.

Аналогичная проблема существует для антарктической станции Casey в 2010 году. Там перевели время на три часа назад 5 марта в 02:00. Если вы работаете на антарктической станции, пожалуйста, не бойтесь использовать ClickHouse. Просто убедитесь, что вы установили часовой пояс в UTC или учитываете возможные неточности.

Смещения времени на несколько дней. Некоторые тихоокеанские острова изменили своё смещение часового пояса с UTC+14 на UTC-12. Это допустимо, но могут возникать некоторые неточности, если вы выполняете вычисления с их часовым поясом для исторических моментов времени в дни перехода.

Обработка перехода на летнее время (DST)​

Тип DateTime с часовыми поясами в ClickHouse может вести себя неожиданным образом во время переходов на летнее время (Daylight Saving Time, DST), в частности, когда:

  • date_time_output_format установлен в значение simple.
  • Часы переводятся назад ("Fall Back"), что приводит к перекрытию одного часа.
  • Часы переводятся вперёд ("Spring Forward"), что приводит к пропуску одного часа.

По умолчанию ClickHouse всегда выбирает более раннее из двух перекрывающихся значений времени и может интерпретировать несуществующие моменты времени при переводе часов вперёд.

Например, рассмотрим следующий переход с летнего времени (DST) на стандартное время.

  • 29 октября 2023 года в 02:00:00 часы переводятся назад на 01:00:00 (BST → GMT).
  • Промежуток 01:00:00 – 01:59:59 встречается дважды (один раз в BST и один раз в 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 │
└─────────────────────┴─────────────────────┘

Аналогично, во время перехода со стандартного на летнее время может показаться, что один час пропущен.

Например:

  • 26 марта 2023 года в 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.

См. также​