LocalDateTime은 쓰기가 편하다
LocalDateTime은 Zone 정보가 필요없다.
그래서 IOS 포맷으로 변환시 Zone (또는 Offset) 표기가 빠져 있어서 간결하다.
- ZonedDateTime.of() 의 경우 Zone 을 꼭 넣어줘야 한다.
- OffsetDateTime.of() 의 경우도 Offset을 넣어줘야 한다.
특히 한국향 서비스라면 굳이 "한국시간으로 22시" 라고 표현할 필요가 없다는 생각 이다.
(Money 클래스에 환율이라던지, 다국어를 지원하는 MessageFormatter 도 마찬가지)
그래서 상대적으로 다른 시간 클래스보다 쓰기도 보기도 좋은 LocalDateTime을 좋아한다.
글로벌 서비스 이더라도 LocalDateTime의 쓰임새는 있다.
자정이벤트를 등록한다 했을땐 그 시각 자체가 의미있다.
이 외에도 타임존을 모르고 싶은 케이스는 얼마든지 있다.
KST 와 UTC
LocalDateTime을 즐겨 쓰기 때문에 타임존도 Asia/seoul 으로 설정 하는것을 선호한다.
만약 UTC 서버에서 LocalDateTime.now() 으로 로그를 찍으면 9시간 전으로 보이게 된다. (물론 로깅 시각도)
JVM 옵션으로 강제로 UTC로 실행해보면 알수있다 (java -Duser.timezone=UTC -jar app.jar)
하지만 UTC냐 KST냐는 선택의 영역이다.
의외로 UTC 추종자도 은근히 많기 때문인데, 이유는 Asia/seoul은 옵션이다보니 누락가능성이 있기 때문이다.
예1.
DB에 UTC 시각을 넣어두는 케이스
예2.
두 기종간의 타임존이 다른경우
예2를 좀더 자세히 알아보자.
A서버(KST) 에서 B서버(UTC) 로 "예약시간 22시" 라는 메세지를 보낸다고 가정하자.
A에서 메세지를 보낼때 LocalDateTime을 써서 발행 하면 포맷은 다음과 같다.
- "reservedAt" : "2023-05-30T22:00:00"
B는 현재시간이 2023-05-30T13:00:00 이다.
위 메세지를 받았을때, B는 A의 타임존을 모르기 때문에 LocalDateTime으로 단순하게 포매팅 해버리면 9시간뒤의 메세지로 해석할수 있다.
이런 케이스들은 의외로 늦게 발견될수 있다.
대체로 시각이란게 상대적 이라서 (보다 큰, 작은) 문제가 잘 발생되지 않다가 특수한 상황 에서만 발견되다보니 한참이 지나서야 발견된다.
zone 이 있거나 없는 클래스로 컨버팅 하거나 offset이 있거나 없는걸로 컨버팅 한다던지..
truncate하면서 00:00 로 만들면서 잘못 절삭 된다던지..
구체적인 예시가 잘 기억 안나긴 한데 대충 생략
결론 :
- LocalDateTime은 매우 간편해서 쓰기 좋다.
- UTC와 KST는 장단점이 있다.
- 여러 서비스가 협업할땐 타임존에 대해 얘길 하는것이 좋겠다.
- 통일하면 베스트이다.
- 통일이 안되더라도 타임존을 넣으면 덜 헷갈릴듯 하다.
- 만약 통일이 안되었을때 타임존이 없는 포맷은 어떻게 해석 할것인가(UTC냐 KST냐)에 대해선 제공자가 알려줘야 한다.
