반응형

MySQL의 시간 표현형식인 DATETIME, TIMESTAMP
두 표현형식에 대해서 알아보자

* 해당 글에서 말하는 local time이란 서버컴퓨터에 설정되어 있는 날짜 기준 시각을 의미

항목 TIMESTAMP DATETIME
용량 4바이트 8바이트
범위 1970-01-01 ~ 2038-01-19 1000-01-01 ~ 9999-12-31
시간대 영향 있음 (타임존 변환 자동 적용) 없음 (그대로 저장)
저장 방식 UNIX timestamp (초 단위) 구조화된 날짜/시간 필드
주의 사항 2038 문제, 시간대 혼동 가능 타임존 변환 로직 수동 구현 필요

TIMESTAMP

  • 저장 용량 : 4Byte
  • 저장 범위 : 1970-01-01 ~ 2038-01-19
  • 시간대 영향 : 서버 Timezone에 따라 변환
  • 내부 저장 방식 : UNIX 시간(초) 기반
  • 주의 사항 : 2038년 문제, timezone 혼동

특징

자동 시간대 관리

저장 : 시간 저장할 때 서버의 timezone → UTC로 변환되어 저장

조회 : 저장된 UTC → 현재 세션/서버의 timezone 기준으로 보여줌

장점

글로벌 서비스에서 사용자 시간대별로 시간 값을 표시할 때, TIMESTAMP는 자동으로 변환되므로 별도의 시간대 계산 로직 없이도 사용자에게 맞는 현지 시간을 보여줄 수 있다.

2038년 문제

TIMESTAMP는 4바이트 날짜 표현 데이터로써 초 단위로 저장하기에, 표현 가능한 범위가 -2147483548 ~ 2147483647이다. 해당 값의 최대값이 2038-01-19 03:14:07 UTC 이기에, 이후 시간 표현에 대해서 문제가 생긴다.

timezone 혼동

  • 서버로 요청하는 클라이언트의 local time이 변경되었을 경우

    • ex) 2025-05-05 10:00:00 → 2025-05-05 01:00:00

    • Asia/Seoul UTC +9* 타임존을 사용하고 있는 서버에서 서버의 TIMEZONE 설정을 UTC로 변경

      ⇒ 기존에 +9시간으로 나오던 시간이 +9가 안된 채로 보여줌

  • 같은 TIMESTAMP 값을 서로 다른 환경에서 비교할 때 오류

    • ex) A 서버 (Asia/Seoul)와 B 서버 (UTC)가 서로 TIMESTAMP 데이터를 주고받는 상황
    • A 서버 : 2025-05-05 12:00:00 UTC +9
    • B 서버 : 2025-05-05 03:00:00 UTC

DATETIME

  • 저장 용량 : 8Byte
  • 저장 범위 : 1000-01-01 ~ 9999-12-31
  • 시간대 영향 : 입력된 값 그대로 저장
  • 내부 저장 방식 : 구조화된 날짜.시간 필드
  • 주의 사항 : UTC 저장이 필요하면 직접 처리해야함

특징

8바이트 구조화된 방식으로 날짜·시간 정보를 별도 필드에 저장하며, 값 변환 없이 그대로 저장된다. 예: 9999-12-31과 같은 값도 안정적으로 표현 가능 (약 47비트 수준이지만 여유 있게 8바이트 확보)

장점

  • 서버 환경, 클라이언트 지역, 타임존 설정과 무관하게 항상 일정한 값 유지
  • TIMESTAMP와 다르게 8바이트의 넓은 범위 저장 가능
  • 타임존에 영향받지 않으며, 타임존 로직은 애플리케이션에서 명시적으로 제어 가능

기준 시간 지정 시 별도의 로직 필요

글로벌 서비스에서 DATETIME을 사용할 경우, 사용자 시간대에 맞게 표시하려면 애플리케이션에서 명시적인 기준 시간(예: UTC) 변환 로직이 필요하다.

반응형

'공부 > Database' 카테고리의 다른 글

RDBMS 쿼리 성능 개선 기초 ( 다수의 WHERE절 쿼리)  (0) 2024.07.24

+ Recent posts