Prisma TZ 이슈 해결(feat. prisma Date 타입지정)

AnyORM을 사용하다가 개인프로젝트에 새롭게 prisma를 도입했다. 
전체적으로 너무 만족스러웠지만, 고질적인 Timezone이슈가 있다는 것을 보고 어떻게 해결했는지 정리해본다.

prisma Date 타입지정 - DateTmie @db.Date

Mysql은 날짜관련 여러가지 타입을 제공하고 있지만, 내가 싶었던 날짜 형식은 Date("YYYY-MM-DD")였다.
Prisma는 기본적으로 모든 DateTime을 Date 오브젝트로 리턴하기 때문에, 이 부분을 설정해줘야 했다.(프리즈마 참고문서)

1. shema.prisma 설정

스키마에서 due_day라는 필드 타입을 아래처럼 설정해 주었다.

due_day DateTime @db.Date

 

 

2. TZ 이슈 발생

나의 서비스는 일정관리를 해주는 서비스였다. 오늘 할 일을 등록하고, 다시 조회 할 수 있다.

 

내 전반적인 계획은 아래와 같다.

오늘 할 일을 생성할 때, 프론트엔드에서 현재시간을 KST로 보내주면  DB에 UTC로 저장을 하고,
오늘 할 일을 조회 할 때에는 오늘 시간을 UTC로 변환해서 조회하면 되지 않을까!? 하는 계획이었다.

DB의 TZ은 UTC로 쓰는것이 일반적이기도 하고, 괜찮아 보였지만 Date타입이기에 문제가 생겼다.

 

예를 들어 보자.

내가 2023-10-25:00:00:01 분에 이벤트를 생성하여 DB에 저장하려 할 때, UTC로는 2023-10-24으로 저장이된다.

그럼 프론트엔드에서 2023-10-25에 생성한 이벤트를 조회 하려고 하면 어떻게 해야 할까?
2023-10-25 오전 9시 이후에 조회를 한다면 UTC로 변환(9시간 차감)을 해도, 여전히 10월 25일이기 때문에,
내가 원하는대로 DB에서 정상적으로 조회가 되지 않는다.

 

 

 

3. 해결방안

해결방안은 Date타입을 저장할 때에는 TZ을 신경쓰지 않고, 전달받은 날짜(KST기준)를 'YYYY-MM-DD' 형태로 저장을 하는 것이다.

위 그림에서 보이듯이 프론트엔드에서 "YYYY-MM-DD"형식으로 전달해주고, 백엔드에서는 해당 값을 그대로 DB에 넣어준다. 
하지만 이렇게 하면 prisma에서 ISO 8601 타입이 아니라고 하면서 에러가 발생한다. 

따라서 아래처럼 백엔드에서 한번 변환해주는 과정이 필요하다.

create(todo: CreateTodoListsDto) {
    todo.due_day = new Date(todo.due_day);
    const prismaDto = CreateTodoListsDto.toPrisma(todo);
    return this.repository.createTodoList(prismaDto);
}