Date는 날짜가 아니다: 타임존 실수를 막는 기준 정리

Date 타입은 왜 날짜가 아니라고 하나요?

Date는 특정 날짜가 아니라 UTC 기준의 "순간(instant)"을 의미한다. 같은 Date라도 해석하는 타임존에 따라 날짜가 달라질 수 있다.

const date: Date = new Date();
------------------------------
const a: Date = new Date();                      // 현재 시각
const b: Date = new Date('2026-01-01');          // UTC 자정
const c: Date = new Date('2026-01-01T00:00+09'); // KST 자정
// a, b, c 모두 Date 타입

Date 타입 하나로 해결되지 않는 문제는 무엇인가요?

Date 타입 하나로는 아래 구분을 안전하게 표현할 수 없다.

• 날짜만인지, 시간만인지, 둘 다인지
• UTC 기준인지, KST 기준인지
• 서버 기준인지, 사용자 기준인지

기준(UTC/KST/ISO 8601)을 어떻게 정해야 하나요?

2026-01-01T00:00:00Z
2026-01-01T00:00:00+09:00  // KST
2026-01-01T00:00:00-08:00  // PST

new Date()는 어디 기준인가요?

new Date()는 현재 시점의 UTC 타임스탬프를 생성한다. 다만 문자열로 변환하면 로컬 타임존으로 표시된다.

const d = new Date();
d.toString();     // 로컬(KST)로 표시
d.toISOString();  // UTC로 표시

toString()은 표현만 바꾸고 내부 UTC 타임스탬프는 그대로 유지한다.

문자열로 Date를 만들면 안전한가요?

문법적으로는 안전해 보이지만, 의도하지 않은 시간 값이 생성될 수 있다. 특히 "날짜만" 원했는데 UTC 기준으로 해석되면 하루가 밀리는 문제가 발생한다.

// 원했던 값: 2026-01-01 00:00 (KST)
const date = new Date('2026-01-01');
const key = date.toISOString().split('T')[0];

KST 자정을 UTC로 변환하면 전날로 바뀌고, 다시 KST로 해석하면 하루가 밀린 것처럼 보인다.

실수 사례: 왜 하루가 밀렸나요?

호스트는 KST 기준으로 예약을 만들고, 게스트는 로컬 타임존으로 해석한다는 가정이 깨졌다. 저장은 UTC로, 표시는 KST로 변환해야 하는데 이를 생략하면서 하루가 밀렸다.

결론

1. Date는 날짜가 아니라 "순간"이다.
2. API 저장은 UTC, 표시 단계는 사용자 타임존 변환이 기본이다.
3. 날짜만 필요하면 문자열로 분리해서 관리한다.
4. Timezone 값을 명시해 변환 기준을 통일한다.

서머타임은 어떻게 처리해야 하나요?

DST는 하루가 24시간이라는 기준을 깨뜨린다. 직접 계산하기보다 UTC로 저장한 뒤 타임존 정보를 통해 표시 단계에서 변환하는 방식이 가장 안전하다.

세 줄 요약

• Date는 날짜가 아니다.
• Date는 UTC 기준의 "순간"이다.
• 날짜는 그 순간을 어떻게 해석하느냐의 문제다.

자주 묻는 질문 (FAQ)

관련 글

같은 주제를 다룬 글을 추가로 준비 중이다.

• 타임존 기준을 설계하는 체크리스트 (준비 중)
• 캘린더 서비스에서 발생하는 날짜 버그 모음 (준비 중)