글로벌 서비스

우리 서비스는 언젠가 전세계에서 이용 가능한 글로벌 이커머스 서비스가 될 수 있다는 가정 하에, 어떻게 설계할지 고민했다 🧐
여러 국가에서 이 서비스를 사용할 때, 발생할 수 있는 문제는 어떤 것들이 있을까?

한번, 데이터베이스에 한국시간 기준 2021-01-02 00:00:00 으로 새해 할인 이벤트 만료 시간이 저장되어있다고 생각해보자!
한국 시간 2021-01-02 00:00:01 에 한국에 있는 사용자는 이벤트를 이용할 수 없지만,
한국보다 약 13시간 느린 미국에 있는 사용자는 이미 13시간 전부터 이벤트가 만료되었을 것이다!
우리는 모든 나라의 1월 2일에 이벤트가 만료되길 바랐지만, 의도대로 동작하지 않았다...!

그렇다면, 한국시간을 기준으로 미국에서는 +13시간, 독일에서는 +7시간 등 나라마다 한국을 기준으로 계산해주어야 하는걸까..?
한국과 다른 나라의 시차를 일일이 계산해서 적용한다면, 실수하기 너무 쉬울 것 같다.
어떤 시간을 기준으로 해야 유연하고, 안전하게 시간 데이터를 관리할 수 있을까?

데이터베이스 기준 : UTC

• "국제적인 표준 시간" 이다.
• 대부분의 시간 라이브러리는 UTC를 기준으로 만들어져있다! 따라서, 여러 다른 시간대로 변환하기 매우 편리하다.
• 우리는 UTC를 기준으로 데이터를 저장하기로 결정했다!

저장 형태

• UCT 기준 yyyy-MM-dd hh:mm:ss 문자열 형태로 저장하고자 한다!
• 사람이 읽기 쉽고, 필요한 정보를 적절히 담았다.

서버 기준 : Local

• 서버에서는 JVM timezone 을 로컬 타임존으로 설정한다.
• 데이터베이스에 있는 데이터를 가져와서 사용자에게 보여줄 때에는 로컬 타임을 적용하여 변환해서 보여준다.

표현 형태

• ISO 8601 포맷 문자열을 사용하고자 한다.
• ISO 는 데이터 교환을 다루는 국제 표준 방식이다.
• 2021-08-10T17:40:00+09:00 처럼 시간 뒤에 timezone offset 이 표시되어 있기 때문에 커뮤니케이션 미스 등으로 인한 실수의 염려가 적다!
• 사람이 읽기 쉽다는 점은 당연하다!

시간 타입

Timestamp VS ZonedDateTime

• 결론 : ZonedDateTime 을 쓰는 것이 더 좋다.
• Timestamp 는 기존 java.util.Date 를 상속받았기 때문에 그것의 문제점을 그대로 안고 있다!

java.util.Date 의 문제점

• 불변 객체가 아니다.
• 상수 필드 남용
  • calendar.add(Calendar.SECOND, 2);
• 헷갈리는 월 지정
  • 1월을 0으로 표현하는 문제
• 일관성 없는 요일 상수
• Date와 Calendar 객체의 역할 분담
  • 필요한 기능을 사용하기 위해서 Calendar 객체를 생성하고 Date 객체를 생성하는 프로세스를 거치기 때문에 번거롭고 생성 비용이 비싸다.
• 기타 java.util.Date 하위 클래스의 문제

Reference

• https://d2.naver.com/helloworld/645609
• https://velog.io/@lsb156/Instant-vs-LocalDateTime
• https://jojoldu.tistory.com/361