Foreword

Feeling java date type of design is really very bad, a lot of additional support framework for the date is not very perfect, I think so.
So many problems encountered during use.

Root of the problem

1: relates to the date type comprising a zone, different areas corresponding to different formats.
2: different business needs, at different times the required accuracy.
3: the same area, a variety of different time formats. As with 2020-1-1 2020-01-01

Experience and thinking

first step

 @ApiOperation(value = "日期参数测试")
    @RequestMapping(path = "datetest/test1", method = RequestMethod.POST)
    public Date dateTest2(
            @RequestBody Date testDate
    ) {
        return testDate;
    }

Corresponding Swagger shown below.
Here Insert Picture Description
From the corresponding mass participation can be seen that this date "2020-03-03T14: 26: 50.380Z" is not a familiar format. That if the direct use of "2020-03-3 12:00:00" as a parameter, it will report 400 (conversion) wrong. As shown below.

The second step

Then we would think, the format can be converted. Yes, and we can be a variety of ways to turn format. Spring preferred parameters directly support format conversion.
Here are ways to collect the I-line
1): global configuration mode, configure the system conversion date format configuration file, as follows

#配置日期格式
spring.jackson.date-format=yyyy-MM-dd HH:mm:ss
#日期的时区
spring.jackson.time-zone=GMT+8

2): By way of comment.

  @JsonFormat(pattern ="yyyy-MM-dd" ,timezone = "GMT-8")
  @DateTimeFormat(pattern = "yyyy-MM-dd")

Through the above, we can solve the problem of the format conversion, as shown below, the test passes.
Here Insert Picture Description
Ah, looks like the problem solved. but. . . If there is a demand, a short date field, a date field is too long? Well, the next toss.

third step

Yes, it can still be resolved, we can define a class by receiving all the parameters, and define the parameters specified as follows:

public class InputClass {
   // @ShortDate()
    @JsonFormat(pattern ="yyyy-MM-dd" ,timezone = "GMT-8")
    @DateTimeFormat(pattern = "yyyy-MM-dd")
    
    private Date attrDate;
    @JsonFormat(pattern ="yyyy-MM-dd hh:mm:ss" ,timezone = "GMT-8")
    @DateTimeFormat(pattern = "yyyy-MM-dd hh:mm:ss")
    private Date attrDate2;
    public Date getAttrDate() {
        return attrDate;
    }
    public void setAttrDate(Date attrDate) {
        this.attrDate = attrDate;
    }
    public Date getAttrDate2() {
        return attrDate2;
    }
    public void setAttrDate2(Date attrDate2) {
        this.attrDate2 = attrDate2;
    }
}

Ah, this is not a problem. But we can not help but think, is designated yyyy-MM-ddd types of fields, often transfer data format 2020-3-3, or will shine 400 error.
Cases, more than that, if you specify is yyyy-MM-dd hh: mm : ss format, incoming 2020-03-03 still being given.
Reason, cognition inside, with 2020-03-03 2020-3-3 should be the same. 2020-03-03 00:00:00 to 2020-03-03 should be equal. If you do this to support it? It is not the way did not? Then further reflection.

the fourth step

I stepped over the pit, do not just write their own interfaces to note that using other people to pay attention to the interface again.
Decided off pits, no longer use the Date data type in terms of parameters passed. Be replaced with string. If the date is the type of time, make their own judgment, can be checked according to the type of regular expression passed in what format, and then convert the perfect support yyyy-MM-dd format using the corresponding; yyyy-MM-dd hh: mm : ss; yyyy / MM / dd format coexist, the interface stronger.