글로벌 서비스 구축을 위한 TimeZone(타임존) 적용 방법

타임존이란

동일한 로컬 시간을 따르는 지역을 의미하며, 주로 해당 국가에 의해 법적으로 지정된다.

보통 국가별로 각자의 고유한 타임존을 사용하고 있으며, 미국이나 캐나다처럼 면적이 넓은 나라인 경우 지역별로 각지 다른 타임존을 사용하기도 한다.
예를들어 우리나라의 타임존은 KST (Korea Standard Time)이라고 불리는데, 기준 시간보다 9시간 빠른 영역이다.

GMT, UTC, 오프셋(Offset)은 무엇인가?

GMT (GreenWich Mean Time) && UTC(Coordinated Universal Time)
영국 그리니치 천문대를 기준으로 하는 태양시간이다.

지구의 자전주기의 흐름이 조금씩 늦어져서 이를 해결하기 위해 새로운 표준으로 제정한 시간이 UTC 이다.

실제 소프트웨어를 사용할 때 UTC 라고 하는 것이 더 정확한 표현이다.

브라우저에 따라 기본 설정이 GMT 일수도 있고, UTC 일수도 있다. 시간 차이는 1초 미만이므로 크게 신경쓰지 않아도 된다.

오프셋 (Offeet)
UTC 기준으로 시간이 빠르고 늦음을 표현한 식이다.
UTC +09:00에서 +09:00의 의미는 UTC의 기준 시간보다 9 시간이 빠르다는 의미이다. 즉 UTC와의 차이를 나타낸 것이며, +09:00, -03:00 과 같이 표현된다.

보통 국가나 지역들마다 자신들이 사용하는 타임존에 대해 고유의 이름을 부여한다. 예를 들어, 대한민국의 타임존은 KST 라고 불리는데 이는 앞서 설명했듯이 특정 오프셋을 지칭하므로 KST = UTC +09:00 라고 이해하면 된다. 하지만 +09:00 오프셋은 한국뿐만 아니라 일본, 인도네시아 등 여러 지역에서 사용하고 있으므로, 오프셋과 타임존 이름들의 관계는 1:N이다.

타임존의 문제점

타임존은 한번 정하면 변하지 않을까?

변할수도 있다. 정치, 경제적인 이유 등으로 타임존 변경 가능하다.

즉, 타임존은 No Rules ! 규칙이 없다

• 타임존 오프셋을 결정하는 규칙을 만들 수 없다. 나라 상황에 맞게 변경하는 역사가 있기 때문이다.
• 규칙이 없으므로 프로그래밍으로 해결할 수 없고, DB로 관리해야 할 수 밖에 없다.

글로벌 서비스 구축을 위해 TimeZone을 고려해야 하는 이유

글로벌 서비스를 위해서는 언어 문제, 현지화 문제 등 고려해야 할 사항들이 많지만,

그 중에서도 대처하기 쉽지 않은 문제는 시차, 정확히 말하면 시간대와 관련된 문제이다.

타임존을 고려해야 하는 간단한 시나리오를 생각해보자.

1. 클라이언트 환경에서 사용자가 inputbox 에 일정(날짜 및 시간)을 입력하면, 그 정보를 서버로 전송해서 DB 에 저장한다.
2. 그리고 목록 페이지에서는 클라이언트가 다시 서버로부터 등록된 일정의 정보를 받아와서 화면에 보여주게 된다.
3. 이 때, 서버에 저장된 동일한 데이터에 접근하는 클라이언트들이 서로 다른 타임존을 갖고 있을 수 있다.
4. EX. 예를 들어, 서울에서 2021년 11월 2일 오전 11시 10분에 일정을 등록했다면,
   뉴욕에서 이를 조회할 때는 2021년 11월 2일 오후 9시 10분이라고 표시되어야 한다.

즉, 다양한 타임존의 클라이언트 환경을 지원하기 위해서는 서버에 저장되는 데이터가 타임존에 영향을 받지 않는 절대값이어야 한다.

또 다른 예시를 보자.
애플(Apple)에서 뉴욕시를 기준으로 2021년 11월 2일 오전 8시에 행사를 열려고 한다.
전세계에 똑같은 이벤트를 적용하려면 어떻게 해야할까?

타임존을 고려하지 않았을 경우

• 전세계 동시 시작 이벤트 시작이 불가하다.
• 나라별로 다른 시간에 시작하게 된다.
• ex. 한국
  • 타임존 고려 : 2021년 11월 2일 오후 9시 행사 시작
  • 고려하지 않았을 경우: 뉴욕보다 13시간 빠르게 행사를 시작하게 된다.

글로벌 서비스 구축을 위한 Timezone 적용하는 법

한 가지만 기억하면된다. 모든 통신은 UTC 이다.
서버에서의 모든 통신은 UTC로 하고 client에서 UTC 기준의 시간 데이터를 클라이언트단에서 각 나라에 맞게 변경해서 보여줘야 한다.

⭐데이터베이스 기준 : UTC

• 국제적인 표준 시간
• 대부분의 시간 라이브러리는 UTC 를 기준으로 만들어져 있다.
• 따라서 여러 시간대로 변환하기 매우 편리하다
• 저장 형태
  • UTC 기준 yyyy-MM-dd'T'HH:mm:ssZ 문자열 형태

⭐서버 기준 : UTC

• 여기서 서버는 Backend 즉, Application으로 볼 수 있다. (Spring)
• 서버에서의 모든 통신은 DB 기준인 UTC 로 이루어져야한다.
  • FE에 제공되는 모든 시간 관련 API의 response field 값은 UTC여야 한다는 것이다.
• 데이터 형태는 당연히 DB 데이터와 동일하다.
  • UTC 기준 yyyy-MM-dd'T'HH:mm:ssZ 문자열 형태

⭐프론트 기준 : Local (사용자의 타임존)

• 사용자에게 보여줄 때는 클라이언트 단에서 각 나라에 맞게 localtime을 적용하여 변환해서 보여준다.
• 만약 서비스라면 사용자의 타임존을 화면 단에서 입력받게 하여 DB에 저장 하여 관리할 수 있고, 해당 타임존으로 값을 변환하여 보여줄 수 있다.
  • 서버에서는 API호출 시 UTC로 내려줌
  • 프론트에서는 UTC를 사용자의 타임존으로 변환하여 화면으로 보여줌
• 표현 형태
• ISO 8601 포맷 문자열을 사용하고자 한다.
• ISO 는 데이터 교환을 다루는 국제 표준 방식이다.
• 2021-11-02T14:15:00+09:00 처럼 시간뒤에 timezone offset이 표시되어 있기 때문에 커뮤니케이션 미스 등으로 인한 실수의 염려가 적다.
• 사람이 읽기 쉽다.

참고

Java라면 ZoneDateTime 으로 관리할 수 있다.

  

    
    
      
     
  
import java.time.ZoneId;
import java.time.ZonedDateTime;

public class ConverTimeZone {
    public static void main(String[] args) {

        ZonedDateTime zonedDateTime = ZonedDateTime.now(); // 로컬 시각
        System.out.println(zonedDateTime); // 2021-11-01T17:46:21.938450+09:00[Asia/Seoul]

        ZoneId zoneId = ZoneId.of("America/Vancouver");
        System.out.println(ZonedDateTime.now(zoneId)); // 2021-11-01T01:46:21.940450300-07:00[America/Vancouver]

        System.out.println(ZoneId.getAvailableZoneIds()); // 약 600 여 개
        // [Asia/Aden, America/Cuiaba, Etc/GMT+9, Etc/GMT+8, Africa/Nairobi, ...] 

    }
}

레퍼런스

https://www.daleseo.com/java8-zoned-date-time/