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 |
---|