1월24일 - DB time zone

개요

내가 사용하는 테이블 컬럼의 속성은 다음과 같다.

여기서 createdAt, updatedAt은 데이터를 넣을 때 자동으로 넣는 시간이 들어간다.

하지만 time zone 문제로 인해 현재 시간보다 정확히 9시간 전의 시간으로 들어가게 되는데

 

문득 나는 여기서 pickup에 대한 시간은 사용자가 선택해서 넣는데 

그럼 동일한 시간에 대해 pickup 시간만 다른거 아냐? 라는 생각이 들었다.

 

만약 그렇다면 api를 통해 받은 해당 테이블의 데이터에 대해 

createdAt은 9시간을 더하고 pickup은 9시간을 안더한 값을 쓰는 어지러운 상황이 연출될 것이다.

 

일단 진짜 생각한대로 그런지 테스트 해보았다.

 

알게된 사실

데이터 넣는 시간에 맞춰 pickup 데이터도 동일하게 선택해 넣었는데

 

놀랍게도 알아서 9시간 전의 시간값으로 들어가고 있었다.

 

이로써 datetime 속성 컬럼에 대해 값을 넣을 때는 딱히 걱정을 할 필요가 없다는걸 알게 되었다.

 

그럼 데이터를 가져와 사용할 때 (프론트엔드에 뿌려줄 때)는 어떻게 할거냐 라는 의문이 들 수 있는데

JavaScript에서 제공하는 date 함수가 있다.

 

Date 객체에 대해 toLocal~ 함수를 사용하면 사용하는 해당 local에 맞춰 시간이 변경된다.

 

new Date().toLocaleString()
new Date().toLocaleDateString()
new Date().toLocaleTimeString()

위 상황에서는 console에서 바로 찍다보니 변경이 안되고 있는데

 

api를 통해 요청했을 때 받는 위의 값에 대해

 

const dateFormatter = (pickup) => {
  return new Date(pickup).toLocaleString();
}

이런 방법으로 출력시키면

 

오전 5시 57분이 아닌 오후 2시 57분으로 나오는걸 확인할 수 있다.

 

결론

위에서 알아낸 사실들을 통해 글로벌 서비스를 하게 되더라도 

백엔드와 프론트엔드에서 특별한 과정 없이도 해당 국가에 맞는 시간대를 오차 없이 보여줄 수 있을 것으로 판단된다.

 

항상 이렇게 시간차이가 나는 상황에 대해 고민이 많았고

실제로 사용할 때도 9시간을 직접 더해 사용하는 경우도 간간히 있었는데

이러면 다른 로컬에서 볼 때 오차가 또 생길 수 밖에 없을 것이다.

 

오늘 배운 내용을 알고 있었다면 굳이 그렇게 하지 않아도 됐을텐데 하는 생각이 든다.

이렇게 또 성장해버렸다는

 

+추가

 글을 쓰며 각 나라에 대해 어떻게 local 시간을 보여주는거지 라는 생각을 했었고

팀스터디를 하며 이러한 고민도 같이 해봤는데

다른분이 친절하게도 관련 내용을 검색해서 알려주셨다.

 

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#locale_identification_and_negotiation

Intl - JavaScript | MDN

 

Date의 toLocaleString 함수를 타고 들어가면 위와 같은 내용이 나오는데 

여기서 언급되는 Intl에서 관련 로직을 수행해주는 것으로 보인다.

 

국제화 API로서 날짜 및 시간 형식뿐만 아니라 언어 구분 문자열 비교, 숫자 형식 등도 지원해준다고 하니 

만약 국제화 서비스를 준비중이라면 꼭 확인해봐야 할 개체인 것 같다.