Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

DateTime64

View as MarkdownEdit this pageReport an issueSet up docs MCP

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 :

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.

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 :
CREATE TABLE dt64
(
    `timestamp` DateTime64(3, 'Asia/Istanbul'),
    `event_id` UInt8
)
ENGINE = MergeTree;
-- 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;
┌───────────────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.
  1. Filtrage sur les valeurs DateTime64
SELECT * FROM dt64 WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Asia/Istanbul');
┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00.000 │        3 │
└─────────────────────────┴──────────┘

Contrairement à DateTime, les valeurs DateTime64 ne sont pas automatiquement converties depuis String.

SELECT * FROM dt64 WHERE timestamp = toDateTime64(1546300800.123, 3);
┌───────────────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.

  1. Obtenir le fuseau horaire d’une valeur de type DateTime64 :
SELECT toDateTime64(now(), 3, 'Asia/Istanbul') AS column, toTypeName(column) AS x;
┌──────────────────column─┬─x──────────────────────────────┐
│ 2023-06-05 00:09:52.000 │ DateTime64(3, 'Asia/Istanbul') │
└─────────────────────────┴────────────────────────────────┘
  1. Conversion de fuseau horaire
SELECT
toDateTime64(timestamp, 3, 'Europe/London') AS lon_time,
toDateTime64(timestamp, 3, 'Asia/Istanbul') AS istanbul_time
FROM dt64;
┌────────────────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

Navigation