사이드 프로젝트로 소개한 콩이라고 합니다.

개발할 때, datetime에 대한 이해도가 떨어져서, 개인적으로 정리한 글인데 공유하면 좋을 것 같아서 공유드리고, 틀린 부분있으면 알려주시고 같이 성장하는 계기가 되었으면 좋겠습니다!! 감사합니다

개요

어제 디버깅 세션에서 ‘datetime 생성자에 pytz timezone을 넣으면 버그나는 것을 pytz 개발자는 왜 고치지 않는가’에 대해 명쾌한 답변을 드리지 못하였기에 조사해서 정리해 둡니다.

한줄 요약

datetime의 tzinfo를 직접 지정하는 방식은 Daylight Savings Time에서 어차피 버그나니 그렇게 쓰지 말라고 일부러 안고치고 있는 것 입니다.

배경

datetime객체의 생성자에 pytz 라이브러리의 timezone 객체를 쓰면 대한제국 초창기의 타임존을 불러옵니다. 그래서 print를 찍어보면 괴상한 +08:28 타임존이 박혀있는 것을 볼 수 있습니다.

import datetime
from pytz import timezone

KST = timezone('Asia/Seoul')

my_date = datetime.datetime(2022, 11, 1, 9, tzinfo=KST)
print(my_date)  # 2022-11-01 09:00:00+08:28 <-???
print(my_date.astimezone(datetime.timezone.utc))  # 2022-11-01 00:32:00+00:00

이에 대해 문서에서는 tzinfo에 넣지 말고 무조건 localize()를 쓰라고 강조하고 있습니다.

pytz documentation의 첫 부분에 강조되어 있긴 하지만 이미 적당히 동작하면 누가 개발하는데 문서를 읽습니까?

직관적인 것을 추구하는 파이썬으로써 왜 상당히 많은 사람이 밟았을 버그를 고치지 않고 있는 것일까요?

이는 저렇게 datetime의 tzinfo에 직접 pytz timezone을 박는 것이 pytz가 해결하려는 문제에 직접적으로 반하기 때문입니다.

Python 2.4 부터 있었던 pytz의 목적은 다음과 같습니다.

IANA 타임존 데이터베이스 지원
Daylight Savings Time (DST) 관련 지원

저희는 DST에 관심이 없으니 pytz를 쓰는 이유는 첫 부분인 IANA 데이터베이스 지원일 것입니다.

IANA 타임존 데이터베이스(혹은 Olson database)는 전세계적인 기여를 통해 만들어진 타임존 데이터베이스 입니다. “Asia/Seoul” 같은 이름도 이 표준에 포함되어 있는 것입니다. CLDR라는 이런 비슷한 류의 locale정보와 함께 묶여서 배포되며, 웬만하면 모든 시스템에 포함되어 있습니다.

문제는 DST인데, DST가 뭐냐면 봄에 시계 한시간 뒤로 돌리고 가을에 한시간 앞으로 감는 겁니다. 일부 국가에서 태양광 좀 더 쐬겠다고 시행하는데 듣는 순간 머리가 지끈거리면 정상입니다.

예를 들어서 데이터베이스에서 user의 timezone과 어떤 (timezone없는) 시간정보를 따로 저장했다고 해봅시다. 그러면 다음과 같은 문제가 생깁니다.

유저: 캘리포니아 거주 (Pacific Time)
시각: 2022년 3월 13일 오전 1시 30분

→ 이 정보는 서로 다른 2개의 시각을 나타낼 수 있습니다. (DST가 적용된것/아닌것의 차이)

(구체적으로는, 2022-03-13T09:30:00Z 일수도 있고 2022-03-13T10:30:00Z 일수도 있습니다.)

결론적으로 이를 해결하기 위해서는 utc offset 이외의 다른 정보가 포함된 상위 객체가 필요합니다.

pytz의 timezone은 그래서 여러개의 utc offset을 하나로 묶어주고 있는 객체이며, utc 기준 시점이 주어지면 그에 해당하는 utc offset을 지정해 줍니다.

한마디로, tzinfo와 pytz timezone은 추상화 층위가 다른 incompatible한 객체입니다.

이는 pytz timezone 객체의 _utc_transition_times 를 찍어 보면 알 수 있습니다. 한 pytz timezone 객체는 여러 offset들을 ._tzinfos 속성에 저장하고 있으며, 주어진 시점에 따라 _utc_transition_times 테이블을 참조해서 utc offset을 세팅합니다.

# 캘리포니아가 사용하는 LA 타임존
PT = timezone('America/Los_Angeles')
PT._utc_transition_times  # 엄청길다. 1901년부터 2037년까지 타임존 offset의 변경사항 수록.

# 반면 한국의 타임존은 변경사항이 상대적으로 적다.
# 1948년~1951년, 1955~1961년 한국에서도 서머타임을 실행했다는 것을 알 수 있다.
KST._utc_transition_times

그래서 시점이 주어지지 않은 타임존은 utc offset이 미정인 상태로 놓이게 되며, pytz에서는 임의로 IANA 데이터베이스의 첫 항목에 써있는 utc offset을 긁어다가 둡니다.

결론적으로 pytz개발자의 입장은 타임존 지정만으로는 UTC offset을 알 수 있는 방법이 없다는 것입니다. 서머타임을 시행하지 않고 1988년 이래 타임존이 바뀌지 않은 한국 입장에서는 말도안되는 엣지케이스이지만, 서머타임을 시행하며, 심지어는 미국같이 서머타임의 실행여부가 주별로 관할권마다 다른 (한 주 내에서도 관할구역이 다른, 인디언 보호구역 같은 곳에서는 타임존이 다를 수 있습니다) 그런 끔찍한 세계에서는 모든 타임존 구현체가 일년에 2번씩 버그가 터질 가능성이 있는 시한폭탄인 것입니다.

그럼 왜 Python 쪽에서 고치지 않는가

결론만 말하면 고쳤습니다. 구체적으로는 pytz의 IANA database 지원 기능만 똑 떼와서 표준 라이브러리에 삽입했습니다. python 3.9 부터 zoneinfo 모듈이 도입되었고, 이는 datetime 객체에 넣어도 잘 동작합니다.

from zoneinfo import ZoneInfo
from datetime import datetime

KST = ZoneInfo("Asia/Seoul")
my_date = datetime(2022, 11, 1, 9, tzinfo=KST)
print(my_date)  # 2022-11-01 09:00:00+09:00  <- yay!

제가 그때 답변드렸던 것은 ‘python 내장 라이브러리를 고치면 영향범위가 크므로 써드파티 라이브러리와의 합합을 맞추기 위해 동작을 변경하지 않는다’였는데 사실은 반만 맞는 얘기였던 것이죠. 실제로 파이썬이 low level 에서부터 엄청 많이 쓰여서 동작을 바꿔서 스마트 그리드 같은거 한번 버그 일으키면 국가재난 일으키는 건 일도 아니긴 할겁니다.

실제로 zoneinfo가 논의된 PEP-431와 PEP-615를 보시면 2012년부터 싸우기 시작되서 2020년에 끝납니다. 장장 8년동안 얼마나 많은 상황이 논의되었는지는 두 문서를 직접 훑어보시면 알 수 있으실 것입니다. 어느게 옳은 동작인가 뿐만 아니라, forward/backward compatibility는 물론, 표준 라이브러리에 들어갈 기능이 맞는지 조차 어느하나 간단한 문제가 아닌 것을 알 수 있습니다.

결론

Daylight Savings Time은 만악의 근원입니다.
pytz 대신 파이썬의 ZoneInfo 모듈을 씁시다.

교훈

솔직히 이런거 몰라도 개발하는데에 지장이 없고 그냥 제가 궁금해서 심연을 한번 들여다본것입니다.

저희가 여기서 얻을 수 있는 교훈은 통계학에서 말하는 “모든 모델은 잘못되었지만 일부는 유용하다” 처럼 프로그래밍도 무한히 복잡한 현실을 추상화를 통해 간소화하려는 몸부림이다라는 정도겠네요.

사족

윤초라는 것도 있긴 한데말이죠…

datetime 생성자의 pytz timezone을 넣으면 버그나는걸 pytz 개발자가 고치지 않는 이유에 관한 고찰