> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.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<sup>-precision</sup> 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: \[1900-01-01 00:00:00, 2299-12-31 23:59:59.999999999]

La cantidad de dígitos después del punto decimal depende del parámetro de precisión.

Nota: La precisión del valor máximo es 8. Si se usa la precisión máxima de 9 dígitos (nanosegundos), el valor máximo admitido es `2262-04-11 23:47:16` en UTC.

<div id="examples">
  ## Ejemplos
</div>

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}
-- Parsear DateTime
-- - desde un entero interpretado como el número de milisegundos (debido a la precisión 3) desde 1970-01-01,
-- - desde un decimal interpretado como el número de segundos antes de la parte decimal, y basado en la precisión después del punto decimal,
-- - desde una cadena de texto.

INSERT INTO dt64
VALUES
(1546300800123, 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.123 │        1 │
│ 2019-01-01 03:00:00.123 │        2 │
│ 2019-01-01 00:00:00.000 │        3 │
└─────────────────────────┴──────────┘
```

* Al insertar un datetime como entero, se trata como un Unix timestamp (UTC) con la escala adecuada. `1546300800000` (con precisión 3) 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 datetime como decimal se trata de forma similar a un entero, salvo que el valor antes del punto decimal es el Unix timestamp hasta los segundos inclusive, y el valor después del punto decimal se interpreta como la precisión.
* 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 │
└─────────────────────────┴──────────┘
```

A diferencia de la inserción, la función `toDateTime64` tratará todos los valores como la variante decimal, por lo que la precisión debe
indicarse después del punto decimal.

3. Obtener una 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_input_format)
* [El ajuste `date_time_output_format`](/es/reference/settings/formats#date_time_output_format)
* [El parámetro de configuración del servidor `timezone`](/es/reference/settings/server-settings/settings#timezone)
* [El ajuste `session_timezone`](/es/reference/settings/session-settings#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)
