datetime 객체 생성 시 timezone 주입하는 스타일

[jseop-lim]

논의가 촉발된 PR 리뷰입니다.

datetime.datetime 객체를 생성할 때 tzinfo 매개변수에 시간대 값을 주입합니다. UTC 시간대를 입력할 경우 아래 두 가지 방법이 가능합니다. 어떤 것을 권장하면 좋을까요?

1. datetime.timezone.utc
2. zoneinfo.ZoneInfo('UTC')

[jseop-lim]

zoneinfo.ZoneInfo('UTC')를 선호합니다.

1. UTC가 아닌 다른 시간대와의 일관성 유지 e.g. zoneinfo.ZoneInfo('Asia/Seoul')
2. 장고 유틸과 겹치기 때문에 datetime.timezone.utc를 import할 때 from datetime import timezone을 사용할 수 없습니다. 기존 코드와의 혼란을 줄이기 위해 이 import는 피하면 좋을 것 같습니다.

[jseop-lim]

@cbscsm

[twins1040]

UTC 를 주입하는 경우라면, 2번 선호합니다. timezone 을 다룰 때는 zoneinfo 를 사용한다. 라는 단순한 룰이 되기 때문입니다.
다만 django 내에서 KST 를 사용하는 경우에는 먼저 make_aware 함수를 사용할 지 고려한 후 사용해야 할 것 같습니다.

[jseop-lim]

일관성을 증진한다는 점에 동의합니다. make_aware()은 상대적인 현지 시간대를 적용, ZoneInfo 사용은 절대적 시간대를 적용으로 경우가 구분되므로 '한국시간'을 사용해야 하는 경우가 아니라면 make_aware()가 우선된다고 생각합니다. 실제 우리 코드에도 make_aware()가 우선적으로, 많이 사용되고 있습니다.

[cbscsm]

저는 일단 UTC 사용을 지양해야한다고 생각합니다. 외부 시스템에서 UTC를 필요로 하는 경우 그 연결점에서만 UTC로 변환을 하면 되고,
그 외에는 특히 날짜를 다룰 때 KST를 기준으로 해야하므로 UTC를 혼용해서 쓸 필요가 없을 것 같습니다.

만약 외부시스템으로 export하는 코드 등의 경우 UTC를 사용한다면, django.utils.timezone을 쓸 필요가 없으므로
import 충돌 문제는 발생할 가능성이 낮아보입니다(하나의 모듈이 지나치게 다양한 기능을 담지 않는다는 가정이 있다면요).

(위와 같은 상황에서 불가피하게)
UTC를 사용할 때에는 더 안정적이고 절대적이라는 점에서 datetime.timezone.utc를 저는 약간 더 선호합니다. ZoneInfo('UTC') 또는 ZoneInfo('utc')는 IANA 데이터베이스를 사용하므로 데이터베이스의 버전이나 오염에 영향을 받을 수 있습니다. 다만 현실적으로 이런 문제가 생길 가능성은 매우 낮고 이는 매우 크리티컬한 문제이므로 UTC와 무관하게 바로 수정해야하는 문제입니다. 100%의 안정성과 99.99...%의 안정성 정도의 차이일 것 같습니다. 그렇지만 다른분들이 말씀하신 일관성 측면에서 ZoneInfo('UTC')의 사용의 이점도 충분히 있다고 생각합니다.

[정리]
datetime.timezone.utc: 60
zoneinfo.ZoneInfo('UTC'): 40
정도의 의견입니다.

[배경]

1. datetime.timezone.utc는 datetime.timezone 인스턴스입니다.
2. 이는 zoneinfo.ZoneInfo와 서로 다른 타입입니다. 하지만 두 타입 모두 tzinfo의 서브타입입니다.
3. timezone 클래스는 고정 offset 방식을 사용하고, ZoneInfo 클래스는 IANA timezone DB를 사용합니다.
4. 현실 시간대를 다룰 때에는 IANA 방식을 따르는 것이 권장되지만, UTC의 경우에는 둘 간의 차이가 없습니다(없어야 합니다).
5. zoneinfo 라이브러리 예시 코드에서도 UTC에 대해서는 timezone.utc를 사용하고 있습니다. ZoneInfo('UTC')의 사용에 대해서 언급하고 있지는 않습니다.

[jseop-lim]

5. zoneinfo 라이브러리 예시 코드에서도 UTC에 대해서는 timezone.utc를 사용하고 있습니다. ZoneInfo('UTC')의 사용에 대해서 언급하고 있지는 않습니다.는 치명적이네요. 안정성과 근본을 좇는다는 측면에서 timezone.utc 사용이 좋아보입니다. 다만, 명욱님께서 언급하신대로 일관성이 작아지고, import 충돌 가능성이 적어도 우리 코드베이스에서 제기됩니다. 따라서 저도 비록 (매우 조금) 덜 안정적이지만 ZoneInfo 사용이 좋아보입니다.

[cbscsm]

테스트 해보니 ZoneInfo('UTC') 또는 ZoneInfo('utc')가 문제 없이 동작하는 것 같긴 합니다. 다만 아직 이렇게 사용하는 레퍼런스를 찾지 못했습니다. 이는 ZoneInfo가 도입된 것이 파이썬 3.9로 비교적 최근이라서 그런 것일 수도 있다고 생각합니다.

ZoneInfo를 도입한 Django 내부 코드에서도 전부 datetime.timezone.utc를 사용하고 있고, Django의 경고메시지에서도 기존 django.utils.timezone.utc를 datetime.timezone.utc로 바꿔 쓰라고 가이드 하고 있습니다.
여러가지 레퍼런스나 정황으로 보았을 때 datetime.timezone.utc로 쓰는 것이 일단은 안전해 보입니다(적어도 지양할 부분은 아닌 것 같습니다).

추가적으로 ZoneInfo('UTC') 또는 ZoneInfo('utc')를 사용하는 사례와 자료가 발견되면 그 때 그 장단점을 판단해서 바꾸는 것도 좋지 않을까 싶습니다.

[jseop-lim]

본 논의의 주제와 연관된 새로운 제안입니다.

제안

KST나 UTC 등 시간대 상수를 특정 모듈에 선언하고 다른 모든 파일에서 그 모듈의 상수를 불러 쓰는 구현은 어떨까요?
즉, 시간대 상수를 저희 프로젝트에서 한 번 더 추상화하는 것입니다.

효과

시간대를 한 방식으로만 가져옵니다. 시간대 코드가 django나 python에 의존하지 않게 됩니다.
ZoneInfo('Asia/Seoul')의 경우 각 코드마다 지역변수로 선언해놓고 쓰는 일이 잦아 일관성을 증진하는 방안을 고안했습니다.

예시 구현

예를 들어 core.utils 패키지 내에 timezone.py를 아래와 같이 작성합니다.

from zoneinfo import ZoneInfo

KST = ZoneInfo('Asia/Seoul')
UTC = ZoneInfo('UTC')  # 혹은 datetime.timezone.utc

@cbscsm

[cbscsm]

만약 KST를 직접 사용하게 되면 Django의 settings에서 지정한 TIME_ZONE을 우회해서 사용하는 것이 됩니다.
물론 저희 서비스의 특성 상, 다른 settings의 TIME_ZONE을 바꿀 일이 없긴 하겠지만 그래도 settings에 지정된 값을 사용하지 않고
각자 사용한다면 코드 해석 때 헷갈릴 수 있을 것 같습니다.

때문에 KST의 경우는 직접 쓰기보다, django.utils.timezone.make_aware를 쓰는 것이 어떨까 싶습니다.
naive datetime이나 date를 aware datetime으로 변경할 때 타임존을 지정하는 방식이 다소 번거로운데,
make_aware를 사용하면 간단하게 처리할 수 있습니다. 대부분의 코드에서 이것을 사용하고 있습니다.

UTC는 다음과 같은 이유에서 사용할 필요가 없다고 생각됩니다.

• 저희가 작성하는 코드에서는 모두 KST를 사용합니다.
• 외부 코드(라이브러리 등)을 사용하더라도, 정상적인 코드라면 특정 타임존을 요구하지 않습니다. 특정 타임존이 필요하다면, 그 시스템 내에서 타임존 변환을 해서 사용하는 것이 일반적입니다.
• 외부 코드 또는 API의 리턴 타임존이 UTC더라도, 유닛테스트의 어서션에서 타임존이 일치할 필요가 없으므로 make_aware로 비교할 수 있습니다.

print(datetime(2023, 3, 15, 9, tzinfo=ZoneInfo('Asia/Seoul')) == datetime(2023, 3, 15, tzinfo=ZoneInfo('UTC')))  # True

결론적으로, Django settings를 사용하는 eight 코드에서는 이미 settings.USE_TZ와 settings.TIME_ZONE으로 전반 시스템이 동작하므로
별도 타임존 인스턴스가 필요 없다고 생각됩니다.

[cbscsm]

말씀하신것처럼
기존 코드에서 ZoneInfo('Asia/Seoul')나 ZoneInfo('UTC')를 사용하고 있다면 그것을 django.utils.timezone.make_aware로 대체하는 것이 좋을 것 같습니다.

[cbscsm]

django의 영향을 받지 않는 독립적인 코드/프로젝트에서는 공통 타임존 상수를 두는 방식에 동의합니다.