Spring Boot JPA : Java 날짜/시간 데이터 타입과 JPA, MySQL 타임존의 관계

Java 타입과 MySQL 저장 타입별 분석 최종 결론

• 타임존이 필요한 시간을 저장할 때는 ZonedDateTime을 MySQL의 datetime에 저장하는 방식을 사용하자.
  • 장점: 다른 어떤 타임존 설정에도 영향받지 않는다.
  • 단점(아닐 수도): DB에는 항상 UTC 기준 시간으로 저장되고 조회된다.
• Java의 Date 타입은 DB 타임존과 DB 세션 타임존을 일치시켜서 MySQL의 timestamp에 저장해야 정확한 시간 값을 저장하고 조회할 수 있다.
• Java의 Calendar 타입은 DB 타임존과 DB 세션 타임존, Calendar 타임존을 일치시켜서 MySQL의 timestamp에 저장해야 정확한 시간 값을 저장하고 조회할 수 있다.
• Java의 LocalDateTime 타입은 시스템 기본 타임존과 DB 세션 타임존을 일치시켜서 datetime에 저장해야 저장하고 조회할 때 동일한 시간을 반환하며, DB에서 조회할 때도 동일한 시간(타임존에 의해 영향받지 않는..)을 조회할 수 있다.
• Java의 ZonedDateTime 타입은 MySQL의 datetime에 저장하면 시스템 기본 타임존, DB 타임존, DB 세션 타임존에 영향받지 않고 일관된 동작을 하며, 중간에 DB 타임존이 바뀌어도 아무 문제가 없다. 다만 DB에서 조회할 때의 값은 항상 UTC 시간 기준이라는 것을 유념하자.

종합

• Java의 Date 타입
  • 저장할 때
    • DB 세션 타임존만큼 오프셋을 더한 시간으로 insert 한다.
    • timestamp에 저장할 때, DB 타임존과 DB 세션 타임존이 일치해야 정확한 unix timestamp가 저장된다.
  • 조회할 때
    • DB 세션 타임존만큼 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장된 데이터는 DB 타임존을 변경하여 DB를 띄우면 오프셋을 더한 시간으로 조회된다.
  • 종합
    • Java의 Date 타입은 timestamp에 저장할 때는 DB 타임존과 DB 세션 타임존이 일치해야 정확한 unix timestamp가 저장되고 조회된다.
    • Java의 Date 타입은 datetime에 저장할 때는 DB 세션 타임존만큼 오프셋을 더한 시간이 insert 되므로 DB에 저장된 값은 타임존 오프셋이 반영된 값이라고 볼 수 있는데, DB 타임존을 다르게 해서 띄워도 저장된 datetime 값은 변경되지 않고 조회할 때도 그대로이므로 DB 타임존과 DB 세션 타임존을 맞춰도 DB 세션 타임존이 저장할 때와 다르면 잘못된 시간 값이 조회된다.
    • 결론은 Java의 Date 타입을 쓸 때는 DB 타임존과 DB 세션 타임존을 같게 해서 timestamp에 저장하고 조회하는게 안전하다. datetime에 저장한다면 DB 세션 타임존을 중간에 바꾸면 안된다.
• Java의 Calendar 타입
  • 저장할 때
    • Calendar 타임존만큼 오프셋을 더한 시간으로 insert 한다.
    • timestamp에 저장할 때, DB 타임존과 Calendar 타임존이 일치해야 정확한 unix timestamp가 저장된다.
  • 조회할 때
    • DB 세션 타임존만큼 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장된 데이터는 DB 타임존을 변경하여 DB를 띄우면 오프셋을 더한 시간으로 조회된다.
  • 종합
    • Java의 Calendar 타입은 timestamp에 저장할 때는 DB 타임존과 Calendar 타임존이 일치해야 정확한 unix timestamp가 저장되고, DB 타임존과 DB 세션 타임존이 일치해야 정확한 시간이 조회된다. 즉, DB 타임존, DB 세션 타임존, Calendar 타임존을 일치시켜야 한다.
    • Java의 Calendar 타입을 datetime에 저장할 때는 Calendar 타임존과 DB 세션 타임존의 차이가 저장할 때와 조회할 때 차이가 없어야 정상 데이터를 얻을 수 있다.
    • 결론은 Java의 Calendar 타입을 쓸 때는 DB 타임존과 Calendar 타임존, DB 세션 타임존을 일치시켜서 timestamp에 저장하고 조회하는게 안전하다. datetime에 저장하는 것은 나중에 뭔가 변경해야할 때 너무 헷갈릴 것 같다.
• Java의 LocalDateTime 타입
  • 저장할 때
    • 시스템 기본 타임존을 제거한 시간(타임존 오프셋을 뺀 시간)에 DB 세션 타임존을 반영한 시간(타임존 오프셋을 더한 시간)을 계산하여 insert 한다.
  • 조회할 때
    • 시스템 기본 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
    • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • 종합
    • 시스템 기본 타임존과 DB 세션 타임존이 같으면 insert 하는 값이 원래의 값과 동일한데, 이를 timestamp에 저장하면 타임존 값이 같이 저장되어 DB 타임존에 따라 시간의 변동이 생기기 때문에 더욱 헷갈릴 수 있다.
    • Java의 LocalDateTime 타입을 쓸 때에는 시스템 기본 타임존과 DB 세션 타임존을 일치시켜서 datetime에 저장하고 조회하는 것이 안전하다. 이렇게 해야 DB에서 직접 조회할 때도 같은 값을 얻을 수 있다.
• Java의 ZonedDateTime 타입
  • 저장할 때
    • 다른 타임존 설정 상관 없이 자신의 타임존 기준으로 UTC 시간을 계산하여 쿼리를 날린다.
    • 즉, timestamp에 저장할 때엔 DB 타임존에 맞게 시간이 보정되지 않기 때문에 제대로 된 unix timestamp를 저장할 수 없다.
  • 조회할 때
    • 시스템 기본 타임존에 영향 받지 않는다.
    • DB 세션 타임존에 영향 받지 않는다.
    • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • 종합
    • Java의 ZonedDateTime 타입은 timestamp에 저장할 때 DB 타임존이 UTC가 아니면 제대로 된 unix timestamp를 저장할 수 없다.
    • 결론, Java의 ZonedDateTime 타입을 datetime에 저장하고 조회하면 DB의 값은 항상 UTC 기준으로 저장되고, 저장하거나 조회할 때 어떤 타임존 설정에도 영향받지 않고 저장한 값 그대로 조회된다. 왠만하면 타임존까지 저장해야 하는 경우에는 ZonedDateTime을 datetime에 저장하는 방식을 사용하자.

테스트용 데이터

• +00:00 = 2024-12-23T02:12:34+00:00
• +09:00 = 2024-12-23T11:12:34+09:00

테스트 케이스

1. Calendar의 타임존: UTC, Seoul/Asia
2. 데이터의 타임존: +00:00, +09:00
3. Spring Boot 기본 타임존: UTC, Seoul/Asia
4. DB 세션 타임존: default(no), UTC, Seoul/Asia
5. DB 타임존: UTC, Seoul/Asia

공통 비교

• DB 세션 타임존을 지정하지 않으면 시스템 기본 타임존으로 지정된다.

저장할 때의 비교

• 공통 입력 데이터
  • 2024-12-23T02:12:34+00:00
  • 2024-12-23T11:12:34+09:00
  • unix_timestamp = 1734919954
• 쿼리에는 타임존 값이 들어가지 않는다.

저장 타입에 따른 차이

• JPA Entity에서 @Temporal(TemporalType.TIMESTAMP)으로 지정하여 MySQL의 timestamp에 저장하는 것과 아무 것도 지정하지 않고 MySQL의 datetime에 저장하는 것 사이에 실행 쿼리의 차이는 없다.

각 타임존 설정별 비교

• DB 타임존에 따른 차이
  • DB 타임존에 따른 실행 쿼리의 차이는 없다.
  • timestamp에 저장하는 경우, 타임존이 반영된 시간(타임존 오프셋이 더해진 시간)을 insert해야 제대로 된 unix timestamp가 저장된다.
    • 그래야 추후에 DB 타임존이 변경되거나 했을 때 원본 데이터를 신뢰할 수 있다.
  • datetime에 저장하는 경우, DB 타임존이 변경되어도 저장된 시간 값은 변경되지 않기 때문에 항상 동일한 타임존이 반영된 시간을 insert해야 제대로 된 시간 값이라고 볼 수 있다.
    • 타임존을 같이 저장하지 않기 때문에 UTC 시간으로 변경하여 저장해야 인지하는데 문제없지 않을까?
• DB 세션 타임존에 따른 차이
  • Java의 Date 타입과 LocalDateTime 타입은 DB 세션 타임존에 따라 타임존이 계산된 시간(타임존 오프셋이 더해진 시간)으로 쿼리를 날린다.
• 시스템 기본 타임존에 따른 차이
  • Java의 LocalDateTime 타입은 시스템 기본 타임존에 따라 타임존을 제거한 시간(타임존 오프셋을 뺀 시간)으로 쿼리를 날린다.
• Calendar 타임존에 따른 차이
  • Java의 Calendar 타입은 Calendar에 지정된 타임존에 따라 타임존이 계산된 시간(타임존 오프셋이 더해진 시간)으로 쿼리를 날린다.

각 Java 타입별 비교

• Java의 Date 타입
  • DB 세션 타임존에 따라 타임존을 반영한 시간(타임존 오프셋이 더해진 시간)으로 insert 한다.
  • 즉, Date 타입을 쓸 때엔, DB 타임존과 DB 세션 타임존이 일치해야 정상적인 데이터를 저장할 수 있다.
• Java의 Calendar 타입
  • Calendar 타임존에 따라 타임존을 반영한 시간(타임존 오프셋이 더해진 시간)으로 insert 한다.
  • 즉, Calendar 타입을 쓸 때엔, Calendar 타임존과 DB 타임존이 일치하면 정상적인 데이터를 저장할 수 있다.
• Java의 LocalDateTime 타입
  • 시스템 기본 타임존과 DB 세션 타임존을 반영하여, 시스템 기본 타임존 기준 DB 세션 타임존으로 변환했을 때의 시간을 계산하여 쿼리를 날린다.
  • 시스템 기본 타임존을 제거한 시간(타임존 오프셋을 뺀 시간)에 DB 세션 타임존을 반영한 시간(타임존 오프셋을 더한 시간)을 계산하여 insert 한다.
  • 예시1. 시스템 기본 타임존과 DB 세션 타임존이 같으면 그대로 쿼리를 날린다.
  • 예시2. 시스템 기본 타임존이 Asia/Seoul이고 DB 세션 타임존이 UTC이면 -9시간 하여 쿼리를 날린다.
  • 예시3. 시스템 기본 타임존이 UTC이고 DB 세션 타임존이 Asia/Seoul이면 +9시간 하여 쿼리를 날린다.
• Java의 ZonedDateTime 타입
  • 다른 타임존 설정 상관 없이 자신의 타임존 기준으로 UTC 시간을 계산하여 쿼리를 날린다.
  • 즉, timestamp에 저장할 때엔 DB 타임존에 맞게 시간이 보정되지 않기 때문에 제대로 된 unix timestamp를 저장할 수 없다.

조회할 때의 비교

타임존 설정별 비교

• 시스템 기본 타임존만 다른 경우
  • LocalDateTime에 저장한 것이, 시스템 기본 타임존이 Asia/Seoul인 것이 UTC인 것보다 +9시간 되어있다.
  • 정상: 타임존 값을 저장하지 않는 java 타입만 타임존 offset 만큼 영향을 받았다.
• DB 세션 타임존만 다른 경우
  • Java ZonedDateTime을 제외하고, DB 세션 타임존이 Asia/Seoul인 것이 UTC인 것보다 -9시간 되어있다.
• DB 타임존만 다른 경우
  • MySQL timestamp 타입에 저장한 것이, DB 타임존이 Asia/Seoul인 것이 UTC인 것보다 +9시간 되어있다.
• 아무런 영향을 받지 않은 것
  • ZonedDateTime을 MySQL의 datetime 타입에 저장한 것

Java 타입별 비교

• Java의 Date 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 Calendar 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 LocalDateTime 타입
  • 시스템 기본 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 ZonedDateTime 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존에 영향 받지 않는다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.

정상 값이 읽어와지는 것(DB의

• Date to timestamp
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=Asia/Seoul, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=UTC
  • DB 타임존=Asia/Seoul, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=Asia/Seoul
  • 정리: DB 타임존과 DB 세션 타임존이 일치하는 경우 정상
• Date to datetime
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=Asia/Seoul, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=Asia/Seoul, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • 정리: DB 세션 타임존이 UTC인 경우 정상
• Calendar to timestamp
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=Asia/Seoul, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=UTC
  • DB 타임존=Asia/Seoul, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=Asia/Seoul
  • 정리: DB 타임존과 DB 세션 타임존이 일치하는 경우 정상
• Calendar to datetime
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=Asia/Seoul, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=Asia/Seoul, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • 정리: DB 세션 타임존이 UTC인 경우 정상
• LocalDateTime to timestamp - DB 타임존과 DB 세션 타임존에 따라 시간 값이 바뀌기 때문에 무엇이 정상이라고 판단할 수 없다. 애초에 잘못된 저장 방식이다.
• LocalDateTime to datetime - DB의 값이 그대로 조회된 것 기준
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=Asia/Seoul, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=Asia/Seoul, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=Asia/Seoul
  • 정리: 시스템 기본 타임존과 DB 세션 타임존이 일치하는 경우 정상
• ZonedDateTime to timestamp
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=UTC, 시스템 기본 타임존=Asia/Seoul
  • DB 타임존=UTC, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=UTC
  • DB 타임존=UTC, DB 세션 타임존=Asia/Seoul, 시스템 기본 타임존=Asia/Seoul
  • 정리: DB 타임존이 UTC인 경우 정상
• ZonedDateTime to datetime
  • 모든 설정에서 정상

Java 타입과 MySQL 저장 타입별 비교

종합

• Java의 Date 타입
  • 저장할 때
    • DB 세션 타임존만큼 오프셋을 더한 시간으로 insert 한다.
    • timestamp에 저장할 때, DB 타임존과 DB 세션 타임존이 일치해야 정확한 unix timestamp가 저장된다.
  • 조회할 때
    • DB 세션 타임존만큼 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장된 데이터는 DB 타임존을 변경하여 DB를 띄우면 오프셋을 더한 시간으로 조회된다.
  • 종합
    • Java의 Date 타입은 timestamp에 저장할 때는 DB 타임존과 DB 세션 타임존이 일치해야 정확한 unix timestamp가 저장되고 조회된다.
    • Java의 Date 타입은 datetime에 저장할 때는 DB 세션 타임존만큼 오프셋을 더한 시간이 insert 되므로 DB에 저장된 값은 타임존 오프셋이 반영된 값이라고 볼 수 있는데, DB 타임존을 다르게 해서 띄워도 저장된 datetime 값은 변경되지 않고 조회할 때도 그대로이므로 DB 타임존과 DB 세션 타임존을 맞춰도 DB 세션 타임존이 저장할 때와 다르면 잘못된 시간 값이 조회된다.
    • 결론은 Java의 Date 타입을 쓸 때는 DB 타임존과 DB 세션 타임존을 같게 해서 timestamp에 저장하고 조회하는게 안전하다. datetime에 저장한다면 DB 세션 타임존을 중간에 바꾸면 안된다.
• Java의 Calendar 타입
  • 저장할 때
    • Calendar 타임존만큼 오프셋을 더한 시간으로 insert 한다.
    • timestamp에 저장할 때, DB 타임존과 Calendar 타임존이 일치해야 정확한 unix timestamp가 저장된다.
  • 조회할 때
    • DB 세션 타임존만큼 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장된 데이터는 DB 타임존을 변경하여 DB를 띄우면 오프셋을 더한 시간으로 조회된다.
  • 종합
    • Java의 Calendar 타입은 timestamp에 저장할 때는 DB 타임존과 Calendar 타임존이 일치해야 정확한 unix timestamp가 저장되고, DB 타임존과 DB 세션 타임존이 일치해야 정확한 시간이 조회된다. 즉, DB 타임존, DB 세션 타임존, Calendar 타임존을 일치시켜야 한다.
    • Java의 Calendar 타입을 datetime에 저장할 때는 Calendar 타임존과 DB 세션 타임존의 차이가 저장할 때와 조회할 때 차이가 없어야 정상 데이터를 얻을 수 있다.
    • 결론은 Java의 Calendar 타입을 쓸 때는 DB 타임존과 Calendar 타임존, DB 세션 타임존을 일치시켜서 timestamp에 저장하고 조회하는게 안전하다. datetime에 저장하는 것은 나중에 뭔가 변경해야할 때 너무 헷갈릴 것 같다.
• Java의 LocalDateTime 타입
  • 저장할 때
    • 시스템 기본 타임존을 제거한 시간(타임존 오프셋을 뺀 시간)에 DB 세션 타임존을 반영한 시간(타임존 오프셋을 더한 시간)을 계산하여 insert 한다.
  • 조회할 때
    • 시스템 기본 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
    • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
    • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • 종합
    • 시스템 기본 타임존과 DB 세션 타임존이 같으면 insert 하는 값이 원래의 값과 동일한데, 이를 timestamp에 저장하면 타임존 값이 같이 저장되어 DB 타임존에 따라 시간의 변동이 생기기 때문에 더욱 헷갈릴 수 있다.
    • Java의 LocalDateTime 타입을 쓸 때에는 시스템 기본 타임존과 DB 세션 타임존을 일치시켜서 datetime에 저장하고 조회하는 것이 안전하다. 이렇게 해야 DB에서 직접 조회할 때도 같은 값을 얻을 수 있다.
• Java의 ZonedDateTime 타입
  • 저장할 때
    • 다른 타임존 설정 상관 없이 자신의 타임존 기준으로 UTC 시간을 계산하여 쿼리를 날린다.
    • 즉, timestamp에 저장할 때엔 DB 타임존에 맞게 시간이 보정되지 않기 때문에 제대로 된 unix timestamp를 저장할 수 없다.
  • 조회할 때
    • 시스템 기본 타임존에 영향 받지 않는다.
    • DB 세션 타임존에 영향 받지 않는다.
    • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • 종합
    • Java의 ZonedDateTime 타입은 timestamp에 저장할 때 DB 타임존이 UTC가 아니면 제대로 된 unix timestamp를 저장할 수 없다.
    • 결론, Java의 ZonedDateTime 타입을 datetime에 저장하고 조회하면 DB의 값은 항상 UTC 기준으로 저장되고, 저장하거나 조회할 때 어떤 타임존 설정에도 영향받지 않고 저장한 값 그대로 조회된다. 왠만하면 타임존까지 저장해야 하는 경우에는 ZonedDateTime을 datetime에 저장하는 방식을 사용하자.

저장할 때

• Java의 Date 타입
  • DB 세션 타임존에 따라 타임존을 반영한 시간(타임존 오프셋이 더해진 시간)으로 insert 한다.
  • 즉, Date 타입을 쓸 때엔, DB 타임존과 DB 세션 타임존이 일치해야 정상적인 데이터를 저장할 수 있다.
• Java의 Calendar 타입
  • Calendar 타임존에 따라 타임존을 반영한 시간(타임존 오프셋이 더해진 시간)으로 insert 한다.
  • 즉, Calendar 타입을 쓸 때엔, Calendar 타임존과 DB 타임존이 일치하면 정상적인 데이터를 저장할 수 있다.
• Java의 LocalDateTime 타입
  • 시스템 기본 타임존과 DB 세션 타임존을 반영하여, 시스템 기본 타임존 기준 DB 세션 타임존으로 변환했을 때의 시간을 계산하여 쿼리를 날린다.
  • 시스템 기본 타임존을 제거한 시간(타임존 오프셋을 뺀 시간)에 DB 세션 타임존을 반영한 시간(타임존 오프셋을 더한 시간)을 계산하여 insert 한다.
  • 예시1. 시스템 기본 타임존과 DB 세션 타임존이 같으면 그대로 쿼리를 날린다.
  • 예시2. 시스템 기본 타임존이 Asia/Seoul이고 DB 세션 타임존이 UTC이면 -9시간 하여 쿼리를 날린다.
  • 예시3. 시스템 기본 타임존이 UTC이고 DB 세션 타임존이 Asia/Seoul이면 +9시간 하여 쿼리를 날린다.
• Java의 ZonedDateTime 타입
  • 다른 타임존 설정 상관 없이 자신의 타임존 기준으로 UTC 시간을 계산하여 쿼리를 날린다.
  • 즉, timestamp에 저장할 때엔 DB 타임존에 맞게 시간이 보정되지 않기 때문에 제대로 된 unix timestamp를 저장할 수 없다.

조회할 때

• Java의 Date 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 Calendar 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 LocalDateTime 타입
  • 시스템 기본 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
  • DB 세션 타임존만큼 타임존 오프셋을 뺀 시간을 반환한다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.
• Java의 ZonedDateTime 타입
  • 시스템 기본 타임존에 영향 받지 않는다.
  • DB 세션 타임존에 영향 받지 않는다.
  • timestamp에 저장한 경우 DB 타임존만큼 타임존 오프셋을 더한 시간을 반환한다.