Permite armazenar um instante no tempo, que pode ser expresso como uma data de calendário e uma hora do dia.
Sintaxe:
Faixa de valores suportada: [1970-01-01 00:00:00, 2106-02-07 06:28:15].
Resolução: 1 segundo.
O tipo de dados Date é mais rápido que DateTime na maioria dos casos.
O tipo Date requer 2 bytes de armazenamento, enquanto DateTime requer 4. No entanto, durante a compressão, a diferença de tamanho entre Date e DateTime se torna mais significativa. Isso ocorre porque os minutos e segundos em DateTime são menos compressíveis. Filtrar e agregar Date em vez de DateTime também é mais rápido.
O instante no tempo é salvo como um Unix timestamp, independentemente do fuso horário ou do horário de verão. O fuso horário afeta como os valores do tipo DateTime são exibidos em formato de texto e como os valores especificados como strings são interpretados ('2020-01-01 05:00:01').
Um Unix timestamp independente de fuso horário é armazenado nas tabelas, e o fuso horário é usado para convertê-lo para o formato de texto ou de volta durante a importação/exportação de dados, ou para fazer cálculos de calendário com os valores (exemplo: funções toDate, toHour etc.). O fuso horário não é armazenado nas linhas da tabela (nem no conjunto de resultados), mas nos metadados da coluna.
Uma lista dos fusos horários compatíveis pode ser encontrada no IANA Time Zone Database e também pode ser consultada com SELECT * FROM system.time_zones. A lista também está disponível na Wikipedia.
Você pode definir explicitamente um fuso horário para colunas do tipo DateTime ao criar uma tabela. Exemplo: DateTime('UTC'). Se o fuso horário não for definido, o ClickHouse usa o valor do parâmetro timezone nas configurações do servidor ou nas configurações do sistema operacional no momento da inicialização do ClickHouse server.
O clickhouse-client aplica o fuso horário do servidor por padrão se um fuso horário não for explicitamente definido ao inicializar o tipo de dado. Para usar o fuso horário do cliente, execute clickhouse-client com o parâmetro --use_client_time_zone.
O ClickHouse gera valores de acordo com o valor da configuração date_time_output_format. O formato de texto YYYY-MM-DD hh:mm:ss é usado por padrão. Além disso, você pode alterar a saída com a função formatDateTime.
Ao inserir dados no ClickHouse, você pode usar diferentes formatos de strings de data e hora, dependendo do valor da configuração date_time_input_format.
1. Criando uma tabela com uma coluna do tipo DateTime e inserindo dados nela:
CREATE TABLE dt
(
`timestamp` DateTime('Asia/Istanbul'),
`event_id` UInt8
)
ENGINE = TinyLog;
-- Converter DateTime
-- - a partir de string,
-- - a partir de inteiro interpretado como número de segundos desde 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 │
└─────────────────────┴──────────┘
- Ao inserir um datetime como inteiro, ele é tratado como Unix timestamp (UTC).
1546300800 representa '2019-01-01 00:00:00' UTC. No entanto, como a coluna timestamp tem o fuso horário Asia/Istanbul (UTC+3) especificado, ao ser exibido como string, o valor será mostrado como '2019-01-01 03:00:00'
- Ao inserir um valor em string como datetime, ele é tratado como estando no fuso horário da coluna.
'2019-01-01 00:00:00' será tratado como estando no fuso horário Asia/Istanbul e salvo como 1546290000.
2. Filtragem de valores 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 podem ser filtrados usando um valor em formato de string no predicado WHERE. Ele será convertido automaticamente para DateTime:
SELECT * FROM dt WHERE timestamp = '2019-01-01 00:00:00'
┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │ 1 │
└─────────────────────┴──────────┘
DateTime:
SELECT toDateTime(now(), 'Asia/Istanbul') AS column, toTypeName(column) AS x
┌──────────────column─┬─x─────────────────────────┐
│ 2019-10-16 04:12:04 │ DateTime('Asia/Istanbul') │
└─────────────────────┴───────────────────────────┘
SELECT
toDateTime(timestamp, 'Europe/London') AS lon_time,
toDateTime(timestamp, 'Asia/Istanbul') AS istanbul_time
FROM dt
┌───────────lon_time──┬───────istanbul_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 │
└─────────────────────┴─────────────────────┘
Limitações no suporte a fusos horários
date_time_output_format está definido como simple.- Os relógios são atrasados (“Fall Back”), causando uma sobreposição de uma hora.
- Os relógios são adiantados (“Spring Forward”), causando um intervalo de uma hora.
Por padrão, o ClickHouse sempre escolhe a primeira ocorrência de um horário sobreposto e pode interpretar horários inexistentes durante os adiantamentos do relógio.
Por exemplo, considere a seguinte transição do horário de verão (DST) para a hora padrão.
- Em 29 de outubro de 2023, às 02:00:00, os relógios voltam para 01:00:00 (BST → GMT).
- A hora 01:00:00 – 01:59:59 aparece duas vezes (uma em BST e outra em GMT)
- O ClickHouse sempre escolhe a primeira ocorrência (BST), o que causa resultados inesperados ao adicionar intervalos de tempo.
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 │
└─────────────────────┴─────────────────────┘
- Em 26 de março de 2023, às
00:59:59, os relógios avançam para 02:00:00 (GMT → BST).
- O intervalo entre
01:00:00 e 01:59:59 não existe.
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 │
└─────────────────────┴─────────────────────┘
2023-03-26 01:30:00 para 2023-03-26 00:30:00.
Última modificação em 10 de junho de 2026
