首次安全更新中修复了83个漏洞

本地时间的输出非常“干净”，可直接用于显示。带时区的时间显示了该时间代表的是哪个时区的时间，毕竟不指定时区的时间是没有任何意义的。LocalXXX因为它具有时区无关性，因此它不能代表一个瞬间/时刻。

另外，关于LocalDateTime、OffsetDateTime、ZonedDateTime三者的跨时区转换问题，以及它们的详解，因为内容过多放在了下文专文阐述，保持关注。

读取字符串为JSR 310类型

一个独立的日期时间类型字符串如2021-05-05T18:00-04:00它是没有任何意义的，因为没有时区无法确定它代表那个瞬间，这是理论当然也适合JSR 310类型喽。

遇到一个日期时间格式字符串，要解析它一般有这两种情况：

1.不带时区/偏移量的字符串：要么不理它说转换不了，要么就约定一个时区(一般用系统默认时区)，使用LocalDateTime来解析
 

看来，偏移量是能精确到秒的哈，只不过一般来说精确到分钟已经到顶了。

设置默认时区

ZoneId并没有提供设置默认时区的方法，但是通过文章可知ZoneId获取默认时区底层依赖的是TimeZone.getDefault()方法，因此设置默认时区方式完全遵照TimeZone的方式即可(共三种方式，还记得吗?)。

让人恼火的夏令时

因为有夏令时规则的存在，让操作日期/时间的复杂度大大增加。但还好JDK尽量的屏蔽了这些规则对使用者的影响。因此：推荐使用时区(ZoneId)转换日期/时间，一般情况下不建议使用偏移量ZoneOffset去搞，这样就不会有夏令时的烦恼啦。

JSR 310时区相关性

java.util.Date类型它具有时区无关性，带来的弊端就是一旦涉及到国际化时间转换等需求时，使用Date来处理是很不方便的。

JSR 310解决了Date存在的一系列问题：对日期、时间进行了分开表示(LocalDate、LocalTime、LocalDateTime)，对本地时间和带时区的时间进行了分开管理。LocalXXX表示本地时间，也就是说是当前JVM所在时区的时间;ZonedXXX表示是一个带有时区的日期时间，它们能非常方便的互相完成转换。
 

虽然方法入参是TemporalAccessor，但是只接受带时区的类型，LocalXXX是不行的，使用时稍加注意。

ZoneOffset

距离格林威治/UTC的时区偏移量，例如+02:00。值得注意的是它继承自ZoneId，所以也可当作一个ZoneId来使用的，当然并不建议你这么去做，请独立使用。

时区偏移量是时区与格林威治/UTC之间的时间差。这通常是固定的小时数和分钟数。世界不同的地区有不同的时区偏移量。在ZoneId类中捕获关于偏移量如何随一年的地点和时间而变化的规则(主要是夏令时规则)，所以继承自ZoneId。

1、最小/最大偏移量：因为偏移量传入的是数字，这个是有限制的哦

 

（编辑：衡水站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!