@JsonFromat, @DateTimeForamt이 계속 헷갈린다!

@JsonFormat, @DateTimeFormat Request일 경우

---

@ModelAttribte, @RequestParam

두 애노테이션은 요청 query string(message body form Data 동일)에 대한 값을 매핑해준다.

• @DateTImeFormat을 사용한다.
• @JsonFormat은 사용할 수 없다.

@RequestBody

이번에는 message body JSON 요청이 올 경우이다.

• @DateTimeFormat을 사용한다.
• @JsonFormat도 사용한다.

우선 순위

• @JsonFormat이 우선 순위를 갖는다.
• @JsonFormat이 틀렸다면, @DateTimeFormat이 맞아도 실패한다.
  @JsonFormat이 우선 순위이기 때문에 당연한다.

@JsonFormat, @DateTimeFormat Response일 경우

---

@ResponseBody

message body에 JSON을 리턴할 때 사용한다.

• @JsonFormat만 사용 가능하다.

@JsonFormat만 가능한 이유

@JsonFormat은 jackson의 애노테이션이고, @DateTimeFormat은 Spring 애노테이션이다.

@JsonFormat은 직렬화, 역직렬화를 담당한다. 이외에는 아무것도 하지 않는다.

그래서 @ModelAttribute, @RequestParam은 JSON이 아니기 때문에 @JsonFormat은 사용할 수가 없는 것이다.

즉, 역직렬화 시 Spring은 기본 JSON 컨버터를 Jackson으로 갖기 때문에 @RequestBody에서는 두 가지 모두 사용 가능한 것이고,

직렬화 시에는 오로지 jackson 라이브러리만 사용하기 때문에 Spring을 모르는 jackson은 @JsonFormat만 사용이 가능한 것이다.

SpringBoot 2.x VS SpringBoot 1.x

---

2.0부터는 JSR310이 기본 의존성이지만 1.x에서는 별도로 추가 해주어야 한다.

그렇지 않으면 JSON parse error가 난다.

JSR310(Date and Time API, Java Specification Requests)이란?

---

Java SE의 날짜 API인 Date, Calendar 클래스를 대체하기 위한 API이다.

Java8부터 JSR310이 적용 되어서 LocalDateTime과 DateTime을 사용하게 된다.

oracle 문서 내용

2.1 Please describe the proposed Specification:

This JSR will provide a new and improved date and time API for Java. The main goal is to build upon the lessons learned from the first two APIs (Date and Calendar) in Java SE, providing a more advanced and comprehensive model for date and time manipulation.

The new API will be targeted at all applications needing a data model for dates and times. This model will go beyond classes to replace Date and Calendar, to include representations of date without time, time without date, durations and intervals. This will raise the quality of application code. For example, instead of using an int to store a duration, and javadoc to describe it as being a number of days, the date and time model will provide a class defining it unambiguously.

The new API will also tackle related date and time issues. These include formatting and parsing, taking into account the ISO8601 standard and its implementations, such as XML. In addition, the areas of serialization and persistence will be considered.

The final goal of the new API is to be simple to use. The API will need to contain some powerful features, but these must not be allowed to obscure the standard use cases. Part of being easy to use includes interaction with the existing Date and Calendar classes, something that will be a key focus of the Expert Group.

2.5 What need of the Java community will be addressed by the proposed specification?

Currently Java SE has two separate date and time APIs - java.util.Date and java.util.Calendar. Both APIs are consistently described as difficult to use by Java developers on weblogs and forums. Notably, both use a zero-index for months, which is a cause of many bugs. Calendar has also suffered from many bugs and performance issues over the years, primarily due to storing its state in two different ways internally.

One classic bug (4639407) prevented certain dates from being created in a Calendar object. A sequence of code could be written that could create a date in some years but not in others, having the effect of preventing some users from entering their correct birth dates. This was caused by the Calendar class only allowing a daylight savings time gain of one hour in summer, when historically it was plus 2 hours around the time of the second world war. While this bug is now fixed, if at some point in the future a country chose to introduce a daylight savings time gain of plus three hours in summer, then the Calendar class would again be broken.

The current Java SE API also suffers in multi-threaded environments. Immutable classes are known to be inherently thread-safe as their state cannot change. However, both Date and Calendar are mutable, which requires programmers to consider cloning and threading explicitly. In addition, the lack of thread-safety in DateTimeFormat is not widely known, and has been the cause of many hard to track down threading issues.

As well as the problems with the classes that Java SE has for datetime, it has no classes for modelling other concepts. Non-time-zone dates or times, durations, periods and intervals have no class representation in Java SE. As a result, developers frequently use an int to represent a duration of time, with javadoc specifying the unit.

The lack of a comprehensive date and time model also results in many common operations being trickier than they should be. For example, calculating the number of days between two dates is a particularly hard problem at present.

This JSR will tackle the problem of a complete date and time model, including dates and times (with and without time zones), durations and time periods, intervals, formatting and parsing.

jackson에서는 이를 맞춰서 라이브러리를 지원한다.

참고

---

https://jojoldu.tistory.com/361

https://mvnrepository.com/artifact/com.fasterxml.jackson.datatype/jackson-datatype-jsr310/2.9.7

https://jcp.org/en/jsr/detail?id=310

https://sejoung.github.io/2018/06/2018-06-21-JSR310/#JSR-310-Date-and-Time-API