Comet5 블로그
개발·운영

Python 시간대 처리: UTC 저장과 한국 날짜의 경계

Comet5 · 최초 발행 · 약 4분

같은 순간이 UTC와 한국에서 다른 날짜가 되는 사례로 예약 공개 조건과 시간대 변환을 검증합니다.

이 글의 목차

예약 게시물이 하루 늦게 보이는 문제는 날짜 문자열의 정렬보다 “어느 시간대의 오늘인가”에서 시작할 수 있습니다. 한국 시각 자정은 UTC 기준 전날 오후 3시입니다. 이 글에서는 서버 위치와 관계없이 한국 날짜를 계산하는 작은 예제를 만듭니다.

순간과 달력 날짜를 구분하기

2026-09-30은 날짜일 뿐 정확한 순간이 아닙니다. “한국에서 9월 30일부터 공개”라면 Asia/Seoul의 날짜와 비교해야 합니다. 반면 “9월 30일 오전 10시에 이메일 발송”은 시간대가 있는 실행 시각이 필요합니다. 두 요구를 같은 필드 하나로 표현하면 자정 처리나 해외 사용자 표시에서 혼동이 생깁니다.

Python의 naive datetime에는 시간대 정보가 없습니다. aware datetime은 UTC 오프셋을 해석할 정보를 가집니다. replace(tzinfo=...)는 시계 숫자를 유지한 채 시간대 의미를 붙이고, astimezone(...)은 같은 순간을 다른 시간대의 시계 숫자로 바꿉니다. 이미 UTC인 값을 한국 시각으로 바꾸려면 후자를 사용합니다.

자정 직전과 직후를 실행해 보기

Python 3.11 이상과 IANA 시간대 데이터가 있는 환경을 기준으로 합니다. 일부 환경에서 ZoneInfoNotFoundError가 나면 운영체제 시간대 데이터 또는 tzdata 패키지 설치 여부를 확인합니다.

from datetime import date, datetime, timezone
from zoneinfo import ZoneInfo

SEOUL = ZoneInfo('Asia/Seoul')
release_date = date(2026, 9, 30)

def is_visible(now, scheduled_date):
    if now.tzinfo is None or now.utcoffset() is None:
        raise ValueError('시간대가 있는 시각이 필요합니다')
    return now.astimezone(SEOUL).date() >= scheduled_date

before = datetime(2026, 9, 29, 14, 59, 59, tzinfo=timezone.utc)
after = datetime(2026, 9, 29, 15, 0, 0, tzinfo=timezone.utc)
assert not is_visible(before, release_date)
assert is_visible(after, release_date)
print(before.astimezone(SEOUL).isoformat())
print(after.astimezone(SEOUL).isoformat())
try:
    is_visible(datetime(2026, 9, 30), release_date)
except ValueError:
    print('naive 입력 거절')
else:
    raise AssertionError('시간대 없는 입력을 허용했습니다')

예상 시각은 2026-09-29T23:59:59+09:00과 2026-09-30T00:00:00+09:00입니다. UTC 날짜는 둘 다 9월 29일이지만 공개 결과는 달라집니다. 서버의 date.today()를 그대로 사용하면 서버 설정에 따라 다른 답을 낼 수 있습니다.

입력 형식부터 명시하기

외부 API가 2026-09-30T10:00:00만 보내면 한국 시각인지 UTC인지 알 수 없습니다. 문서화된 규칙이 없다면 임의로 추측해 저장하지 않습니다. 오프셋이 포함된 문자열이나 UTC 표기를 받도록 계약을 정하는 것이 좋습니다.

요구 저장·비교 기준 확인할 경계
한국 날짜부터 글 공개 날짜 + 고정된 서비스 시간대 한국 자정
한 번만 실행할 작업 UTC로 환산 가능한 시각 재시도와 중복 실행
매일 현지 오전 9시 지역 시간대 + 반복 규칙 일광절약시간 전환

해외 지역의 현지 시각에는 존재하지 않거나 두 번 나타나는 시간이 있을 수 있습니다. 단순히 tzinfo를 붙였다고 입력 검증이 끝나지 않습니다. 반복 예약 기능은 이런 시각을 건너뛸지, 다음 유효 시각으로 이동할지 별도 정책이 필요합니다. 이 글의 코드는 한국 날짜 기반 공개만 해결합니다.

날짜가 되어도 바로 안 보이는 경우

동적 페이지가 요청마다 날짜를 비교해도 CDN이 이전 HTML을 계속 반환하면 공개가 지연될 수 있습니다. 앱의 판정, 목록·사이트맵의 필터, 캐시 만료를 각각 확인해야 합니다. 또한 콘텐츠 파일을 프로세스 시작 때 읽는 앱이라면 파일 수정 후 프로세스 재시작이 필요합니다. 시간대 테스트만으로 배포와 캐시 문제까지 검증한 것은 아닙니다.

참고 자료

같은 카테고리 글