我们不需要对他们固执。 有时其他人不理解或不关心时间戳的好处； 事实上，后端可以处理任何格式。

这里我们引入@注解，可以方便的进行Date和Json的转换。

1）注解简介

@注解是由Java编写的开源工具包提供的，专门用于处理json数据。 默认用于处理json数据。

@，您可以在 JSON 和 java.util.Date 对象之间转换日期数据。 该注解提供了两个属性

用于设置日期格式，这个很容易理解；

用于设置时区。 我们在东八区。 如果我们不设置默认时区的话，就会和我们东八区相差8个小时。 例如，如果前端传输12点钟，则后端将得到20点钟。

2）前端将其传给后端

@注解在JSON和java.util.Date对象之间转换日期数据，因此前端参数必须是json格式才能@起作用。

如果单独使用@注解，前端参数只能放在body中，以json格式传输，如下所示

这时候后端需要通过实体类来接收（使用实体类要使用@注解）； 并且由于参数放在请求体中，因此接口需要使用@注解来解析参数。

并且可以看到，如果不设置@的时区，时间就会与前端传入的输入参数不匹配，会往后调8个小时。

3）后端返回前端

因为@注解是在JSON和java.util.Date对象之间进行日期数据的转换，所以后端从前端返回的Date也会被@转换成指定格式的json字符串。

也就是说，@注解也会对接口返回的时间进行格式化。

如上界面所示，调用结果如下

可以看到Date类型的返回值按照@注解指定的格式标准化为json字符串，符合预期；

并且不设置时区的时间提前8小时（所以使用@请设置时区）。

3.使用注解@1）注解简介

@是框架的fomat工具包提供的注解；

注释具有三个可以设置的属性，如下所示：

该注释的目的有两个：

首先是局限性。 如果前端传过来的参数不符合设定的格式，接口无法接收，会报格式转换错误。

二是转化。 对于符合格式的时间参数，@会将其转换为Date类型。

总结：@注解不需要设置时区。

2）前端将其传给后端

当后端使用@注解接收时间数据时，前端可以以form-data格式传输，如下图：

理论上后端使用@注解来接收时间数据，前端也可以传递json格式的参数，如下所示：

但在实际测试中，如果通过这种方式无法接收到参数，就会报如下错误：

error: Failed to parse Date value '2023-06-18 12:00:30': Cannot parse date "2023-06-18 12:00:30": while it seems to fit format 'yyyy-MM-dd'T'HH:mm:ss.SSSZ'

意思是：你传递的参数“格式错误”，所以Date转换失败。 正确的格式是“yyyy-MM-dd'T'HH:mm:ss.SSSZ”。

但是从截图中可以看到，我们设置的时间格式是这样的：

@DateTimeFormat(pattern = "yyyy-MM-dd HH")
private Date startTime;
@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private Date endTime;

而且，使用form-data类型传递参数时，已经成功接收，说明@属性设置没有问题。

那里有一条错误消息，所需的格式是 yyyy-MM-dd'T'HH:mm:ss.SSSZ。 我只能说：我看不懂，完全没有道理！

总结：@只能处理前端传递到后端的时间参数，对传输方式也有狭窄的限制。 它也无法处理从后端传递到前端的时间格式。 它也存在很多问题。 建议不要单独使用。 这个非常困难。 麻烦！ 4.@与@

@不仅可以约束前端传入的时间类型参数格式，还可以约束后端响应前端的时间类型参数格式； 可以设置时区，设置后前后端传输时间不会有错误。

@：

它只能约束前端输入参数时间类型的格式，不会修改原始日期对象的格式。 如果想获得想要的日期格式，需要自己手动转换；

如果单独使用@，到前端的响应时间会比实际时间晚8个小时（由于时区的原因，且无法设置时区）。

每个人都应该自己判断这两个注释哪个更好。

1）@和@一起使用

@比@好用多了，但是有一个问题：后端使用@处理时间参数，前端只能使用json格式进行传输。

这时候可以把@和@一起使用，这样以后@就会“覆盖”@的作用，但同时也支持前端通过form-data传递参数（@的功能）； 属于“1+1>2”！

补充：我刚刚测试了一下，并不是@完全“覆盖”了@的效果。 @对时间格式限制仍然有影响（如果格式不正确仍然会报错）。 6． 数据库中几个时间字段的描述及处理方法0.要点

以mysql为例，时间字段主要有日期、时间、、年份。 它们的存储空间和显示格式如下：

其中，最常用的是 和 。 另外，有些类型还可以用来存储时间，以方便查询。

我们分别来说一下。 当数据库使用这三种类型来存储时间时，后端应该如何传递值。

1、

我们先说最简单的。 该类型是普通整数。 它一般用于存储时间戳，即某个时间点与格林威治标准时间之间的秒数。 这个时间戳可以转换成时间（精确到秒）。 ）。

还可以存储时间的毫秒值，即某个时间与格林威治标准时间之间的毫秒值。 本例中，其值为13位，比时间戳多3位； 这使得记录的时间可以精确到毫秒值。

然而，为了简单起见，通常使用存储时间。 毫秒值需要手动转换，很少使用。 大多数时候，都会使用时间戳。

1）sql查询

使用存储时间时，SQL的增删改查非常方便，特别是对时间进行范围查询时。 与处理数字相同。 我个人觉得与其他类型相比非常方便；

2）后端接收前端传递的参数

因为前端从时间控件直接获取的时间值可以是数值类型，所以后端方法可以直接使用Long类型接收，这使得前端和后端处理非常方便； 后续接口之间不需要传递参数，直到放入SQL进行查询。 处理。

唯一需要注意的是，前端可以获取时间戳或者时间毫秒值，后端也可以获取； 为了效率和方便，双方必须统一。 一般来说，以数据库设计为准。 如果数据清单中包含时间戳，那么后续增删改查的前后端都要与时间戳进行交互。 否则需要手动处理，这是没有必要的。

3）后端返回前端

后端可以直接返回数值类型，前端可以处理； 如果前端需要后端处理，可以在类中写一个方法。

该方法的核心是先将Long类型转换为Date，然后将Date转换为对应的格式字符串。

long time = 1609296070000L;
Date date = new Date(time);
SimpleDateFormat sdf= new SimpleDateFormat("yyyy-MM-dd");
String dateStr=sdf.format(date);

上面说了，前端和后端都可以处理时间格式，但是为了省去大家的麻烦，一开始就必须约定好，大家都会使用时间戳，而不需要做额外的转换工作； 方便是使用存储时间的初衷。

2、

又称为时间戳（英文翻译为时间戳），它记录了某个时间到1970年1月1日0:00:00（格林威治标准时间）之间的秒数（注意是秒值，而不是毫秒值，总共 10 位数字，而不是 13 位数字）。 数据库占用4字节，比8字节和8字节都要小。 它包含第二个值的时间信息，这通常就足够了。

1）sql查询

使用类型来存储时间在查询时有点麻烦。