DateTime documentation improvements, added DateTime64 doc (#9562)

* Added DateTime64 docs, added info on DateTime timezone conversion, added ClickHouse.Client to list of ADO.NET clients

* I accidentally a word

* Review notes

* Fix space per review notes
Co-Authored-By: NIvan Blinkov <github@blinkov.ru>

* More review notes: fixed wrong notes on DateTime, added more extensive info on automatic type conversion

* Minor tweaks

* Review notes: missing `code` markers

* Formatting fix

* Silence PR check

* fix typo

* fix typos

* fix typos

* removed meaningless sentence.

* TZ new description

* Update datetime.md

* Update datetime.md

* Update datetime.md

* Update datetime.md

* Update datetime64.md

* Update datetime64.md

* Update datetime64.md

* Update datetime64.md
Co-authored-by: NDarkWanderer <elquentaro@gmail.com>
Co-authored-by: NIvan Blinkov <github@blinkov.ru>
Co-authored-by: NDenis Zhuravlev <denis.zhuravlev@revjet.com>

docs/en/data_types/datetime.md

 # DateTime {#data_type-datetime}
 
-Allows to store an instant in time, that can be expressed as a calendar date and a time of a day. `DateTime` allows to take into account time zones for stored values.
+Allows to store an instant in time, that can be expressed as a calendar date and a time of a day.
 
 Syntax:
 
@@ -12,21 +12,17 @@ Supported range of values: [1970-01-01 00:00:00, 2105-12-31 23:59:59].
 
 Resolution: 1 second.
 
-SELECT toDateTime(0)
-FORMAT TSV
-
-0000-00-00 00:00:00
-
-
 ## Usage Remarks
 
-A moment of time is stored as [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time), independently of time zones and daylight savings. Additionally `DateTime` can store time zone, that affects how `DateTime` values are displayed in text format and how input strings are parsed for storage. The `tzdata` package, containing [IANA Time Zone Database](https://www.iana.org/time-zones), should be installed in the system. Use the `timedatectl list-timezones` command to list timezones known by a local system.
+The point in time is saved as a [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time), regardless of the time zone or daylight saving time. Additionally, the `DateTime` type can store time zone that is the same for the entire column, that affects how the values of the `DateTime` type values are displayed in text format and how the values specified as strings are parsed ('2020-01-01 05:00:01'). The time zone is not stored in the rows of the table (or in resultset), but is stored in the column metadata. 
+A list of supported time zones can be found in the [IANA Time Zone Database](https://www.iana.org/time-zones).
+The `tzdata` package, containing [IANA Time Zone Database](https://www.iana.org/time-zones), should be installed in the system. Use the `timedatectl list-timezones` command to list timezones known by a local system.
 
 You can explicitly set a time zone for `DateTime`-type columns when creating a table. If the time zone isn't set, ClickHouse uses the value of the [timezone](../operations/server_settings/settings.md#server_settings-timezone) parameter in the server settings or the operating system settings at the moment of the ClickHouse server start.
 
 The [clickhouse-client](../interfaces/cli.md) applies the server time zone by default if a time zone isn't explicitly set when initializing the data type. To use the client time zone, run `clickhouse-client` with the `--use_client_time_zone` parameter.
 
-ClickHouse outputs values in `YYYY-MM-DD hh:mm:ss` text format by default. You can change the format with the [formatDateTime](../query_language/functions/date_time_functions.md#formatdatetime) function.
+ClickHouse outputs values in `YYYY-MM-DD hh:mm:ss` text format by default. You can change the output with the [formatDateTime](../query_language/functions/date_time_functions.md#formatdatetime) function.
 
 When inserting data into ClickHouse, you can use different formats of date and time strings, depending on the value of the [date_time_input_format](../operations/settings/settings.md#settings-date_time_input_format) setting.
 
@@ -40,13 +36,13 @@ CREATE TABLE dt
     `timestamp` DateTime('Europe/Moscow'), 
     `event_id` UInt8
 )
-ENGINE = TinyLog
+ENGINE = TinyLog;
 ```
 ```sql
-INSERT INTO dt Values (1546300800, 1), ('2019-01-01 00:00:00', 2)
+INSERT INTO dt Values (1546300800, 1), ('2019-01-01 00:00:00', 2);
 ```
 ```sql
-SELECT * FROM dt
+SELECT * FROM dt;
 ```
 ```text
 ┌───────────timestamp─┬─event_id─┐
@@ -55,7 +51,10 @@ SELECT * FROM dt
 └─────────────────────┴──────────┘
 ```
 
-Unix timestamp `1546300800` represents the `'2019-01-01 00:00:00'` date and time in `Europe/London` (UTC+0) time zone, but the `timestamp` column stores values in the `Europe/Moscow` (UTC+3) timezone, so the value inserted as Unix timestamp is formatted as `2019-01-01 03:00:00`.
+* When inserting datetime as an integer, it is treated as Unix Timestamp (UTC). `1546300800` represents `'2019-01-01 00:00:00'` UTC. However, as `timestamp` column has `Europe/Moscow` (UTC+3) timezone specified, when outputting as string the value will be shown as `'2019-01-01 03:00:00'`
+* When inserting string value as datetime, it is treated as being in column timezone. `'2019-01-01 00:00:00'` will be treated as being in `Europe/Moscow` timezone and saved as `1546290000`.
+
+**2.** Filtering on `DateTime` values
 
 ```sql
 SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Europe/Moscow')
@@ -65,8 +64,17 @@ SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Europe/Mos
 │ 2019-01-01 00:00:00 │        2 │
 └─────────────────────┴──────────┘
 ```
+`DateTime` column values can be filtered using a string value in `WHERE` predicate. It will be converted to `DateTime` automatically:
+```sql
+SELECT * FROM dt WHERE timestamp = '2019-01-01 00:00:00'
+```
+```text
+┌───────────timestamp─┬─event_id─┐
+│ 2019-01-01 03:00:00 │        1 │
+└─────────────────────┴──────────┘
+```
 
-**2.** Getting a time zone for a `DateTime`-type value:
+**3.** Getting a time zone for a `DateTime`-type column:
 
 ```sql
 SELECT toDateTime(now(), 'Europe/Moscow') AS column, toTypeName(column) AS x
@@ -77,6 +85,21 @@ SELECT toDateTime(now(), 'Europe/Moscow') AS column, toTypeName(column) AS x
 └─────────────────────┴───────────────────────────┘
 ```
 
+**4.** Timezone conversion
+
+```sql
+SELECT 
+toDateTime(timestamp, 'Europe/London') as lon_time, 
+toDateTime(timestamp, 'Europe/Moscow') as mos_time
+FROM dt
+```
+```text
+┌───────────lon_time──┬────────────mos_time─┐
+│ 2019-01-01 00:00:00 │ 2019-01-01 03:00:00 │
+│ 2018-12-31 21:00:00 │ 2019-01-01 00:00:00 │
+└─────────────────────┴─────────────────────┘
+```
+
 ## See Also
 
 - [Type conversion functions](../query_language/functions/type_conversion_functions.md)

docs/en/data_types/datetime64.md

+# DateTime64 {#data_type-datetime64}
+
+Allows to store an instant in time, that can be expressed as a calendar date and a time of a day, with defined sub-second precision
+
+Tick size (precision): 10<sup>-precision</sup> seconds
+
+Syntax:
+```sql
+DateTime64(precision, [timezone])
+```
+
+Internally, stores data as number of 'ticks' since epoch start (1970-01-01 00:00:00 UTC) as Int64. The tick resolution is determined by the precision parameter. Additionally, the `DateTime64` type can store time zone that is the same for the entire column, that affects how the values of the `DateTime64` type values are displayed in text format and how the values specified as strings are parsed ('2020-01-01 05:00:01.000'). The time zone is not stored in the rows of the table (or in resultset), but is stored in the column metadata. See details in [DateTime](datetime.md).
+
+## Examples
+
+**1.** Creating a table with `DateTime64`-type column and inserting data into it:
+
+```sql
+CREATE TABLE dt
+(
+    `timestamp` DateTime64(3, 'Europe/Moscow'), 
+    `event_id` UInt8
+)
+ENGINE = TinyLog
+```
+```sql
+INSERT INTO dt Values (1546300800000, 1), ('2019-01-01 00:00:00', 2)
+```
+```sql
+SELECT * FROM dt
+```
+```text
+┌───────────────timestamp─┬─event_id─┐
+│ 2019-01-01 03:00:00.000 │        1 │
+│ 2019-01-01 00:00:00.000 │        2 │
+└─────────────────────────┴──────────┘
+```
+
+* When inserting datetime as an integer, it is treated as an appropriately scaled Unix Timestamp (UTC). `1546300800000` (with precision 3) represents `'2019-01-01 00:00:00'` UTC. However, as `timestamp` column has `Europe/Moscow` (UTC+3) timezone specified, when outputting as string the value will be shown as `'2019-01-01 03:00:00'`
+* When inserting string value as datetime, it is treated as being in column timezone. `'2019-01-01 00:00:00'` will be treated as being in `Europe/Moscow` timezone and stored as `1546290000000`.
+
+**2.** Filtering on `DateTime64` values
+
+```sql
+SELECT * FROM dt WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Europe/Moscow')
+```
+```text
+┌───────────────timestamp─┬─event_id─┐
+│ 2019-01-01 00:00:00.000 │        2 │
+└─────────────────────────┴──────────┘
+```
+Unlike `DateTime`, `DateTime64` values are not converted from `String` automatically
+
+**3.** Getting a time zone for a `DateTime64`-type value:
+
+```sql
+SELECT toDateTime64(now(), 3, 'Europe/Moscow') AS column, toTypeName(column) AS x
+```
+```text
+┌──────────────────column─┬─x──────────────────────────────┐
+│ 2019-10-16 04:12:04.000 │ DateTime64(3, 'Europe/Moscow') │
+└─────────────────────────┴────────────────────────────────┘
+```
+
+**4.** Timezone conversion 
+
+```sql
+SELECT 
+toDateTime64(timestamp, 3, 'Europe/London') as lon_time, 
+toDateTime64(timestamp, 3, 'Europe/Moscow') as mos_time
+FROM dt
+```
+```text
+┌───────────────lon_time──┬────────────────mos_time─┐
+│ 2019-01-01 00:00:00.000 │ 2019-01-01 03:00:00.000 │
+│ 2018-12-31 21:00:00.000 │ 2019-01-01 00:00:00.000 │
+└─────────────────────────┴─────────────────────────┘
+```
+
+## See Also
+
+- [Type conversion functions](../query_language/functions/type_conversion_functions.md)
+- [Functions for working with dates and times](../query_language/functions/date_time_functions.md)
+- [Functions for working with arrays](../query_language/functions/array_functions.md)
+- [The `date_time_input_format` setting](../operations/settings/settings.md#settings-date_time_input_format)
+- [The `timezone` server configuration parameter](../operations/server_settings/settings.md#server_settings-timezone)
+- [Operators for working with dates and times](../query_language/operators.md#operators-datetime)
+- [`Date` data type](date.md)
+- [`DateTime` data type](datetime.md)

docs/en/interfaces/third-party/client_libraries.md

@@ -40,8 +40,8 @@
     - [AORM](https://github.com/TanVD/AORM)
 - C#
     - [ClickHouse.Ado](https://github.com/killwort/ClickHouse-Net)
-    - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
     - [ClickHouse.Client](https://github.com/DarkWanderer/ClickHouse.Client)
+    - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
 - Elixir
     - [clickhousex](https://github.com/appodeal/clickhousex/)
 - Nim

docs/en/interfaces/third-party/integrations.md

@@ -78,6 +78,7 @@
 - C#
     - [ADO.NET](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview)
         - [ClickHouse.Ado](https://github.com/killwort/ClickHouse-Net)
+        - [ClickHouse.Client](https://github.com/DarkWanderer/ClickHouse.Client)
         - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
         - [ClickHouse.Net.Migrations](https://github.com/ilyabreev/ClickHouse.Net.Migrations)
 - Elixir

docs/ru/data_types/datetime.md

 # DateTime {#data_type-datetime}
 
-Позволяет хранить момент времени, который может быть представлен как календарная дата и время. `DateTime` позволяет учесть часовой пояс для хранимых значений.
+Позволяет хранить момент времени, который может быть представлен как календарная дата и время.
 
 Синтаксис:
 
@@ -14,13 +14,15 @@ DateTime([timezone])
 
 ## Использование
 
-Момент времени сохраняется как Unix timestamp, независимо от часового пояса и переходов на летнее/зимнее время. Дополнительно, `DateTime` позволяет хранить часовой пояс, который влияет на то, как буду отображаться значения типа `DateTime` в текстовом виде и как будут парситься входные строки. Список поддержанных временных зон можно найти в [IANA Time Zone Database](https://www.iana.org/time-zones).
+Момент времени сохраняется как [Unix timestamp](https://ru.wikipedia.org/wiki/Unix-%D0%B2%D1%80%D0%B5%D0%BC%D1%8F), независимо от часового пояса и переходов на летнее/зимнее время. Дополнительно, тип `DateTime` позволяет хранить часовой пояс, единый для всей колонки, который влияет на то, как будут отображаться значения типа `DateTime` в текстовом виде и как будут парситься значения заданные в виде строк ('2020-01-01 05:00:01'). Часовой пояс не хранится в строках таблицы (выборки), а хранится в метаданных колонки. 
+Список поддерживаемых временных зон можно найти в [IANA Time Zone Database](https://www.iana.org/time-zones).
+Пакет `tzdata`, содержащий [базу данных часовых поясов IANA](https://www.iana.org/time-zones), должен быть установлен в системе. Используйте команду `timedatectl list-timezones` для получения списка часовых поясов, известных локальной системе.
 
 Часовой пояс для столбца типа `DateTime` можно в явном виде установить при создании таблицы. Если часовой пояс не установлен, то ClickHouse использует значение параметра [timezone](../operations/server_settings/settings.md#server_settings-timezone), установленное в конфигурации сервера или в настройках операционной системы на момент запуска сервера.
 
 Консольный клиент ClickHouse по умолчанию использует часовой пояс сервера, если для значения `DateTime` часовой пояс не был задан в явном виде при инициализации типа данных. Чтобы использовать часовой пояс клиента, запустите [clickhouse-client](../interfaces/cli.md) с параметром `--use_client_time_zone`.
 
-ClickHouse по умолчанию выводит значение в формате `YYYY-MM-DD hh:mm:ss`. Формат можно поменять с помощь функции [formatDateTime](../query_language/functions/date_time_functions.md#formatdatetime).
+ClickHouse отображает значения типа `DateTime` в формате `YYYY-MM-DD hh:mm:ss`. Отображение можно поменять с помощью функции [formatDateTime](../query_language/functions/date_time_functions.md#formatdatetime).
 
 При вставке данных в ClickHouse, можно использовать различные форматы даты и времени в зависимости от значения настройки [date_time_input_format](../operations/settings/settings.md#settings-date_time_input_format).
 
@@ -28,18 +30,19 @@ ClickHouse по умолчанию выводит значение в форма
 
 **1.** Создание таблицы с столбцом типа `DateTime` и вставка данных в неё:
 
+```sql
 CREATE TABLE dt
 (
     `timestamp` DateTime('Europe/Moscow'), 
     `event_id` UInt8
 )
-ENGINE = TinyLog
+ENGINE = TinyLog;
 ```
 ```sql
-INSERT INTO dt Values (1546300800, 1), ('2019-01-01 00:00:00', 2)
+INSERT INTO dt Values (1546300800, 1), ('2019-01-01 00:00:00', 2);
 ```
 ```sql
-SELECT * FROM dt
+SELECT * FROM dt;
 ```
 ```text
 ┌───────────timestamp─┬─event_id─┐
@@ -48,7 +51,10 @@ SELECT * FROM dt
 └─────────────────────┴──────────┘
 ```
 
-Unix timestamp `1546300800` в часовом поясе `Europe/London (UTC+0)` представляет время `'2019-01-01 00:00:00'`, однако столбец `timestamp` хранит время в часовом поясе `Europe/Moscow (UTC+3)`, таким образом значение, вставленное в виде Unix timestamp, представляет время `2019-01-01 03:00:00`.
+* При вставке даты-времени как целого числа, оно трактуется как Unix Timestamp (UTC). Unix timestamp `1546300800` в часовом поясе `Europe/London (UTC+0)` представляет время `'2019-01-01 00:00:00'`. Однако, столбец `timestamp` имеет тип `DateTime('Europe/Moscow (UTC+3)')`, так что при выводе в виде строки время отобразится как `2019-01-01 03:00:00`.
+* При вставке даты-времени в виде строки, время трактуется соответственно часовому поясу установленному для колонки. `'2019-01-01 00:00:00'` трактуется как время по Москве (и в базу сохраняется `1546290000`)
+
+**2.** Фильтрация по значениям даты-времени
 
 ```sql
 SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Europe/Moscow')
@@ -58,8 +64,17 @@ SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Europe/Mos
 │ 2019-01-01 00:00:00 │        2 │
 └─────────────────────┴──────────┘
 ```
+Фильтровать по колонке типа `DateTime` можно, указывая строковое значение в фильтре `WHERE`. Конвертация будет выполнена автоматически:
+```sql
+SELECT * FROM dt WHERE timestamp = '2019-01-01 00:00:00'
+```
+```text
+┌───────────timestamp─┬─event_id─┐
+│ 2019-01-01 03:00:00 │        1 │
+└─────────────────────┴──────────┘
+```
 
-**2.** Получение часового пояса для значения типа `DateTime`:
+**3.** Получение часового пояса для колонки типа `DateTime`:
 
 ```sql
 SELECT toDateTime(now(), 'Europe/Moscow') AS column, toTypeName(column) AS x
@@ -70,6 +85,21 @@ SELECT toDateTime(now(), 'Europe/Moscow') AS column, toTypeName(column) AS x
 └─────────────────────┴───────────────────────────┘
 ```
 
+**4.** Конвертация часовых поясов
+
+```sql
+SELECT 
+toDateTime(timestamp, 'Europe/London') as lon_time, 
+toDateTime(timestamp, 'Europe/Moscow') as mos_time
+FROM dt
+```
+```text
+┌───────────lon_time──┬────────────mos_time─┐
+│ 2019-01-01 00:00:00 │ 2019-01-01 03:00:00 │
+│ 2018-12-31 21:00:00 │ 2019-01-01 00:00:00 │
+└─────────────────────┴─────────────────────┘
+```
+
 ## See Also
 
 - [Функции преобразования типов](../query_language/functions/type_conversion_functions.md)

docs/ru/data_types/datetime64.md

+# DateTime64 {#data_type-datetime64}
+
+Позволяет хранить момент времени, который может быть представлен как календарная дата и время, с заданной суб-секундной точностью. 
+
+Размер тика/точность: 10<sup>-precision</sup> секунд, где precision - целочисленный параметр типа.
+
+Синтаксис:
+```sql
+DateTime64(precision, [timezone])
+```
+
+Данные хранятся в виде количества 'тиков', прошедших с момента начала эпохи (1970-01-01 00:00:00 UTC), в Int64. Размер тика определяется параметром precision. Дополнительно, тип `DateTime64` позволяет хранить часовой пояс, единый для всей колонки, который влияет на то, как будут отображаться значения типа `DateTime64` в текстовом виде и как будут парситься значения заданные в виде строк ('2020-01-01 05:00:01.000'). Часовой пояс не хранится в строках таблицы (выборки), а хранится в метаданных колонки. Подробнее см. [DateTime](datetime.md).
+
+## Пример
+
+**1.** Создание таблицы с столбцом типа `DateTime64` и вставка данных в неё:
+
+```sql
+CREATE TABLE dt
+(
+    `timestamp` DateTime64(3, 'Europe/Moscow'), 
+    `event_id` UInt8
+)
+ENGINE = TinyLog
+```
+```sql
+INSERT INTO dt Values (1546300800000, 1), ('2019-01-01 00:00:00', 2)
+```
+```sql
+SELECT * FROM dt
+```
+```text
+┌───────────────timestamp─┬─event_id─┐
+│ 2019-01-01 03:00:00.000 │        1 │
+│ 2019-01-01 00:00:00.000 │        2 │
+└─────────────────────────┴──────────┘
+```
+
+* При вставке даты-времени как числа (аналогично 'Unix timestamp'), время трактуется как UTC. Unix timestamp `1546300800` в часовом поясе `Europe/London (UTC+0)` представляет время `'2019-01-01 00:00:00'`. Однако, столбец `timestamp` имеет тип `DateTime('Europe/Moscow (UTC+3)')`, так что при выводе в виде строки время отобразится как `2019-01-01 03:00:00`.
+* При вставке даты-времени в виде строки, время трактуется соответственно часовому поясу установленному для колонки. `'2019-01-01 00:00:00'` трактуется как время по Москве (и в базу сохраняется `'2018-12-31 21:00:00'` в виде Unix Timestamp)
+
+**2.** Фильтрация по значениям даты-времени
+
+```sql
+SELECT * FROM dt WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Europe/Moscow')
+```
+```text
+┌───────────────timestamp─┬─event_id─┐
+│ 2019-01-01 00:00:00.000 │        2 │
+└─────────────────────────┴──────────┘
+```
+В отличие от типа `DateTime`, `DateTime64` не конвертируется из строк автоматически
+
+**3.** Получение часового пояса для значения типа `DateTime64`:
+
+```sql
+SELECT toDateTime64(now(), 3, 'Europe/Moscow') AS column, toTypeName(column) AS x
+```
+```text
+┌──────────────────column─┬─x──────────────────────────────┐
+│ 2019-10-16 04:12:04.000 │ DateTime64(3, 'Europe/Moscow') │
+└─────────────────────────┴────────────────────────────────┘
+```
+
+**4.** Конвертация часовых поясов
+
+```sql
+SELECT 
+toDateTime64(timestamp, 3, 'Europe/London') as lon_time, 
+toDateTime64(timestamp, 3, 'Europe/Moscow') as mos_time
+FROM dt
+```
+```text
+┌───────────────lon_time──┬────────────────mos_time─┐
+│ 2019-01-01 00:00:00.000 │ 2019-01-01 03:00:00.000 │
+│ 2018-12-31 21:00:00.000 │ 2019-01-01 00:00:00.000 │
+└─────────────────────────┴─────────────────────────┘
+```
+
+## See Also
+
+- [Функции преобразования типов](../query_language/functions/type_conversion_functions.md)
+- [Функции для работы с датой и временем](../query_language/functions/date_time_functions.md)
+- [Функции для работы с массивами](../query_language/functions/array_functions.md)
+- [Настройка `date_time_input_format`](../operations/settings/settings.md#settings-date_time_input_format)
+- [Конфигурационный параметр сервера `timezone`](../operations/server_settings/settings.md#server_settings-timezone)
+- [Операторы для работы с датой и временем](../query_language/operators.md#operators-datetime)
+- [Тип данных `Date`](date.md)
+- [Тип данных `DateTime`](datetime.md)
+

docs/ru/interfaces/third-party/client_libraries.md

@@ -38,8 +38,8 @@
     - [AORM](https://github.com/TanVD/AORM)
 - C#
     - [ClickHouse.Ado](https://github.com/killwort/ClickHouse-Net)
-    - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
     - [ClickHouse.Client](https://github.com/DarkWanderer/ClickHouse.Client)
+    - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
 - Elixir
     - [clickhousex](https://github.com/appodeal/clickhousex/)
 - Nim

docs/ru/interfaces/third-party/integrations.md

@@ -77,6 +77,7 @@
 - C#
     - [ADO.NET](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview)
         - [ClickHouse.Ado](https://github.com/killwort/ClickHouse-Net)
+        - [ClickHouse.Client](https://github.com/DarkWanderer/ClickHouse.Client)
         - [ClickHouse.Net](https://github.com/ilyabreev/ClickHouse.Net)
         - [ClickHouse.Net.Migrations](https://github.com/ilyabreev/ClickHouse.Net.Migrations)
 - Elixir