> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8a08bda2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 달력 날짜와 하루 중 시간으로 표현할 수 있는 시점을 초 단위 정밀도의 timestamp로 저장하는 ClickHouse의 DateTime 데이터 타입 문서

# DateTime

달력 날짜와 하루 중 시간으로 표현할 수 있는 특정 시점을 저장할 수 있습니다.

구문:

```sql theme={null}
DateTime([timezone])
```

지원되는 값의 범위: \[1970-01-01 00:00:00, 2106-02-07 06:28:15].

해상도: 1초.

<div id="speed">
  ## 속도
</div>

대부분의 상황에서 `Date` 데이터 타입은 `DateTime`보다 더 빠릅니다.

`Date` 데이터 타입은 저장 공간으로 2바이트가 필요하지만 `DateTime`은 4바이트가 필요합니다. 하지만 압축 시에는 `Date`와 `DateTime`의 크기 차이가 더 크게 벌어집니다. 이는 `DateTime`의 분과 초는 압축 효율이 낮기 때문입니다. 또한 `DateTime` 대신 `Date`에 필터링과 집계를 수행하는 것도 더 빠릅니다.

<div id="usage-remarks">
  ## 사용 시 유의사항
</div>

시점은 시간대나 일광 절약 시간제와 관계없이 [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time)로 저장됩니다. 시간대는 `DateTime` 타입 값이 텍스트 포맷으로 표시되는 방식과 문자열로 지정된 값('2020-01-01 05:00:01')이 파싱되는 방식에 영향을 줍니다.

시간대와 무관한 Unix timestamp가 테이블에 저장되며, 시간대는 데이터 가져오기/내보내기 시 이를 텍스트 포맷으로 변환하거나 다시 되돌리는 데 사용됩니다. 또한 값에 대해 달력 계산을 수행할 때도 사용됩니다(예: `toDate`, `toHour` 함수 등). 시간대는 테이블의 행(또는 결과 집합)에는 저장되지 않지만, 컬럼 메타데이터에는 저장됩니다.

지원되는 시간대 목록은 [IANA Time Zone Database](https://www.iana.org/time-zones)에서 확인할 수 있으며, `SELECT * FROM system.time_zones`로도 조회할 수 있습니다. [이 목록](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)은 Wikipedia에서도 제공됩니다.

테이블을 생성할 때 `DateTime` 타입 컬럼에 시간대를 명시적으로 설정할 수 있습니다. 예시: `DateTime('UTC')`. 시간대가 설정되지 않으면 ClickHouse는 서버 설정의 [timezone](/ko/reference/settings/server-settings/settings#timezone) 매개변수 값 또는 ClickHouse 서버가 시작될 당시의 운영 체제 설정을 사용합니다.

[clickhouse-client](/ko/concepts/features/interfaces/client)는 데이터 타입을 초기화할 때 시간대가 명시적으로 설정되지 않으면 기본적으로 서버 시간대를 적용합니다. 클라이언트 시간대를 사용하려면 `--use_client_time_zone` 매개변수와 함께 `clickhouse-client`를 실행하세요.

ClickHouse는 [date\_time\_output\_format](/ko/reference/settings/formats#date_time_output_format) 설정 값에 따라 값을 출력합니다. 기본 텍스트 포맷은 `YYYY-MM-DD hh:mm:ss`입니다. 또한 [formatDateTime](/ko/reference/functions/regular-functions/date-time-functions#formatDateTime) 함수를 사용해 출력 형식을 변경할 수 있습니다.

ClickHouse에 데이터를 삽입할 때는 [date\_time\_input\_format](/ko/reference/settings/formats#date_time_input_format) 설정 값에 따라 다양한 날짜 및 시간 문자열 포맷을 사용할 수 있습니다.

<div id="examples">
  ## 예시
</div>

**1.** `DateTime` 타입의 컬럼이 있는 테이블을 생성하고 데이터를 삽입하는 예시:

```sql theme={null}
CREATE TABLE dt
(
    `timestamp` DateTime('Asia/Istanbul'),
    `event_id` UInt8
)
ENGINE = TinyLog;
```

```sql theme={null}
-- DateTime 파싱
-- - 문자열로부터,
-- - 1970-01-01 이후 경과한 초(seconds) 수를 나타내는 정수로부터.
INSERT INTO dt VALUES ('2019-01-01 00:00:00', 1), (1546300800, 2);

SELECT * FROM dt;
```

```text theme={null}
┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
│ 2019-01-01 03:00:00 │        2 │
└─────────────────────┴──────────┘
```

* datetime를 정수로 삽입하면 Unix Timestamp(UTC)로 처리됩니다. `1546300800`은 UTC 기준 `'2019-01-01 00:00:00'`을 나타냅니다. 하지만 `timestamp` 컬럼에 `Asia/Istanbul` (UTC+3) 시간대가 지정되어 있으므로, 문자열로 출력하면 값이 `'2019-01-01 03:00:00'`으로 표시됩니다.
* 문자열 값을 datetime로 삽입하면 컬럼의 시간대로 처리됩니다. `'2019-01-01 00:00:00'`은 `Asia/Istanbul` 시간대로 간주되어 `1546290000`으로 저장됩니다.

**2.** `DateTime` 값 필터링

```sql theme={null}
SELECT * FROM dt WHERE timestamp = toDateTime('2019-01-01 00:00:00', 'Asia/Istanbul')
```

```text theme={null}
┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
└─────────────────────┴──────────┘
```

`DateTime` 컬럼 값은 `WHERE` 프레디케이트에서 문자열 값으로 필터링할 수 있습니다. 이 값은 자동으로 `DateTime`으로 변환됩니다:

```sql theme={null}
SELECT * FROM dt WHERE timestamp = '2019-01-01 00:00:00'
```

```text theme={null}
┌───────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00 │        1 │
└─────────────────────┴──────────┘
```

**3.** `DateTime` 타입 컬럼의 시간대 확인하기:

```sql theme={null}
SELECT toDateTime(now(), 'Asia/Istanbul') AS column, toTypeName(column) AS x
```

```text theme={null}
┌──────────────column─┬─x─────────────────────────┐
│ 2019-10-16 04:12:04 │ DateTime('Asia/Istanbul') │
└─────────────────────┴───────────────────────────┘
```

**4.** 시간대 변환

```sql theme={null}
SELECT
toDateTime(timestamp, 'Europe/London') AS lon_time,
toDateTime(timestamp, 'Asia/Istanbul') AS istanbul_time
FROM dt
```

```text theme={null}
┌───────────lon_time──┬───────istanbul_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 │
└─────────────────────┴─────────────────────┘
```

시간대 변환은 메타데이터만 변경하므로 연산 비용이 발생하지 않습니다.

<div id="limitations-on-time-zones-support">
  ## 시간대 지원의 제한 사항
</div>

일부 시간대는 완전히 지원되지 않을 수 있습니다. 대표적인 경우는 다음과 같습니다.

UTC와의 오프셋이 15분의 배수가 아니면 시와 분 계산이 부정확할 수 있습니다. 예를 들어 라이베리아 몬로비아의 시간대는 1972년 1월 7일 이전에 UTC -0:44:30 오프셋을 사용했습니다. Monrovia 시간대의 과거 시각을 기준으로 계산을 수행하면 시간 처리 함수가 잘못된 결과를 반환할 수 있습니다. 다만 1972년 1월 7일 이후의 결과는 정확합니다.

시간 전환(DST 또는 기타 이유로 인한 전환)이 15분의 배수가 아닌 시점에 이루어진 경우에도, 해당 날짜에는 잘못된 결과가 나올 수 있습니다.

달력 날짜가 단조롭게 증가하지 않는 경우도 있습니다. 예를 들어 Happy Valley - Goose Bay에서는 2010년 11월 7일 00:01:00에 시간이 1시간 뒤로 전환되었습니다(자정 1분 후). 따라서 11월 6일이 끝난 뒤 11월 7일이 1분 동안 진행되었고, 이후 시간이 다시 11월 6일 23:01로 돌아간 다음 59분이 더 지난 뒤 11월 7일이 다시 시작되었습니다. ClickHouse는 이런 종류의 상황을 (아직) 지원하지 않습니다. 이러한 날짜에는 시간 처리 함수의 결과가 약간 부정확할 수 있습니다.

2010년의 남극 Casey 관측소에도 비슷한 문제가 있었습니다. 이곳에서는 3월 5일 02:00에 시간을 3시간 뒤로 변경했습니다. 남극 관측소에서 작업하더라도 ClickHouse 사용을 걱정할 필요는 없습니다. 다만 시간대를 UTC로 설정하거나, 약간의 부정확성이 있을 수 있다는 점을 인지해야 합니다.

여러 날에 걸친 시간 이동도 있습니다. 일부 태평양 섬은 시간대 오프셋을 UTC+14에서 UTC-12로 변경했습니다. 이는 허용되는 경우이지만, 전환이 일어난 날짜의 과거 시점에 대해 해당 시간대로 계산을 수행하면 일부 부정확성이 발생할 수 있습니다.

<div id="handling-daylight-saving-time-dst">
  ## 일광 절약 시간제(DST) 처리
</div>

시간대가 지정된 ClickHouse의 DateTime 유형은 일광 절약 시간제(DST) 전환 시 예상치 못한 동작을 보일 수 있으며, 특히 다음과 같은 경우에 그렇습니다.

* [`date_time_output_format`](/ko/reference/settings/formats#date_time_output_format)이 `simple`로 설정된 경우
* 시계가 뒤로 이동("Fall Back")하여 1시간이 겹치는 경우
* 시계가 앞으로 이동("Spring Forward")하여 1시간의 공백이 생기는 경우

기본적으로 ClickHouse는 시간이 겹치는 경우 항상 더 이른 쪽을 선택하며, 시계가 앞으로 이동할 때는 실제로 존재하지 않는 시간을 해석할 수도 있습니다.

예를 들어, 다음과 같은 일광 절약 시간제(DST)에서 표준시로의 전환을 살펴보겠습니다.

* 2023년 10월 29일 02:00:00에 시계가 01:00:00으로 뒤로 이동합니다(BST → GMT).
* 01:00:00 – 01:59:59 구간이 두 번 나타납니다(BST에서 한 번, GMT에서 한 번).
* ClickHouse는 항상 첫 번째 시점(BST)을 선택하므로, 시간 인터벌을 추가할 때 예상치 못한 결과가 발생할 수 있습니다.

```sql theme={null}
SELECT '2023-10-29 01:30:00'::DateTime('Europe/London') AS time, time + toIntervalHour(1) AS one_hour_later

┌────────────────time─┬──────one_hour_later─┐
│ 2023-10-29 01:30:00 │ 2023-10-29 01:30:00 │
└─────────────────────┴─────────────────────┘
```

마찬가지로 표준시에서 일광 절약 시간으로 전환될 때는 1시간이 건너뛴 것처럼 보일 수 있습니다.

예시는 다음과 같습니다.

* 2023년 03월 26일 `00:59:59`에 시계가 02:00:00으로 앞당겨집니다(GMT → BST).
* `01:00:00` – `01:59:59` 시간대는 존재하지 않습니다.

```sql theme={null}
SELECT '2023-03-26 01:30:00'::DateTime('Europe/London') AS time, time + toIntervalHour(1) AS one_hour_later

┌────────────────time─┬──────one_hour_later─┐
│ 2023-03-26 00:30:00 │ 2023-03-26 02:30:00 │
└─────────────────────┴─────────────────────┘
```

이 경우 ClickHouse는 존재하지 않는 시각 `2023-03-26 01:30:00`을 `2023-03-26 00:30:00`으로 앞당깁니다.

<div id="see-also">
  ## 관련 항목
</div>

* [타입 변환 함수](/ko/reference/functions/regular-functions/type-conversion-functions)
* [날짜 및 시간을 처리하는 함수](/ko/reference/functions/regular-functions/date-time-functions)
* [배열을 처리하는 함수](/ko/reference/functions/regular-functions/array-functions)
* [`date_time_input_format` 설정](/ko/reference/settings/formats#date_time_input_format)
* [`date_time_output_format` 설정](/ko/reference/settings/formats#date_time_output_format)
* [`timezone` 서버 구성 매개변수](/ko/reference/settings/server-settings/settings#timezone)
* [`session_timezone` 설정](/ko/reference/settings/session-settings#session_timezone)
* [날짜 및 시간을 처리하는 연산자](/ko/reference/operators#operators-for-working-with-dates-and-times)
* [`Date` 데이터 타입](/ko/reference/data-types/date)