> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Documentation du type de données DateTime64 dans ClickHouse, qui stocke des horodatages avec une précision inférieure à la seconde # DateTime64 Permet de stocker un instant, pouvant être exprimé sous la forme d’une date calendaire et d’une heure de la journée, avec une précision inférieure à la seconde définie Taille du tick (précision) : 10-precision secondes. Plage valide : \[ 0 : 9 ]. Les valeurs généralement utilisées sont 3 (millisecondes), 6 (microsecondes) et 9 (nanosecondes). Valeur par défaut : 3 (millisecondes). **Syntaxe :** ```sql theme={null} DateTime64(precision, [timezone]) ``` En interne, les données sont stockées sous la forme d’un certain nombre de « ticks » depuis le début de l’epoch (1970-01-01 00:00:00 UTC), sous forme d’Int64. La résolution des ticks est déterminée par le paramètre precision. De plus, le type `DateTime64` peut stocker un fuseau horaire identique pour toute la colonne, ce qui affecte la façon dont les valeurs du type `DateTime64` sont affichées au format texte ainsi que la façon dont les valeurs spécifiées sous forme de chaînes sont interprétées ('2020-01-01 05:00:01.000'). Le fuseau horaire n’est pas stocké dans les lignes de la table (ou dans le resultset), mais dans les métadonnées de la colonne. Voir les détails dans [DateTime](/fr/reference/data-types/datetime). Plage de valeurs prise en charge : \[0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999] Le nombre de chiffres après le séparateur décimal dépend du paramètre precision. Remarque : la plage complète ci-dessus est disponible pour des précisions allant jusqu’à 7. Comme les ticks sont stockés dans un `Int64`, les précisions plus élevées couvrent une plage plus étroite : avec une précision de 8, la valeur maximale est d’environ `4892-10-07`, et avec la précision maximale de 9 chiffres (nanosecondes), la plage prise en charge va de `1677-09-21 00:12:44` à `2262-04-11 23:47:16` en UTC.
## Exemples
1. Création d’une table avec une colonne de type `DateTime64` et insertion de données dans cette table : ```sql theme={null} CREATE TABLE dt64 ( `timestamp` DateTime64(3, 'Asia/Istanbul'), `event_id` UInt8 ) ENGINE = MergeTree; ``` ```sql theme={null} -- Parse DateTime64 -- - from an integer interpreted as the number of seconds since 1970-01-01 (like DateTime), -- - from a decimal interpreted as the number of seconds, the fractional part giving sub-second precision, -- - from a string. INSERT INTO dt64 VALUES (1546300800, 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.000 │ 1 │ │ 2019-01-01 03:00:00.123 │ 2 │ │ 2019-01-01 00:00:00.000 │ 3 │ └─────────────────────────┴──────────┘ ``` * Lors de l’insertion d’une valeur datetime sous forme de nombre, elle est traitée comme un horodatage Unix (UTC) en secondes, comme `DateTime`. `1546300800` représente `'2019-01-01 00:00:00'` UTC. Cependant, comme la colonne `timestamp` utilise le fuseau horaire `Asia/Istanbul` (UTC+3), la valeur sera affichée sous forme de chaîne comme `'2019-01-01 03:00:00'`. L’insertion d’un nombre avec une partie fractionnaire fonctionne de la même manière : la partie avant le point décimal correspond à l’horodatage Unix en secondes et la partie après fournit une précision inférieure à la seconde selon la précision de la colonne. (Avant la version 26.8, un entier nu non entre guillemets dans les chemins d’entrée `JSON` et `Values`/`Quoted` — ce dernier couvrant tous les formats qui analysent les champs avec la règle d’échappement `Quoted` : `Values`, `MySQLDump` et `Template`/`CustomSeparated`/`Regexp` configurés avec l’échappement de champ `Quoted` — était plutôt interprété comme la valeur brute sous-jacente à la précision de la colonne, de sorte que `1546300800000` avec une précision de 3 signifiait `'2019-01-01 00:00:00'`. Pour restaurer le comportement précédent dans ces chemins, définissez `input_format_read_datetime_number_as_raw_value = 1` (ou `SET compatibility = '26.7'`) ; cela affecte également la fonction `JSONExtract` et le type de données `JSON`. Le paramètre de compatibilité ne régit qu’un entier nu : dans le format `Values`, un nombre fractionnaire, que le legacy streaming parser rejette, revient à l’évaluation d’une expression SQL et est lu en secondes — comme dans les versions antérieures à la 26.8. Dans `JSONExtract` et le type de données `JSON`, une valeur fractionnaire est analysée via `Float64`, de sorte qu’un horodatage dont le nombre de chiffres dépasse ce que `Float64` peut préserver peut être arrondi à la valeur adjacente, contrairement aux formats d’entrée de lignes qui analysent exactement le texte d’origine. Les formats d’entrée de texte séparé par des tabulations, CSV et les autres formats de texte avec échappement ne sont pas régis par ce paramètre et conservent leur interprétation existante d’un nombre non entre guillemets : une valeur élevée est lue comme des ticks.) * Lors de l’insertion d’une valeur de chaîne comme datetime, elle est considérée comme étant dans le fuseau horaire de la colonne. `'2019-01-01 00:00:00'` sera considéré comme appartenant au fuseau horaire `Asia/Istanbul` et stocké sous la forme `1546290000000`. 2. Filtrage sur les valeurs `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 │ └─────────────────────────┴──────────┘ ``` Contrairement à `DateTime`, les valeurs `DateTime64` ne sont pas automatiquement converties depuis `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 │ └─────────────────────────┴──────────┘ ``` Comme lors de l’insertion d’un nombre, la fonction `toDateTime64` traite un argument numérique comme un nombre de secondes. La précision inférieure à la seconde doit donc être indiquée après le point décimal. 3. Obtenir le fuseau horaire d’une valeur de type `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. Conversion de fuseau horaire ```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 │ └─────────────────────────┴─────────────────────────┘ ``` **Voir aussi** * [Fonctions de conversion de type](/fr/reference/functions/regular-functions/type-conversion-functions) * [Fonctions de manipulation des dates et heures](/fr/reference/functions/regular-functions/date-time-functions) * [Le paramètre `date_time_input_format`](/fr/reference/settings/formats/date-time#date_time_input_format) * [Le paramètre `date_time_output_format`](/fr/reference/settings/formats/date-time#date_time_output_format) * [Le paramètre de configuration du serveur `timezone`](/fr/reference/settings/server-settings/settings/other#timezone) * [Le paramètre `session_timezone`](/fr/reference/settings/session-settings/other#session_timezone) * [Opérateurs de manipulation des dates et heures](/fr/reference/operators/index#operators-for-working-with-dates-and-times) * [Type de données `Date`](/fr/reference/data-types/date) * [Type de données `DateTime`](/fr/reference/data-types/datetime)