서머타임이 프로그래밍 악몽인 이유
서머타임은 소프트웨어 개발에서 가장 오류가 발생하기 쉬운 영역 중 하나로 여겨집니다. 이유는 다양합니다. DST 규칙은 자주 바뀌고, 다른 국가들이 서로 다른 날짜에 전환하며, 전환 시 모호하고 존재하지 않는 시간이 생기고, 엣지 케이스가 넘쳐납니다. 프로그래머들 사이에는 악명 높은 말이 있습니다: "시간대는 거짓말이다."
기본 규칙: UTC로 저장, 로컬로 표시
소프트웨어에서 시간을 처리하는 가장 중요한 원칙은:
- 모든 타임스탬프를 UTC로 저장하세요. UTC는 서머타임이 없습니다. 변하지 않습니다. 모호하지 않습니다.
- 표시할 때만 현지 시간으로 변환하세요. 렌더링 시 사용자의 시간대와 현재 DST 규칙을 사용해 UTC를 현지 시간으로 변환합니다.
모호한 시간과 존재하지 않는 시간
DST 전환 중 두 가지 특수한 경우가 발생합니다:
- 존재하지 않는 시간 (봄 전환): 시계가 오전 2시에서 오전 3시로 앞당겨질 때, 오전 2:00~2:59는 존재하지 않습니다. 모든 현지 시간이 유효하다고 가정하는 코드는 여기서 실패합니다.
- 모호한 시간 (가을 전환): 시계가 오전 2시에서 오전 1시로 돌아갈 때, 오전 1:00~1:59는 두 번 발생합니다. 그날 "오전 1:30"이라는 타임스탬프는 첫 번째인지 두 번째인지 모르면 모호합니다.
IANA 시간대 데이터베이스 사용
앱에 "UTC+5"나 "EST" 같은 UTC 오프셋을 하드코딩하지 마세요. 대신 America/New_York이나 Europe/London 같은 IANA 시간대 식별자를 사용하세요. 이 식별자들은 모든 지역의 과거 및 현재 DST 규칙을 포함한 포괄적인 IANA 시간대 데이터베이스(Olson 데이터베이스라고도 함)를 참조합니다. 대부분의 프로그래밍 언어에는 이 데이터베이스를 사용하는 라이브러리가 있습니다:
- Python:
zoneinfo(표준 라이브러리, Python 3.9+) 또는pytz - JavaScript:
Intl.DateTimeFormat(네이티브) 또는date-fns-tz - Java:
java.time.ZoneId - Go:
time.LoadLocation
시간대 데이터 최신화 유지
DST 규칙은 정기적으로 변경됩니다. 때로는 불과 몇 주 전에 통보가 오기도 합니다. 국가들이 규칙을 업데이트하고, 전환 날짜를 변경하고, 서머타임을 완전히 폐지합니다. OS 및 라이브러리 업데이트와 함께 시간대 데이터베이스가 업데이트되도록 확인하세요. OS 시간대 패키지가 오래된 경우 서버 환경이 특히 취약합니다.
흔한 함정
- 반복 이벤트를 "매일 오전 2:00"에 예약하기 — 봄 전환 중에는 이 시간이 존재하지 않을 수 있습니다.
- 적절한 날짜/시간 라이브러리 대신 단순 산술로 DST 경계를 넘어 시간 차이를 계산하기.
- UTC를 통해 왕복하지 않고 사용자가 입력한 현지 시간을 표시하기.
- 모든 날이 24시간이라고 가정하기 — DST 날은 23시간 또는 25시간입니다.
- 컨테이너화되거나 다중 지역 배포에서 시간대 정보를 위해 시스템 시계에 의존하기.