Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Utilizzo dei dati con timestamp
<a name="data-types-timestamps"></a>

Questa sezione descrive alcune considerazioni sull'utilizzo dei dati con timestamp in Athena.

**Nota**  
Il trattamento dei timestamp è leggermente cambiato tra le versioni precedenti e la versione 3 del motore Athena. Per informazioni sugli errori relativi ai timestamp che possono verificarsi nella versione 3 del motore Athena e sulle soluzioni suggerite, consultare [Modifiche al timestamp](engine-versions-reference-0003.md#engine-versions-reference-0003-timestamp-changes) nei riferimenti [Versione 3 del motore Athena](engine-versions-reference-0003.md).

## Formato per la scrittura di dati timestamp su oggetti Amazon S3
<a name="data-types-timestamps-writing-to-s3-objects"></a>

Il formato in cui i dati timestamp devono essere scritti negli oggetti Amazon S3 dipende sia dal tipo di dati della colonna che [SerDedalla libreria utilizzata](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html).
+ Se hai una colonna di tabella di tipo `DATE`, Athena si aspetta che la colonna o la proprietà corrispondente dei dati sia una stringa in formato `YYYY-MM-DD` ISO o un tipo di data integrato come quelli per Parquet o ORC.
+ Se hai una colonna di tabella di tipo `TIME`, Athena si aspetta che la colonna o la proprietà corrispondente dei dati sia una stringa in formato `HH:MM:SS` ISO o un tipo di ora integrato come quelli per Parquet o ORC.
+ Se hai una colonna di tabella di tipo `TIMESTAMP`, Athena si aspetta che la colonna o la proprietà corrispondente dei dati sia una stringa nel formato `YYYY-MM-DD HH:MM:SS.SSS` (nota lo spazio tra la data e l'ora) o un tipo di ora integrato come quelli per Parquet, ORC o Ion. Nota che Athena non garantisce il comportamento per i timestamp non validi (ad esempio,). `0000-00-00 08:00:00.000`
**Nota**  
I timestamp Open CSVSer De sono un'eccezione e devono essere codificati come epoche UNIX con risoluzione in millisecondi.

## Come garantire che i dati partizionati nel tempo corrispondano al campo timestamp di un record
<a name="data-types-timestamps-time-partitioned-data-and-timestamp-fields"></a>

Il produttore dei dati deve assicurarsi che i valori della partizione siano allineati con i dati all'interno della partizione. Ad esempio, se i dati hanno una `timestamp` proprietà e si utilizza Firehose per caricare i dati in Amazon S3, è necessario [utilizzare il partizionamento dinamico](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html) perché il partizionamento predefinito di Firehose è. wall-clock-based

## Usa string come tipo di dati per le chiavi di partizione
<a name="data-types-timestamps-partition-key-types"></a>

Per motivi di prestazioni, è preferibile utilizzare `STRING` come tipo di dati per le chiavi di partizione. Anche se Athena riconosce i valori delle partizioni nel formato `YYYY-MM-DD` come date quando si utilizza il tipo `DATE`, ciò può portare a prestazioni scadenti. Per questo motivo, si consiglia di utilizzare invece il tipo di dati `STRING` per le chiavi di partizione.

## Come scrivere query per campi timestamp che sono anche partizionati in base all'ora
<a name="data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned"></a>

Il modo in cui si scrivono le query per i campi di indicazione temporale che sono partizionati in base all'ora dipende dal tipo di tabella su cui si intende eseguire la query.

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

Con le tabelle Hive più comunemente utilizzate in Athena, il motore di query non conosce le relazioni tra colonne e chiavi di partizione. Per questo motivo, devi sempre aggiungere predicati nelle tue query sia per la colonna che per la chiave di partizione.

Ad esempio, supponi di avere una colonna `event_time` e una chiave di partizione `event_date` e di voler eseguire query sugli eventi tra le 23:00 e le 03:00. In questo caso, è necessario includere i predicati nella query sia per la colonna che per la chiave di partizione, come nell'esempio seguente.

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

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

Con le tabelle Iceberg, puoi utilizzare valori di partizione calcolati, il che semplifica le tue query. Ad esempio, supponiamo che la tabella Iceberg sia stata creata con una clausola come la seguente: `PARTITIONED BY`

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

In questo caso, il motore di query elimina automaticamente le partizioni in base ai valori dei predicati `event_time`. Per questo motivo, la query deve solo specificare un predicato per `event_time`, come nell'esempio seguente.

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

Per ulteriori informazioni, consulta [Creazione di una tabella Iceberg](querying-iceberg-creating-tables.md).

Quando si utilizza il partizionamento nascosto di Iceberg per una colonna di timestamp, Iceberg potrebbe creare una partizione su una colonna di tabella costruita derivata da una colonna di timestamp e trasformata in una data per un partizionamento più efficace. Ad esempio, potrebbe creare dalla colonna timestamp e ripartire automaticamente. `event_date` `event_time` `event_date` **In questo caso, il **tipo** di partizione è una data.**

Per prestazioni di query ottimali quando usi la partizione, filtra in base a intervalli di giorni interi per abilitare il pushdown dei predicati. Ad esempio, la seguente query non verrebbe rimandata perché l’intervallo non può essere convertito in una singola partizione di date, anche se rientra nell’arco di un solo giorno:

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

Utilizzate invece un intervallo di giorni completi per consentire il pushdown dei predicati e migliorare le prestazioni delle query, come nell’esempio seguente.

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

Puoi anche utilizzare la `BETWEEN start_time AND end_time` sintassi o utilizzare gli intervalli di più giorni purché le porzioni relative ai timestamp lo siano. `00:00:00`

Per ulteriori informazioni, leggi il [post del blog di Trino](https://trino.io/blog/2023/04/11/date-predicates.html).