애플리케이션의 서버 타임존을 UTC로 설정했기 때문에, 흔히 애플리케이션 코드에 녹아있는 LocalDateTime.now() 와 같이 현재시간을 출력하는 코드는 실제 서버가 배포되면 UTC기준으로 출력이 된다. 그렇기 때문에 다음과 같이 DateTimeUtil 클래스를 만들어서, now라는 시간에 +9 시간을 더해야 한다.
java
public class DateTimeUtils { public static LocalDateTime now() { return LocalDateTime.now().plusHours(9); }}
위의 코드의 문제점은 UTC +9 = KST 라는 사실을 알고 있어야 하는것과, 9라는 것이 하드코딩 되어있다는 것이다.
3.2. 더 살펴볼 문제
java
public class DateTimeUtils { ... public static LocalDateTime nowAtZone() { return LocalDateTime.now().atZone(ZoneId.of("Asia/Seoul")).toLocalDateTime(); } public static LocalDateTime nowFromZone() { return ZonedDateTime.now(ZoneId.of("Asia/Seoul")).toLocalDateTime(); }}
이번에는 plusHours(9) 방식 외의 ZonedDateTime를 이용한 방법으로 똑같은 상황을 구현해 보자.
2개의 현재시간의 LocalDateTime을 찍는 정적메서드이다. 확연한 차이가 존재한다.
의도한 바는, KST 시간대로 현재의 LocalDateTim을 찍고 싶었던 경우이다.
첫번째 메서드는 UTC로 서버타임존이 설정(위의예제에서 그렇게 설정함) 되어있기 때문에, LocalDateTime.now() 를 했을때 UTC 시간으로 만들어진다. 그 이후에, atZone()으로 Asia/Seoul로 설정하더라도, UTC시간임에는 변함이 없다. 원래 의도한 경우에 어긋난다.❌
두번째 메서드는 ZonedDateTime의 now메서드로 Zone을 Asia/Seoule로 현재 시간을 만든다. 그렇기 때문에 KST시간으로 출력된다. 이게 원래 의도한 경우이다. ⭕️
4. 정리
스프링 프로젝트 내에 서버 타임존을 @PostConstructor로 설정하는 방법을 알아보았다.
그리고 애플리케이션내에서 날짜를 사용하는 부분에 대해서 KST시간으로 처리하도록 Utility성 클래스를 만들어서 사용하는 방법을 알아보았다.
끝으로 Zone설정을 잘못하게 되면, 원래 의도했던 대로 동작하지 않는 경우를 알아보았다.
정정 · 제보
정정·제보는 댓글로 남겨 주세요.