# Trabalhar com dados de timestamp
<a name="data-types-timestamps"></a>

Esta seção descreve algumas considerações para trabalhar com dados de timestamp no Athena.

**nota**  
O tratamento dos timestamps mudou um pouco entre as versões anteriores do mecanismo do Athena e o mecanismo do Athena versão 3. Para obter informações sobre erros relacionados ao timestamp que podem ocorrer no mecanismo do Athena versão 3 e soluções sugeridas, consulte [Alterações de timestamp](engine-versions-reference-0003.md#engine-versions-reference-0003-timestamp-changes) na referência [Mecanismo Athena versão 3](engine-versions-reference-0003.md).

## Formato para gravar dados de timestamp em objetos do Amazon S3
<a name="data-types-timestamps-writing-to-s3-objects"></a>

O formato no qual os dados de timestamp devem ser gravados em objetos do Amazon S3 depende do tipo de dados da coluna e da [biblioteca SerDe](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html) utilizada.
+ Se você tiver uma coluna de tabela do tipo `DATE`, o Athena espera que a coluna ou propriedade correspondente dos dados seja uma string no formato ISO `YYYY-MM-DD` ou um tipo de data incorporado, como aqueles para Parquet ou ORC.
+ Se você tiver uma coluna de tabela do tipo `TIME`, o Athena espera que a coluna ou propriedade correspondente dos dados seja uma string no formato ISO `HH:MM:SS` ou um tipo de hora incorporado, como aqueles para Parquet ou ORC.
+ Se você tiver uma coluna de tabela do tipo `TIMESTAMP`, o Athena espera que a coluna ou propriedade correspondente dos dados seja uma string no formato `YYYY-MM-DD HH:MM:SS.SSS` (observe o espaço entre a data e a hora) ou um tipo de hora incorporado, como aqueles para Parquet, ORC ou Ion. Observe que o Athena não garante o comportamento com timestamps inválidos (por exemplo `0000-00-00 08:00:00.000`).
**nota**  
Os timestamps do OpenCsvSerDe são uma exceção e devem ser codificados como epochs UNIX com resolução de milissegundos.

## Garantir que os dados particionados por tempo correspondam ao campo de timestamp em um registro
<a name="data-types-timestamps-time-partitioned-data-and-timestamp-fields"></a>

O produtor dos dados deve garantir que os valores da partição estejam alinhados com os dados na partição. Por exemplo, se os dados tiverem uma propriedade `timestamp` e você usar o Firehose para carregá-los no Amazon S3, será necessário usar o [particionamento dinâmico](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html) porque o particionamento padrão do Firehose é baseado em hora real do relógio.

## Usar string como o tipo de dados para chaves de partição
<a name="data-types-timestamps-partition-key-types"></a>

Por motivos de performance, é preferível usar `STRING` como tipo de dados para chaves de partição. Embora o Athena reconheça valores de partição no formato `YYYY-MM-DD` como datas quando você usa o tipo `DATE`, isso pode levar a uma performance ruim. Por isso, recomenda-se usar o tipo de dados `STRING` para chaves de partição.

## Como gravar consultas em campos de timestamp que também são particionados por tempo
<a name="data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned"></a>

A forma como você grava consultas em campos de timestamp que são particionados por hora depende do tipo de tabela que você deseja consultar.

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

Com as tabelas Hive mais usadas no Athena, o mecanismo de consulta não tem conhecimento das relações entre as colunas e as chaves de partição. Por isso, você sempre deve adicionar predicados às consultas tanto para a coluna como para a chave de partição.

Por exemplo, suponha que você tenha uma coluna `event_time` e uma chave de partição `event_date` e queira consultar eventos entre 23:00 e 03:00. Nesse caso, é necessário incluir predicados em sua consulta para a coluna e a chave de partição, como no exemplo a seguir.

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

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

Com as tabelas Iceberg, é possível usar valores de partição computados, o que simplifica suas consultas. Por exemplo, suponha que sua tabela do Iceberg tenha sido criada com uma cláusula `PARTITIONED BY` como esta:

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

Nesse caso, o mecanismo de consulta remove automaticamente as partições com base nos valores dos predicados `event_time`. Por isso, sua consulta só precisa especificar um predicado para `event_time`, como no exemplo a seguir.

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

Para obter mais informações, consulte [Criar tabelas do Iceberg](querying-iceberg-creating-tables.md).

Ao usar o particionamento oculto do Iceberg para uma coluna de timestamp, o Iceberg pode criar uma partição em uma coluna de tabela construída derivada de uma coluna de timestamp e transformada em uma data para proporcionar um particionamento mais eficaz. Por exemplo, ele pode criar `event_date` a partir da coluna de timestamp `event_time` e particionar automaticamente em `event_date`. Nesse caso, o **tipo** da partição é uma **data**.

Para usufruir da performance ideal da consulta ao usar a partição, filtre por intervalos de dias inteiros para habilitar o pushdown de predicados. Por exemplo, a consulta a seguir não seria submetida a pushdown porque o intervalo não pode ser convertido em uma única partição de data, mesmo que esteja dentro de um único dia:

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

Em vez disso, use um intervalo de dias inteiros para permitir o pushdown de predicados e melhorar a performance da consulta, como no exemplo a seguir.

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

Você também pode usar a sintaxe `BETWEEN start_time AND end_time` ou usar os intervalos de vários dias, desde que as partes dos timestamps sejam `00:00:00`.

Para obter mais informações, consulte a [postagem do blog do Trino](https://trino.io/blog/2023/04/11/date-predicates.html).