Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Utilisation des données d’horodatage
<a name="data-types-timestamps"></a>

Cette section décrit certaines considérations relatives à l'utilisation des données d'horodatage dans Athena.

**Note**  
Le traitement des horodatages a quelque peu changé dans la version 3 du moteur Athena par rapport à la version précédente. Pour plus d'informations sur les erreurs liées à l'horodatage qui peuvent se produire dans la version 3 du moteur Athena et sur les solutions proposées, consultez [Modifications d'horodatage](engine-versions-reference-0003.md#engine-versions-reference-0003-timestamp-changes) dans la référence [Version 3 du moteur Athena](engine-versions-reference-0003.md).

## Format pour écrire des données d'horodatage dans des objets Amazon S3
<a name="data-types-timestamps-writing-to-s3-objects"></a>

Le format dans lequel les données d'horodatage doivent être écrites dans les objets Amazon S3 dépend à la fois du type de données de colonne et de la [SerDebibliothèque](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html) que vous utilisez.
+ Si vous avez une colonne de table de type `DATE`, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au format ISO `YYYY-MM-DD` ou un type de date intégré comme ceux de Parquet ou ORC.
+ Si vous avez une colonne de table de type `TIME`, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au format ISO `HH:MM:SS` ou un type d'heure intégré comme ceux de Parquet ou ORC.
+ Si vous avez une colonne de table de type `TIMESTAMP`, Athena s'attend à ce que la colonne ou la propriété correspondante des données soit une chaîne au format `YYYY-MM-DD HH:MM:SS.SSS` (notez l'espace entre la date et l'heure) ou un type d'heure intégré comme ceux de Parquet, ORC ou Ion. Notez qu’Athena ne garantit pas le comportement des horodatages non valides (par exemple, `0000-00-00 08:00:00.000`).
**Note**  
Les horodatages Open CSVSer De constituent une exception et doivent être codés en tant qu'époques UNIX de résolution en millisecondes.

## S'assurer que les données partitionnées dans le temps correspondent au champ d'horodatage d'un enregistrement
<a name="data-types-timestamps-time-partitioned-data-and-timestamp-fields"></a>

Le producteur des données doit s'assurer que les valeurs de partition correspondent aux données contenues dans la partition. Par exemple, si vos données ont une `timestamp` propriété et que vous utilisez Firehose pour les charger dans Amazon S3, vous devez utiliser le partitionnement [dynamique car le partitionnement](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html) par défaut de Firehose est le suivant. wall-clock-based

## Utiliser STRING comme type de données pour les clés de partition
<a name="data-types-timestamps-partition-key-types"></a>

Pour des raisons de performances, il est préférable d'utiliser `STRING` comme type de données pour les clés de partition. Même si Athena reconnaît les valeurs de partition au format `YYYY-MM-DD` comme des dates lorsque vous utilisez le type `DATE`, cela peut entraîner de mauvaises performances. Pour cette raison, nous vous recommandons d'utiliser plutôt le type de données `STRING` pour les clés de partition.

## Comment écrire des requêtes pour des champs d'horodatage qui sont également partitionnés dans le temps
<a name="data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned"></a>

La façon dont vous rédigez les requêtes pour les champs d'horodatage partitionnés dans le temps dépend du type de table que vous souhaitez interroger.

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

Avec les tables Hive les plus couramment utilisées dans Athena, le moteur de requête n'a aucune connaissance des relations entre les colonnes et les clés de partition. Pour cette raison, vous devez toujours ajouter des prédicats dans vos requêtes pour la colonne et pour la clé de partition.

Supposons, par exemple, que vous disposiez d'une colonne `event_time` et d'une clé de partition `event_date` et que vous souhaitiez interroger des événements survenus entre 23 h 00 et 03 h 00. Dans ce cas, vous devez inclure des prédicats dans votre requête pour la colonne et pour la clé de partition, comme dans l'exemple suivant.

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

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

Avec les tables Iceberg, vous pouvez utiliser des valeurs de partition calculées, ce qui simplifie vos requêtes. Supposons, par exemple, que votre table Iceberg ait été créée avec une clause `PARTITIONED BY` comme celle-ci :

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

Dans ce cas, le moteur de requête réduit automatiquement les partitions en fonction des valeurs des prédicats `event_time`. Pour cette raison, votre requête doit uniquement spécifier un prédicat pour `event_time`, comme dans l'exemple suivant.

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

Pour de plus amples informations, veuillez consulter [Création de tables Iceberg](querying-iceberg-creating-tables.md).

Lorsque vous utilisez le partitionnement caché d’Iceberg pour une colonne d’horodatage, Iceberg peut créer une partition sur une colonne de table construite dérivée d’une colonne d’horodatage et transformée en date pour un partitionnement plus efficace. Par exemple, il peut créer `event_date` à partir de la colonne d’horodatage `event_time` et partitionner automatiquement `event_date`. Dans ce cas, le **type** de partition est une **date**.

Pour des performances de requête optimales avec la partition, appliquez des filtres sur des plages de jours complets pour permettre la poussée des prédicats. Par exemple, la requête suivante ne sera pas poussée, car la plage ne peut pas être convertie en une seule partition de date, même si elle correspond à un seul jour :

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

Utilisez plutôt une plage de jours complets pour permettre la poussée des prédicats et améliorer les performances des requêtes, comme illustré dans l’exemple suivant.

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

Vous pouvez également utiliser la syntaxe `BETWEEN start_time AND end_time` ou des plages de plusieurs jours, à condition que les parties d’horodatage soient `00:00:00`.

Pour plus d’informations, consultez cet [article de blog Trino](https://trino.io/blog/2023/04/11/date-predicates.html).