포시코딩

해결 전 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시로 등록한 모습. loc..

개요 개발하다보면 날짜 시간 관련해서 time zone 문제를 다들 겪어봤을 것이다. 전 세계 시간에 대해서도 영점이 존재하고 한국 시간은 9시간을 빼줘야 영점에 맞춰지게 된다. 어떤 날짜 시간을 저장할 때 해당 국가의 시간이 아닌 위에서 말한 영점 시간에 맞춰져 저장이 되야 하는데 이유는 이 서비스가 그 나라뿐만 아니라 다른 나라에서도 접속이 가능할거고 시차가 존재할텐데 나는 9시에 저장했는데 내가 있는 나라보다 1시간 빠른 나라에서 동시에 저장했어도 8시에 저장하게 되는 일이 생기는 이유 때문이다. TypeORM에서 자동으로 만들어 넣어주는 createdAt, updatedAt도 자동으로 그 영점에 맞춰져 저장이 되는데 내가 모임 약속 시간이라는 schedule 컬럼에 대해 string으로 받아 Ty..

개요 내가 사용하는 테이블 컬럼의 속성은 다음과 같다. 여기서 createdAt, updatedAt은 데이터를 넣을 때 자동으로 넣는 시간이 들어간다. 하지만 time zone 문제로 인해 현재 시간보다 정확히 9시간 전의 시간으로 들어가게 되는데 문득 나는 여기서 pickup에 대한 시간은 사용자가 선택해서 넣는데 그럼 동일한 시간에 대해 pickup 시간만 다른거 아냐? 라는 생각이 들었다. 만약 그렇다면 api를 통해 받은 해당 테이블의 데이터에 대해 createdAt은 9시간을 더하고 pickup은 9시간을 안더한 값을 쓰는 어지러운 상황이 연출될 것이다. 일단 진짜 생각한대로 그런지 테스트 해보았다. 알게된 사실 데이터 넣는 시간에 맞춰 pickup 데이터도 동일하게 선택해 넣었는데 놀랍게도 알..

select now(); SET GLOBAL time_zone='+09:00'; SET time_zone='+09:00'; select now();