网上最完整的版本!彻底弄清 Java 如何处理 GMT/UTC 日期时间(如下所示)
ZoneId
它代表一个时区的ID,如Europe/Paris。它规定了一些规则可用于将一个Instant时间戳转换为本地日期/时间LocalDateTime。
上面说了时区ZoneId是包含有规则的,实际上描述偏移量何时以及如何变化的实际规则由java.time.zone.ZoneRules定义。ZoneId则只是一个用于获取底层规则的ID。之所以采用这种方法,是因为规则是由*定义的,并且经常变化,而ID是稳定的。
对于API调用者来说只需要使用这个ID(也就是ZoneId)即可,而需无关心更为底层的时区规则ZoneRules,和“*”同步规则的事是它领域内的事就交给它喽。如:夏令时这条规则是由各国*制定的,而且不同国家不同年一般都不一样,这个事就交由JDK底层的ZoneRules机制自行sync,使用者无需关心。
ZoneId在系统内是唯一的,它共包含三种类型的ID:
- 最简单的ID类型:ZoneOffset,它由’Z’和以’+‘或’-'开头的id组成。如:Z、+18:00、-18:00
- 另一种类型的ID是带有某种前缀形式的偏移样式ID,例如’GMT+2’或’UTC+01:00’。可识别的(合法的)前缀是’UTC’, ‘GMT’和’UT’
- 第三种类型是基于区域的ID(推荐使用)。基于区域的ID必须包含两个或多个字符,且不能以’UTC’、‘GMT’、‘UT’ '+‘或’-'开头。基于区域的id由配置定义好的,如Europe/Paris
概念说了一大推,下面给几个代码示例感受下吧。
1、获取系统默认的ZoneId:
@Test public void test1() { // JDK 1.8之前做法 System.out.println(TimeZone.getDefault()); // JDK 1.8之后做法 System.out.println(ZoneId.systemDefault()); } 输出: Asia/Shanghai sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=29,lastRule=null]
二者结果是一样的,都是Asia/Shanghai。因为ZoneId方法底层就是依赖TimeZone,如图:
2、指定字符串得到一个ZoneId:
@Test public void test2() { System.out.println(ZoneId.of("Asia/Shanghai")); // 报错:java.time.zone.ZoneRulesException: Unknown time-zone ID: Asia/xxx System.out.println(ZoneId.of("Asia/xxx")); }
很明显,这个字符串也是不能随便写的。那么问题来了,可写的有哪些呢?同样的ZoneId提供了API供你获取到所有可用的字符串id,有兴趣的同学建议自行尝试:
@Test public void test3() { ZoneId.getAvailableZoneIds(); }
3、根据偏移量得到一个ZoneId:
@Test public void test4() { ZoneId zoneId = ZoneId.ofOffset("UTC", ZoneOffset.of("+8")); System.out.println(zoneId); // 必须是大写的Z zoneId = ZoneId.ofOffset("UTC", ZoneOffset.of("Z")); System.out.println(zoneId); } 输出: UTC+08:00 UTC
这里第一个参数传的前缀,可用值为:“GMT”, “UTC”, or “UT”。当然还可以传空串,那就直接返回第二个参数ZoneOffset。若以上都不是就报错
注意:根据偏移量得到的ZoneId内部并无现成时区规则可用,因此对于有夏令营的国家转换可能出问题,一般不建议这么去做。
4、从日期里面获得时区:
@Test public void test5() { System.out.println(ZoneId.from(ZonedDateTime.now())); System.out.println(ZoneId.from(ZoneOffset.of("+8"))); // 报错:java.time.DateTimeException: Unable to obtain ZoneId from TemporalAccessor: System.out.println(ZoneId.from(LocalDateTime.now())); System.out.println(ZoneId.from(LocalDate.now())); }
虽然方法入参是TemporalAccessor,但是只接受带时区的类型,LocalXXX是不行的,使用时稍加注意。
ZoneOffset
距离格林威治/UTC的时区偏移量,例如+02:00。值得注意的是它继承自ZoneId,所以也可当作一个ZoneId来使用的,当然并不建议你这么去做,请独立使用。
时区偏移量是时区与格林威治/UTC之间的时间差。这通常是固定的小时数和分钟数。世界不同的地区有不同的时区偏移量。在ZoneId类中捕获关于偏移量如何随一年的地点和时间而变化的规则(主要是夏令时规则),所以继承自ZoneId。
1、最小/最大偏移量:因为偏移量传入的是数字,这个是有限制的哦
@Test public void test6() { System.out.println("最小偏移量:" + ZoneOffset.MIN); System.out.println("最小偏移量:" + ZoneOffset.MAX); System.out.println("中心偏移量:" + ZoneOffset.UTC); // 超出最大范围 System.out.println(ZoneOffset.of("+20")); } 输出: 最小偏移量:-18:00 最小偏移量:+18:00 中心偏移量:Z java.time.DateTimeException: Zone offset hours not in valid range: value 20 is not in the range -18 to 18
2、通过时分秒构造偏移量(使用很方便,推荐):
@Test public void test7() { System.out.println(ZoneOffset.ofHours(8)); System.out.println(ZoneOffset.ofHoursMinutes(8, 8)); System.out.println(ZoneOffset.ofHoursMinutesSeconds(8, 8, 8)); System.out.println(ZoneOffset.ofHours(-5)); // 指定一个精确的秒数 获取实例(有时候也很有用处) System.out.println(ZoneOffset.ofTotalSeconds(8 * 60 * 60)); } // 输出: +08:00 +08:08 +08:08:08 -05:00 +08:00
看来,偏移量是能精确到秒的哈,只不过一般来说精确到分钟已经到顶了。
设置默认时区
ZoneId并没有提供设置默认时区的方法,但是通过文章可知ZoneId获取默认时区底层依赖的是TimeZone.getDefault()方法,因此设置默认时区方式完全遵照TimeZone的方式即可(共三种方式,还记得吗?)。
让人恼火的夏令时
因为有夏令时规则的存在,让操作日期/时间的复杂度大大增加。但还好JDK尽量的屏蔽了这些规则对使用者的影响。因此:推荐使用时区(ZoneId)转换日期/时间,一般情况下不建议使用偏移量ZoneOffset去搞,这样就不会有夏令时的烦恼啦。
JSR 310时区相关性
java.util.Date类型它具有时区无关性,带来的弊端就是一旦涉及到国际化时间转换等需求时,使用Date来处理是很不方便的。
JSR 310解决了Date存在的一系列问题:对日期、时间进行了分开表示(LocalDate、LocalTime、LocalDateTime),对本地时间和带时区的时间进行了分开管理。LocalXXX表示本地时间,也就是说是当前JVM所在时区的时间;ZonedXXX表示是一个带有时区的日期时间,它们能非常方便的互相完成转换。
@Test public void test8() { // 本地日期/时间 System.out.println("================本地时间================"); System.out.println(LocalDate.now()); System.out.println(LocalTime.now()); System.out.println(LocalDateTime.now()); // 时区时间 System.out.println("================带时区的时间ZonedDateTime================"); System.out.println(ZonedDateTime.now()); // 使用系统时区 System.out.println(ZonedDateTime.now(ZoneId.of("America/New_York"))); // 自己指定时区 System.out.println(ZonedDateTime.now(Clock.systemUTC())); // 自己指定时区 System.out.println("================带时区的时间OffsetDateTime================"); System.out.println(OffsetDateTime.now()); // 使用系统时区 System.out.println(OffsetDateTime.now(ZoneId.of("America/New_York"))); // 自己指定时区 System.out.println(OffsetDateTime.now(Clock.systemUTC())); // 自己指定时区 }
运行程序,输出:
================本地时间================ 2021-01-17 09:18:40.703 2021-01-17T09:18:40.703 ================带时区的时间ZonedDateTime================ 2021-01-17T09:18:40.704+08:00[Asia/Shanghai] 2021-01-16T20:18:40.706-05:00[America/New_York] 2021-01-17T01:18:40.709Z ================带时区的时间OffsetDateTime================ 2021-01-17T09:18:40.710+08:00 2021-01-16T20:18:40.710-05:00 2021-01-17T01:18:40.710Z
本地时间的输出非常“干净”,可直接用于显示。带时区的时间显示了该时间代表的是哪个时区的时间,毕竟不指定时区的时间是没有任何意义的。LocalXXX因为它具有时区无关性,因此它不能代表一个瞬间/时刻。
另外,关于LocalDateTime、OffsetDateTime、ZonedDateTime三者的跨时区转换问题,以及它们的详解,因为内容过多放在了下文专文阐述,保持关注。
读取字符串为JSR 310类型
一个独立的日期时间类型字符串如2021-05-05T18:00-04:00它是没有任何意义的,因为没有时区无法确定它代表那个瞬间,这是理论当然也适合JSR 310类型喽。
遇到一个日期时间格式字符串,要解析它一般有这两种情况:
- 不带时区/偏移量的字符串:要么不理它说转换不了,要么就约定一个时区(一般用系统默认时区),使用LocalDateTime来解析
@Test public void test11() { String dateTimeStrParam = "2021-05-05T18:00"; LocalDateTime localDateTime = LocalDateTime.parse(dateTimeStrParam); System.out.println("解析后:" + localDateTime); } 输出: 解析后:2021-05-05T18:00
- 带时区字/偏移量的符串:
@Test public void test12() { // 带偏移量 使用OffsetDateTime String dateTimeStrParam = "2021-05-05T18:00-04:00"; OffsetDateTime offsetDateTime = OffsetDateTime.parse(dateTimeStrParam); System.out.println("带偏移量解析后:" + offsetDateTime); // 带时区 使用ZonedDateTime dateTimeStrParam = "2021-05-05T18:00-05:00[America/New_York]"; ZonedDateTime zonedDateTime = ZonedDateTime.parse(dateTimeStrParam); System.out.println("带时区解析后:" + zonedDateTime); } 输出: 带偏移量解析后:2021-05-05T18:00-04:00 带时区解析后:2021-05-05T18:00-04:00[America/New_York]
请注意带时区解析后这个结果:字符串参数偏移量明明是-05,为毛转换为ZonedDateTime后偏移量成为了-04呢???
这里是我故意造了这么一个case引起你的重视,对此结果我做如下解释:
如图,在2021.03.14 - 2021.11.07期间,纽约的偏移量是-4,其余时候是-5。本例的日期是2021-05-05处在夏令时之中,因此偏移量是-4,这就解释了为何你显示的写了-5最终还是成了-4。
JSR 310格式化
针对JSR 310日期时间类型的格式化/解析,有个专门的类java.time.format.DateTimeFormatter用于处理。
DateTimeFormatter也是一个不可变的类,所以是线程安全的,比SimpleDateFormat靠谱多了吧。另外它还内置了非常多的格式化模版实例供以使用,形如:
@Test public void test13() { System.out.println(DateTimeFormatter.ISO_LOCAL_DATE.format(LocalDate.now())); System.out.println(DateTimeFormatter.ISO_LOCAL_TIME.format(LocalTime.now())); System.out.println(DateTimeFormatter.ISO_LOCAL_DATE_TIME.format(LocalDateTime.now())); } <
上一篇: 本周最新文献 20220508