日期与时间

学习目标

• 理解旧 API（Date/Calendar）的缺陷（可变、时区混乱、月份从 0）
• 掌握 java.time 体系：Instant/LocalDate/LocalDateTime/ZonedDateTime
• 区分时刻(Instant)、本地日期(LocalDate)、带时区时间(ZonedDateTime)
• 掌握 Period（日期-based）与 Duration（时间-based）的差异
• 理解格式化(DateTimeFormatter)与解析、不可变性带来的线程安全

日期与时间是计算机处理的重要数据。绝大部分程序的运行都要和时间打交道

基本概念

在计算机中，我们经常需要处理日期和时间。

日期是指某一天，它不是连续变化的，而是应该被看成离散的。

而时间有两种概念，一种是不带日期的时间，例如，12:30:59。另一种是带日期的时间，例如，2020-1-1 20:21:59，只有这种带日期的时间能唯一确定某个时刻，不带日期的时间是无法确定一个唯一时刻的。

本地时间

当我们说当前时刻是2019年11月20日早上8:15的时候，我们说的实际上是本地时间。在国内就是北京时间。在这个时刻，如果地球上不同地方的人们同时看一眼手表，他们各自的本地时间是不同的

所以，不同的时区，在同一时刻，本地时间是不同的。全球一共分为24个时区，伦敦所在的时区称为标准时区，其他时区按东／西偏移的小时区分，北京所在的时区是东八区。

时区

因为光靠本地时间还无法唯一确定一个准确的时刻，所以我们还需要给本地时间加上一个时区。时区有好几种表示方式。

一种是以 GMT 或者 UTC加时区偏移表示，例如：GMT+08:00 或者 UTC+08:00 表示东八区。

GMT 和 UTC 可以认为基本是等价的，只是 UTC 使用更精确的原子钟计时，每隔几年会有一个闰秒，我们在开发程序的时候可以忽略两者的误差，因为计算机的时钟在联网的时候会自动与时间服务器同步时间。

另一种是缩写，例如，CST表示China Standard Time，也就是中国标准时间。但是CST也可以表示美国中部时间Central Standard Time USA，因此，缩写容易产生混淆，我们尽量不要使用缩写。

最后一种是以洲／城市表示，例如，Asia/Shanghai，表示上海所在地的时区。特别注意城市名称不是任意的城市，而是由国际标准组织规定的城市。

因为时区的存在，东八区的2019年11月20日早上8:15，和西五区的2019年11月19日晚上19:15，他们的时刻是相同的：

时刻相同的意思就是，分别在两个时区的两个人，如果在这一刻通电话，他们各自报出自己手表上的时间，虽然本地时间是不同的，但是这两个时间表示的时刻是相同的。

夏令时

时区还不是最复杂的，更复杂的是夏令时。所谓夏令时，就是夏天开始的时候，把时间往后拨1小时，夏天结束的时候，再把时间往前拨1小时。我们国家实行过一段时间夏令时，1992 年就废除了，但是矫情的美国人到现在还在使用，所以时间换算更加复杂

因为涉及到夏令时，相同的时区，如果表示的方式不同，转换出的时间是不同的。我们举个栗子：

对于2019-11-20和2019-6-20两个日期来说，假设北京人在纽约：

• 如果以GMT或者UTC作为时区，无论日期是多少，时间都是19:00；

• 如果以国家／城市表示，例如America／NewYork，虽然纽约也在西五区，但是，因为夏令时的存在，在不同的日期，GMT时间和纽约时间可能是不一样的：

实行夏令时的不同地区，进入和退出夏令时的时间很可能是不同的。同一个地区，根据历史上是否实行过夏令时，标准时间在不同年份换算成当地时间也是不同的。因此，计算夏令时，没有统一的公式，必须按照一组给定的规则来算，并且，该规则要定期更新。

计算夏令时请使用标准库提供的相关类，不要试图自己计算夏令时。

本地化

在计算机中，通常使用Locale表示一个国家或地区的日期、时间、数字、货币等格式。Locale由语言_国家的字母缩写构成，例如，zh_CN表示中文+中国，en_US表示英文+美国。语言使用小写，国家使用大写。

对于日期来说，不同的 Locale，例如，中国和美国的表示方式如下：

• zh_CN：2016-11-30
• en_US：11/30/2016

计算机用 Locale 在日期、时间、货币和字符串之间进行转换。一个电商网站会根据用户所在的 Locale 对用户显示如下：

Date 和 Calendar

在计算机中，应该如何表示日期和时间呢？

我们经常看到的日期和时间表示方式如下：

• 2019-11-20 0:15:00 GMT+00:00
• 2019年11月20日8:15:00
• 11/19/2019 19:15:00 America/New_York

如果直接以字符串的形式存储，那么不同的格式，不同的语言会让表示方式非常繁琐。

在理解日期和时间的表示方式之前，我们先要理解数据的存储和展示。

当我们定义一个整型变量并赋值时：

int n = 123400;

编译器会把上述字符串（程序源码就是一个字符串）编译成字节码。在程序的运行期，变量n指向的内存实际上是一个4字节区域：

┌──┬──┬──┬──┐
│00│01│e2│08│
└──┴──┴──┴──┘ 

注意到计算机内存除了二进制的0/1外没有其他任何格式。上述十六机制是为了简化表示。

当我们用System.out.println(n)打印这个整数的时候，实际上println()这个方法在内部把int类型转换成String类型，然后打印出字符串123400。

类似的，我们也可以以十六进制的形式打印这个整数，或者，如果n表示一个价格，我们就以$123,400.00的形式来打印它：

import java.text.; import java.util.;

可见，整数123400是数据的存储格式，它的存储格式非常简单。而我们打印的各种各样的字符串，则是数据的展示格式。展示格式有多种形式，但本质上它就是一个转换方法：

String toDisplay(int n) { ... }

理解了数据的存储和展示，我们回头看看以下几种日期和时间：

• 2019-11-20 0:15:01 GMT+00:00
• 2019年11月20日8:15:01
• 11/19/2019 19:15:01 America/New_York

它们实际上是数据的展示格式，分别按英国时区、中国时区、纽约时区对同一个时刻进行展示。而这个“同一个时刻”在计算机中存储的本质上只是一个整数，我们称它为Epoch Time。

Epoch Time是计算从1970年1月1日零点（格林威治时区／GMT+00:00）到现在所经历的秒数，例如：

1574208900表示从1970年1月1日零点GMT时区到该时刻一共经历了1574208900秒，换算成伦敦、北京和纽约时间分别是：

1574208900 = 北京时间2019-11-20 8:15:00
           = 伦敦时间2019-11-20 0:15:00
           = 纽约时间2019-11-19 19:15:00

因此，在计算机中，只需要存储一个整数1574208900表示某一时刻。当需要显示为某一地区的当地时间时，我们就把它格式化为一个字符串：

String displayDateTime(int n, String timezone) { ... }

Epoch Time又称为时间戳，在不同的编程语言中，会有几种存储方式：

• 以秒为单位的整数：1574208900，缺点是精度只能到秒；
• 以毫秒为单位的整数：1574208900123，最后3位表示毫秒数；
• 以秒为单位的浮点数：1574208900.123，小数点后面表示零点几秒。

它们之间转换非常简单。而在Java程序中，时间戳通常是用long表示的毫秒数，即：

long t = 1574208900123L;

转换成北京时间就是2019-11-20T8:15:00.123。要获取当前时间戳，可以使用System.currentTimeMillis()，这是Java程序获取时间戳最常用的方法。

标准库API

我们再来看一下Java标准库提供的API。Java标准库有两套处理日期和时间的API：

• 一套定义在java.util这个包里面，主要包括Date、Calendar和TimeZone这几个类；
• 一套新的API是在Java 8引入的，定义在java.time这个包里面，主要包括LocalDateTime、ZonedDateTime、ZoneId等。

为什么会有新旧两套API呢？因为历史遗留原因，旧的API存在很多问题，所以引入了新的API。

那么我们能不能跳过旧的API直接用新的API呢？如果涉及到遗留代码就不行，因为很多遗留代码仍然使用旧的API，所以目前仍然需要对旧的API有一定了解，很多时候还需要在新旧两种对象之间进行转换。

本节我们快速讲解旧API的常用类型和方法。

Date

java.util.Date是用于表示一个日期和时间的对象，注意与java.sql.Date区分，后者用在数据库中。如果观察Date的源码，可以发现它实际上存储了一个long类型的以毫秒表示的时间戳：

public class Date implements Serializable, Cloneable, Comparable<Date> {

    private transient long fastTime;

    ...
}

我们来看Date的基本用法：

注意getYear()返回的年份必须加上1900，getMonth()返回的月份是011分别表示112月，所以要加1，而getDate()返回的日期范围是1~31，又不能加1。

打印本地时区表示的日期和时间时，不同的计算机可能会有不同的结果。如果我们想要针对用户的偏好精确地控制日期和时间的格式，就可以使用SimpleDateFormat对一个Date进行转换。它用预定义的字符串表示格式化：

• yyyy：年
• MM：月
• dd: 日
• HH: 小时
• mm: 分钟
• ss: 秒

我们来看如何以自定义的格式输出：

import java.text.; import java.util.;

Java的格式化预定义了许多不同的格式，我们以MMM和E为例：

import java.text.; import java.util.;

上述代码在不同的语言环境会打印出类似Sun Sep 15, 2019这样的日期。可以从JDK文档查看详细的格式说明。一般来说，字母越长，输出越长。以M为例，假设当前月份是9月：

• M：输出9
• MM：输出09
• MMM：输出Sep
• MMMM：输出September

Date对象有几个严重的问题：它不能转换时区，除了toGMTString()可以按GMT+0:00输出外，Date总是以当前计算机系统的默认时区为基础进行输出。此外，我们也很难对日期和时间进行加减，计算两个日期相差多少天，计算某个月第一个星期一的日期等。

Calendar

Calendar可以用于获取并设置年、月、日、时、分、秒，它和Date比，主要多了一个可以做简单的日期和时间运算的功能。

我们来看Calendar的基本用法：

注意到Calendar获取年月日这些信息变成了get(int field)，返回的年份不必转换，返回的月份仍然要加1，返回的星期要特别注意，1~7分别表示周日，周一，……，周六。

Calendar只有一种方式获取，即Calendar.getInstance()，而且一获取到就是当前时间。如果我们想给它设置成特定的一个日期和时间，就必须先清除所有字段：

import java.text.; import java.util.;

利用Calendar.getTime()可以将一个Calendar对象转换成Date对象，然后就可以用SimpleDateFormat进行格式化了。

TimeZone

Calendar和Date相比，它提供了时区转换的功能。时区用TimeZone对象表示：

时区的唯一标识是以字符串表示的ID，我们获取指定TimeZone对象也是以这个ID为参数获取，GMT+09:00、Asia/Shanghai都是有效的时区ID。要列出系统支持的所有ID，请使用TimeZone.getAvailableIDs()。

有了时区，我们就可以对指定时间进行转换。例如，下面的例子演示了如何将北京时间2019-11-20 8:15:00转换为纽约时间：

import java.text.; import java.util.;

可见，利用Calendar进行时区转换的步骤是：

1. 清除所有字段；
2. 设定指定时区；
3. 设定日期和时间；
4. 创建SimpleDateFormat并设定目标时区；
5. 格式化获取的Date对象（注意Date对象无时区信息，时区信息存储在SimpleDateFormat中）。

因此，本质上时区转换只能通过SimpleDateFormat在显示的时候完成。

Calendar也可以对日期和时间进行简单的加减：

import java.text.; import java.util.;

小结

计算机表示的时间是以整数表示的时间戳存储的，即Epoch Time，Java使用long型来表示以毫秒为单位的时间戳，通过System.currentTimeMillis()获取当前时间戳。

Java有两套日期和时间的API：

• 旧的Date、Calendar和TimeZone；
• 新的LocalDateTime、ZonedDateTime、ZoneId等。

分别位于java.util和java.time包中。

面试要点

1. 为什么 LocalDate 线程安全？ java.time 类型全部不可变(immutable)，无 setter，每次运算返回新对象。
2. Instant 与 LocalDateTime 区别？ Instant 是 UTC 时间轴上的时刻，无时区；LocalDateTime 不含时区信息，二者需通过 ZoneId 转换。
3. Period 与 Duration 区别？ Period 基于日期（年/月/日），Duration 基于时间（秒/纳秒）。
4. SimpleDateFormat 为何线程不安全？ 其内部 Calendar 可变，多线程共享会相互覆盖；应改用 DateTimeFormatter（不可变）。

版本差异(旧版 → Java 21)

继续阅读

• 上一章：包与命名空间
• 下一章：加密与安全