# Trabajo con datos de marca de tiempo
<a name="data-types-timestamps"></a>

En esta sección se describen algunas consideraciones para trabajar con datos de marcas de tiempo en Athena.

**nota**  
El tratamiento de las marcas de tiempo ha cambiado ligeramente entre las versiones anteriores del motor y la versión 3 del motor de Athena. Para obtener información sobre los errores relacionados con la marca de tiempo que se pueden producir en la versión 3 del motor de Athena y las soluciones sugeridas, consulte [Cambios en la marca de tiempo](engine-versions-reference-0003.md#engine-versions-reference-0003-timestamp-changes) en la referencia de [Versión 3 del motor Athena](engine-versions-reference-0003.md).

## Formato para escribir datos de marcas de tiempo en objetos de Amazon S3
<a name="data-types-timestamps-writing-to-s3-objects"></a>

El formato en el que se deben escribir los datos de marcas de tiempo en los objetos de Amazon S3 depende tanto del tipo de datos de la columna como de la [biblioteca SerDe](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html) que utilice.
+ Si cuenta con una columna de tabla de tipo `DATE`, Athena espera que la columna o propiedad correspondiente de los datos sea una cadena en el formato ISO `YYYY-MM-DD` o un tipo de fecha integrado, como los de Parquet u ORC.
+ Si cuenta con una columna de tabla de tipo `TIME`, Athena espera que la columna o propiedad correspondiente de los datos sea una cadena en el formato ISO `HH:MM:SS` o un tipo de hora integrado, como los de Parquet u ORC.
+ Si cuenta con una columna de tabla de tipo `TIMESTAMP`, Athena espera que la columna o propiedad correspondiente de los datos sea una cadena en el formato `YYYY-MM-DD HH:MM:SS.SSS` (tenga en cuenta el espacio entre la fecha y la hora) o un tipo de hora integrado, como los de Parquet, ORC o Ion. Tenga en cuenta que Athena no garantiza el comportamiento de las marcas de tiempo que son inválidas (por ejemplo, `0000-00-00 08:00:00.000`).
**nota**  
Las marcas de tiempo de OpenCSVSerDe son una excepción y se deben codificar como periodos UNIX con una resolución de milisegundos.

## Cómo garantizar que los datos particionados en el tiempo coincidan con el campo de marca de tiempo de un registro
<a name="data-types-timestamps-time-partitioned-data-and-timestamp-fields"></a>

El productor de los datos debe asegurarse de que los valores de la partición se alineen con los datos de la partición. Por ejemplo, si sus datos tienen una propiedad `timestamp` y utiliza Firehose para cargar los datos en Amazon S3, debe utilizar la [partición dinámica](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html), ya que la partición predeterminada de Firehose se basa en un tiempo cronológico.

## Uso de una cadena como tipo de datos para las claves de partición
<a name="data-types-timestamps-partition-key-types"></a>

Por motivos de rendimiento, es preferible utilizar `STRING` como el tipo de datos para las claves de partición. Si bien Athena reconoce los valores de partición en el formato `YYYY-MM-DD` como fechas al utilizar el tipo `DATE`, esto puede provocar un rendimiento deficiente. Por este motivo, en su lugar le recomendamos que utilice el tipo de datos `STRING` para las claves de partición.

## Cómo escribir consultas para campos de marca de tiempo que también se encuentren particionados por tiempo
<a name="data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned"></a>

La forma en que se escriben las consultas para los campos de marca de tiempo que se encuentran particionados por tiempo dependen del tipo de tabla que se desee consultar.

### Tablas de Hive
<a name="data-types-timestamps-hive-tables"></a>

Con las tablas de Hive más utilizadas en Athena, el motor de consultas no conoce las relaciones entre las columnas y las claves de partición. Por este motivo, siempre debe agregar predicados en las consultas tanto para la columna como para la clave de partición.

Por ejemplo, supongamos que tiene una columna `event_time` y una clave de partición `event_date` y desea consultar eventos entre las 23:00 y las 03:00. En este caso, debe incluir predicados en la consulta tanto para la columna como para la clave de partición, como en el siguiente ejemplo.

```
WHERE event_time BETWEEN start_time AND end_time 
  AND event_date BETWEEN start_time_date AND end_time_date
```

### Tablas de Iceberg
<a name="data-types-timestamps-iceberg-tables"></a>

Con las tablas de Iceberg, puede utilizar valores de partición calculados, lo que simplifica las consultas. Por ejemplo, supongamos que la tabla de Iceberg se creó con una cláusula `PARTITIONED BY` como la siguiente:

```
PARTITIONED BY (event_date month(event_time))
```

En este caso, el motor de consultas reduce de forma automática las particiones en función de los valores de los predicados `event_time`. Por este motivo, la consulta solo necesita especificar un predicado para `event_time`, como en el siguiente ejemplo.

```
WHERE event_time BETWEEN start_time AND end_time
```

Para obtener más información, consulte [Creación de tablas de Iceberg](querying-iceberg-creating-tables.md).

Al utilizar la partición oculta de Iceberg para una columna de tipo marca de tiempo, Iceberg puede crear una partición en una columna de tabla construida, derivada de una columna de marca de tiempo y transformada en una fecha para una partición más eficiente. Por ejemplo, podría crear `event_date` a partir de la columna de marca de tiempo `event_time` y particionar automáticamente por `event_date`. En este caso, el **tipo** de partición es una **fecha**.

Para conseguir un rendimiento óptimo de las consultas al utilizar la partición, filtre por rangos de días completos para habilitar la propagación de predicados. Por ejemplo, la siguiente consulta no aplicaría la propagación de predicados porque el rango no se puede convertir en una única partición de fecha, a pesar de que está dentro de un mismo día.

```
WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-18 12:00:00'
```

En su lugar, utilice un rango de día completo para permitir la propagación del predicado y mejorar el rendimiento de la consulta, como en el siguiente ejemplo.

```
WHERE event_time >= TIMESTAMP '2024-04-18 00:00:00' AND event_time < TIMESTAMP '2024-04-19 00:00:00'
```

También puede utilizar la sintaxis `BETWEEN start_time AND end_time` o emplear rangos de varios días siempre que las porciones de marcas de tiempo sean `00:00:00`.

Para obtener más información, consulte la [publicación en el blog de Trino](https://trino.io/blog/2023/04/11/date-predicates.html).