3월16일 - MySQL, TypeORM, RDS timezone 문제 [해결]

해결 전

3월 16일 11시 51분에

schedule은 3월 16일 13시로 저장

 

local

schedule, createdAt 둘 다 값 그대로 들어갔다.

 

RDS

schedule은 값 그대로, createdAt은 9시간 마이너스된 값이 들어감

 

local

schedule, createdAt 각각 9시간씩 마이너스

 

RDS

DB 값이 그대로 나오고 있음

 

해결 후

기존에 schedule에 대해 string으로 전달되어 

class-validator를 통해 강제로 date 타입으로 변환되는 값을 db에 넣었는데

 

new Date('날짜시간') 값으로 전달하여

강제 date 타입 변환 없이 db에 넣게끔 하니 정상적으로 동작되었다.

 

아래는 3월16일 13시에 

schedule을 3월16일 14시로 등록한 모습.

 

local

local은 여전히 넣은 값 그대로 들어가고 있다.

 

RDS

RDS는 9시간씩 마이너스되어 저장

 

local

local은 가져올 때 9시간을 뺀 상태로 가져온다.

 

RDS

RDS는 있는 그대로 가져온다. 

 

결과적으로 9시간 뺀 값이 가져와지는건 같지만 어디서 9시간이 빼지느냐가 중요한데

아마 내 local MySQL의 timezone이 KST로 되어 있어서 그런듯하다.

 

mysql 에 접속 후

 select @@global.time_zone, @@session.time_zone, @@system_time_zone;

위 명령어를 입력하면 

이렇게 KST로 나오는데 이게 원래는 UTC 여야 하는 상황.

 

RDS는 애초에 UTC라서 문제가 될 게 없었던 듯 함.

저걸 UTC로 바꿔보려고 이리저리 찾아보는데 MySQL을 처음에 세팅할 때 이상하게 했는지

설정파일이 도통 보이질 않는다.. 

 

아무튼 전날에는 이걸 해결하려고 아래와 같은 시행착오를 겪었다.

 

1. FE에서 9시간 빼진 값을 전달

-> 현재 시간보다 이전의 값들은 class-validator를 통해 400 에러 리턴

-> 위 코드를 없애서 통과되게 해도 string으로 전달되었기 때문에 자동으로 변환시켜주질 않음

 

2. RDS의 timezone을 한국 시간으로 변경

-> 라이브 서버에서 기존의 잘 되던 다른 기능들의 createdAt, updatedAt이 

9시간 자동으로 빼고 더하는게 망가져 이상해짐

-> 1번의 코드와 같이 적용 시 9시간 빼진 값에 9시간을 또 빼서 18시간이 빼지는 현상 발생 (끄악)

 

아무튼 그냥 string으로 전달되던 값을 new Date()안에 넣어주기만 하면 됐었다니

알아보는 과정이 복잡했지 해결 방법은 너무너무 단순해서 허탈한 느낌마저 들었다.

 

local에서 사용하는 MySQL의 timezone을 UTC로 하냐 KST로 하냐가 

팀원들과 토론 주제가 될 것 같은데

 

아무래도 UTC로 해야 나중에 RDS를 쓰거나 할 경우를 대비해 제대로 코드를 만들 수 있지 않을까 싶다.

 

제발 미래의 나야

이렇게 막혔던 걸 기억해서 나중에 timezone 문제가 또 발생하지 않게 

코드를 처음부터 고려해 잘 만들자