DateTime64 pode armazenar um fuso horário que é o mesmo para toda a coluna, o que afeta como os valores do tipo DateTime64 são exibidos em formato de texto e como os valores especificados como strings são analisados (‘2020-01-01 05:00:01.000’). O fuso horário não é armazenado nas linhas da tabela (ou no conjunto de resultados), mas nos metadados da coluna. Veja os detalhes em DateTime.
Intervalo de valores compatível: [0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999]
O número de dígitos após o separador decimal depende do parâmetro de precisão.
Observação: o intervalo completo acima está disponível para precisões de até 7. Como os ticks são armazenados em um Int64, precisões mais altas abrangem um intervalo mais estreito: com precisão 8, o valor máximo é aproximadamente 4892-10-07, e com a precisão máxima de 9 dígitos (nanossegundos), o intervalo compatível é de 1677-09-21 00:12:44 a 2262-04-11 23:47:16 em UTC.
Exemplos
- Criando uma tabela com uma coluna do tipo
DateTime64e inserindo dados nela:
- Ao inserir um datetime como número, ele é tratado como um Unix Timestamp (UTC) em segundos, como
DateTime.1546300800representa'2019-01-01 00:00:00'UTC. No entanto, como a colunatimestamptem o fuso horárioAsia/Istanbul(UTC+3) especificado, ao ser exibido como string, o valor será mostrado como'2019-01-01 03:00:00'. Inserir um número com uma parte fracionária funciona da mesma forma: a parte antes do separador decimal é o Unix Timestamp em segundos, e a parte após ele fornece precisão de frações de segundo de acordo com a precisão da coluna. (Antes da versão 26.8, um inteiro simples sem aspas nos caminhos de entradaJSONeValues/Quoted— este último abrangendo todos os formatos que analisam campos com a regra de escapeQuoted:Values,MySQLDumpeTemplate/CustomSeparated/Regexpconfigurados com escape de campoQuoted— era interpretado como o valor bruto subjacente na precisão da coluna; portanto,1546300800000com precisão 3 significava'2019-01-01 00:00:00'. Para restaurar o comportamento anterior nesses caminhos, definainput_format_read_datetime_number_as_raw_value = 1(ouSET compatibility = '26.7'); isso também afeta a funçãoJSONExtracte o tipo de dadosJSON. A configuração de compatibilidade rege apenas um inteiro simples: no formatoValues, um número fracionário, que o parser de streaming legado rejeita, recorre à avaliação de expressão SQL e é lido como segundos — da mesma forma que nas versões anteriores a 26.8. EmJSONExtracte no tipo de dadosJSON, um valor fracionário é analisado por meio deFloat64; portanto, um timestamp com mais dígitos do queFloat64consegue preservar pode ser arredondado para o valor adjacente, diferentemente dos formatos de entrada baseados em linhas, que analisam o texto original exatamente. Os formatos de entrada de texto separados por tabulação, CSV e outros formatos de texto com escape não são regidos por essa configuração e mantêm sua interpretação atual de um número sem aspas: um valor grande é lido como ticks.) - 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árioAsia/Istanbule armazenado como1546290000000.
- Filtragem por valores
DateTime64
DateTime, os valores DateTime64 não são convertidos automaticamente a partir de String.
toDateTime64 trata um argumento numérico como um número de segundos, portanto, a
precisão de subsegundos deve ser informada após o separador decimal.
- Obtendo o fuso horário de um valor do tipo
DateTime64:
- Conversão de fuso horário
- Funções de conversão de tipos
- Funções para trabalhar com datas e horas
- A configuração
date_time_input_format - A configuração
date_time_output_format - O parâmetro
timezoneda configuração do servidor - A configuração
session_timezone - Operadores para trabalhar com datas e horas
- Tipo de dado
Date - Tipo de dado
DateTime