타임존 하나 때문에 달라진 하루
이 글은 오늘 발생한 Unix 타임스탬프 변환 이슈를 기록하기 위한 것이다.
서버에서 받은 시간을 로컬 기준으로 보여주자는 결정에서 비롯된 여러 문제들이 있었다.
문제의 시발점(욕 아님)
결론부터 말하자면, 서버로부터 받은 timestamp를 로컬 기준으로 보여주자는 다소 애매한 결정과, 그에 따른 소통 부족이 문제의 시작이었다.
상황 정리
- 특정 페이지에서는 캘린더로 날짜 범위를 선택한 뒤, 선택한 날짜를 각각
startTime,endTime으로 설정해 서버에 요청한다. 이때 서버로 전달되는 시간은 모두 UTC+0 기준이다.
- 서버에서 반환되는 timestamp 역시 UTC+0 기준이다.
- 실제 응답값:
2025-07-11 20:00:00(UTC) - 변환 결과:
2025-07-12 05:00:00(KST) - 그런데 사용자가 선택한 날짜는
2025-07-10 ~ 2025-07-11 - 결과적으로 사용자가 "내가 지정한 날짜가 아닌데?"라고 느낄 수 있음
문제는 이 timestamp를 로컬 시간으로 변환할 때 발생한다.
타임존 보정으로 인해 날짜가 바뀌어 UI 상 사용자가 선택한 범위를 벗어나는 것처럼 보이게 된다.
예를 들어:
어떻게 하기로 했나?
개인적인 의견으로는, **"UTC 기준으로 표시되며 시차가 존재할 수 있다"**는 안내 문구를 UI에 추가하고,
날짜를 그냥 UTC 기준으로 고정 표시하는 게 가장 간단하고 직관적인 해결책이라고 생각했다.
하지만 논의 끝에, UI 상에서는 사용자가 선택한 범위 안에 데이터가 들어와야 한다는 방향으로 정리되었다. 따라서 프론트에서
startTime, endTime을 UTC 기준에서 로컬 타임존 기준으로 조정해서 서버에 요청하는 방식으로 결정되었다.
이렇게 하면 서버는 계속 UTC 기준으로 응답하지만,로컬에서는 사용자가 지정한 날짜 범위 안에 정확히 들어오게 된다.
변환은 어떻게 했나?
date-fns-tz에서 제공하는 formatInTimeZone 함수를 활용했다.이 함수는 로컬 기준의 Date 객체를, 특정 타임존 기준 문자열로 포맷할 수 있다.
이처럼, 로컬 자정 시간을 기준으로
Date 객체를 만든 뒤, 이를 UTC 기준으로 보정해서 서버로 전송하면 타임존에 상관없이 정확한 날짜 범위로 데이터가 조회된다.
formatInTimeZone은 KST, CST, EST 등 어떤 로컬 타임존에서 실행하더라도 정확하게 보정된 시간 문자열을 만들어주므로 신뢰성이 높다.마무리
시간대는 늘 골치 아프다.
겉보기엔 가벼운 문제 같지만, "사용자에게 친숙하게 보이게 할 것인가" vs "서버와의 일관성을 우선할 것인가"는 늘 고민거리다.
이번 경험은, 단순한 기술적 이슈 같아 보여도 의사결정과 팀 간 소통이 얼마나 중요한지를 다시금 느끼게 해준 사례였다.