> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Documentación del tipo de dato DateTime64 en ClickHouse, que almacena marcas de tiempo con precisión de subsegundos # DateTime64 Permite almacenar un instante temporal, que puede expresarse como una fecha del calendario y una hora del día, con una precisión de subsegundos definida. Tamaño de tick (precisión): 10-precision segundos. Rango válido: \[ 0 : 9 ]. Normalmente se usan 3 (milisegundos), 6 (microsegundos) y 9 (nanosegundos). Valor predeterminado: 3 (milisegundos). **Sintaxis:** ```sql theme={null} DateTime64(precision, [timezone]) ``` Internamente, almacena los datos como una cantidad de 'ticks' desde el inicio de la epoch (1970-01-01 00:00:00 UTC) como Int64. La resolución de los ticks la determina el parámetro de precisión. Además, el tipo `DateTime64` puede almacenar una zona horaria que es la misma para toda la columna, lo que afecta a cómo se muestran en formato de texto los valores del tipo `DateTime64` y a cómo se analizan los valores especificados como cadenas ('2020-01-01 05:00:01.000'). La zona horaria no se almacena en las filas de la tabla (ni en el conjunto de resultados), sino en los metadatos de la columna. Consulte más detalles en [DateTime](/es/reference/data-types/datetime). Rango de valores admitido: \[0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999] La cantidad de dígitos después del punto decimal depende del parámetro de precisión. Nota: El rango completo anterior está disponible para precisiones de hasta 7. Como los ticks se almacenan en un `Int64`, las precisiones más altas cubren un rango más estrecho: con precisión 8 el valor máximo es aproximadamente `4892-10-07`, y con la precisión máxima de 9 dígitos (nanosegundos) el rango admitido es de `1677-09-21 00:12:44` a `2262-04-11 23:47:16` en UTC.
## Ejemplos
1. Crear una tabla con una columna de tipo `DateTime64` e insertar datos en ella: ```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 │ └─────────────────────────┴──────────┘ ``` * Al insertar un datetime como número, se trata como un Unix timestamp (UTC) en segundos, como `DateTime`. `1546300800` representa `'2019-01-01 00:00:00'` UTC. Sin embargo, como la columna `timestamp` tiene especificada la zona horaria `Asia/Istanbul` (UTC+3), al mostrarlo como cadena, el valor aparecerá como `'2019-01-01 03:00:00'`. Insertar un número con una parte fraccionaria funciona de la misma forma: la parte antes del punto decimal es el Unix timestamp en segundos y la parte posterior proporciona precisión de subsegundos según la precisión de la columna. (Antes de la versión 26.8, un entero sin comillas en las rutas de entrada `JSON` y `Values`/`Quoted` —esta última abarca todos los formatos que analizan campos con la regla de escape `Quoted`: `Values`, `MySQLDump` y `Template`/`CustomSeparated`/`Regexp` configurados con escape de campos `Quoted`— se interpretaba como el valor subyacente sin procesar con la precisión de la columna, por lo que `1546300800000` con precisión 3 significaba `'2019-01-01 00:00:00'`. Para restaurar el comportamiento anterior en estas rutas, establezca `input_format_read_datetime_number_as_raw_value = 1` (o `SET compatibility = '26.7'`); esto también afecta a la función `JSONExtract` y al tipo de datos `JSON`. La configuración de compatibilidad solo se aplica a enteros sin comillas: en el formato `Values`, un número fraccionario, que el analizador de streaming legacy rechaza, recurre a la evaluación de expresiones SQL y se lee como segundos, igual que en las versiones anteriores a la 26.8. En `JSONExtract` y el tipo de datos `JSON`, un valor fraccionario se analiza mediante `Float64`, por lo que un timestamp con más dígitos de los que `Float64` puede conservar puede redondearse al valor adyacente, a diferencia de los formatos de entrada por filas, que analizan el texto original con exactitud. Los formatos de entrada de texto separados por tabulaciones, CSV y otros con escape no se rigen por esta configuración y conservan su interpretación actual de un número sin comillas: un valor grande se lee como ticks.) * Al insertar un valor de cadena como datetime, se trata como si estuviera en la zona horaria de la columna. `'2019-01-01 00:00:00'` se interpretará como si estuviera en la zona horaria `Asia/Istanbul` y se almacenará como `1546290000000`. 2. Filtrado de valores `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 │ └─────────────────────────┴──────────┘ ``` A diferencia de `DateTime`, los valores de `DateTime64` no se convierten automáticamente a partir de `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 │ └─────────────────────────┴──────────┘ ``` Al igual que al insertar un número, la función `toDateTime64` interpreta un argumento numérico como un número de segundos, por lo que la precisión de subsegundos debe indicarse después del punto decimal. 3. Obtener la zona horaria de un valor de tipo `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. Conversión de zona horaria ```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 │ └─────────────────────────┴─────────────────────────┘ ``` **Véase también** * [Funciones de conversión de tipos](/es/reference/functions/regular-functions/type-conversion-functions) * [Funciones para trabajar con fechas y horas](/es/reference/functions/regular-functions/date-time-functions) * [El ajuste `date_time_input_format`](/es/reference/settings/formats/date-time#date_time_input_format) * [El ajuste `date_time_output_format`](/es/reference/settings/formats/date-time#date_time_output_format) * [El parámetro de configuración del servidor `timezone`](/es/reference/settings/server-settings/settings/other#timezone) * [El ajuste `session_timezone`](/es/reference/settings/session-settings/other#session_timezone) * [Operadores para trabajar con fechas y horas](/es/reference/operators/index#operators-for-working-with-dates-and-times) * [Tipo de dato `Date`](/es/reference/data-types/date) * [Tipo de dato `DateTime`](/es/reference/data-types/datetime)