日期和时间是计算机处理的重要数据,绝大部分程序的运行都要和时间打交道。本节我们将详细讲解Java程序如何正确处理日期和时间。
基本概念
日期是指某一天,它不是连续变化的,而应该被看作离散的。而时间有两种概念,一种是不带日期的时间,例如12:30:59;另一种是带日期的时间,例如2021-5-13 10:09:01,只有这种带日期的时间能唯一地确定某个时刻,不带日期的时间是无法确定一个唯一时刻的。
本地时间
当我们说当前时刻是2021年5月13日早上10:10时,我们说的实际上是本地时间,在国内就是北京时间。在这个时刻,如果地球上不同地方的人们同时看一眼手表,他们各自的本地时间是不同的。
所以,不同的时区,在同一时刻,本地时间是不同的。全球一共分为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,他们的时刻是相同的。时刻相同的意思就是,分别在两个时区的两个人,如果在这一刻通电话,他们各自报出自己手表的时间,虽然本地时间是不同的,但是这两个时间表示的时刻是相同的。
夏令时
所谓夏令时,就是夏天开始的时候,把时间往后拨一个小时,夏天结束的时候,再把时间往前拨一个小时。我们国家实行过一段夏令时,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对用户显示相应格式的内容。
小结
在编写日期和时间的程序前,我们要准确理解日期、时间和时刻的概念。
由于存在本地时间,我们需要理解时区的概念,并且必须牢记由于夏令时的存在,同一地区用GMT/UTC
和城市表示的时区可能导致时间不同。
计算机通过Locale来针对当地用户习惯格式化日期、时间、数字、货币等。
Date和Calender
在理解日期和时间的表示方式之前,我们先要理解数据的存储和展示。
当我们定义一个整型变量并赋值时:
1 |
|
编译器会把上述字符串(程序源码就是一个字符串)编译成字节码。在程序的运行期,变量n
指向的内存实际上是一个4字节区域:
1 |
|
注意到计算机内存除了二进制的0
/1
外没有其他任何格式。
当我们用System.out.println(n)
打印这个整数的时候,实际上println()
这个方法在内部把int
类型转换成String
类型,然后打印出字符串123400
。
1 |
|
由此可见,整数123400
只是数据的存储格式,而我们打印的各种各样字符串,是数据的展示格式。展示格式有多种形式,但本质上它就是一个转换方法。
理解了数据的存储和展示,我们回头看看以下几种日期和时间:
- 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秒。分别换算成伦敦,北京,纽约时间分别是:
1 |
|
因此,在计算机中只需要存储一个整数1574208900表示某一个时刻。当需要显示为某一地区的当地时间时,我们就把它格式化为一个字符串。
Epoch Time
又称为时间戳,在不同的编程语言中,会有几种存储方式:
- 以秒为单位的整数:1574208900,缺点是精度只能到秒;
- 以毫秒为单位的整数:1574208900123,最后3位表示毫秒数;
- 以秒为单位的浮点数:1574208900.123,小数点后面表示零点几秒。
而在Java程序中,时间戳通常是用long
类型的毫秒数,即:
1 |
|
转换成北京时间就是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类型的以毫秒表示的时间戳。
我们来看看Date的基本用法:
1 |
|
注意getYear()
返回的年份必须加上1900
,getMonth()
返回的月份是0
12月,所以要加1,而11
分别表示1getDate()
返回的日期范围是1
~`31`,又不能加1。
打印本地时区表示的日期和时间时,不同的计算机可能会有不同的结果。如果我们想要针对用户的偏好精确地控制日期和时间的格式,就可以使用SimpleDateFormat
对一个Date
进行转换。它用预定义的字符串表示格式化:
- yyyy:年
- MM:月
- dd: 日
- HH: 小时
- mm: 分钟
- ss: 秒
1 |
|
Date
对象有几个严重的问题:它不能转换时区,除了toGMTString()
可以按GMT+0:00
输出外,Date总是以当前计算机系统的默认时区为基础进行输出。此外,我们也很难对日期和时间进行加减,计算两个日期相差多少天,计算某个月第一个星期一的日期等。
Calender
Calendar
可以用于获取并设置年、月、日、时、分、秒,它和Date
比,主要多了一个可以做简单的日期和时间运算的功能。
我们来看Calendar
的基本用法:
1 |
|
注意到Calendar
获取年月日这些信息变成了get(int field)
,返回的年份不必转换,返回的月份仍然要加1,返回的星期要特别注意,1
~`7`分别表示周日,周一,……,周六。
Calendar
只有一种方式获取,即Calendar.getInstance()
,而且一获取到就是当前时间。如果我们想给它设置成特定的一个日期和时间,就必须先清除所有字段:
1 |
|
利用Calendar.getTime()
可以将一个Calendar
对象转换成Date
对象,然后就可以用SimpleDateFormat
进行格式化了。
TimeZone
利用Calendar
进行时区转换的步骤是:
- 清除所有字段;
- 设定指定时区;
- 设定日期和时间;
- 创建
SimpleDateFormat
并设定目标时区; - 格式化获取的
Date
对象(注意Date
对象无时区信息,时区信息存储在SimpleDateFormat
中)。
因此,本质上时区转换只能通过SimpleDateFormat
在显示的时候完成。
Calendar
也可以对日期和时间进行简单的加减,这里就不贴代码了。
LocalDateTime
从Java 8开始,java.time包提供了新的日期和时间API,主要涉及的类型有:
- 本地日期和时间:LocalDateTime,LocalDate,LocalTime
- 带时区的日期和时间:ZonedDateTime
- 时刻:Instant
- 时区:ZoneId,ZoneOffset
- 时间间隔:Duration
以及一套新的用于取代SimpleDataFormat的格式化类型DateTimeFormatter
。和旧的API相比,新API严格区分了时刻、本地日期、本地时间和带时区的日期时间,并且,对时间和日期运算更加方便。此外,新API修正了旧API不合理的常量设计:
- Month用1~12表示1月到12月
- Week的范围用1~7表示周一到周日
最后,新API的类型几乎全部是不变类型,可以放心使用不必担心被修改。
我们首先来看看最常用的LocalDateTime
,它表示一个本地日期和时间。
1 |
|
本地日期和时间通过now()获取到的总是以当前默认时区返回的,和旧API不同,LocalDateTime、LocalDate、LocalTime默认严格按照ISO 8601规定的日期和时间格式进行打印。
反过来,通过制定的日期和时间创建LocalDateTime可以通过of()
方法。
1 |
|
因为严格按照ISO 8601的格式,因此,将字符串转换为LocalDateTime就可以传入标准格式。
1 |
|
注意ISO 8601规定的日期和时间分隔符是T
。标准格式如下:
- 日期:yyyy-MM-dd
- 时间:HH:mm:ss
- 带毫秒的时间:HH:mm:ss.SSS
- 日期和时间:yyyy-MM-dd’T’HH:mm:ss
- 带毫秒的日期和时间:yyyy-MM-dd’T’HH:mm:ss.SSS
DateTimeFormatter
如果要自定义输出格式,或者要把一个非ISO 8601格式的字符串解析成LocalDateTime,可以使用新的DateTimeFormatter
。
1 |
|
LocalDateTime提供了对日期和时间进行加减的非常简单的链式调用。
1 |
|
注意到月份加减会自动调用日期,例如从2019-10-31
减去1个月得到的结果是2019-09-30
,因为9月没有31日。
对日期和时间进行调整则使用withXxx()
方法,例如:withHour(15)
会把10:11:12
变为15:11:12
:
- 调整年:withYear()
- 调整月:withMonth()
- 调整日:withDayOfMonth()
- 调整时:withHour()
- 调整分:withMinute()
- 调整秒:withSecond()
实际上,LocalDateTime还有一个通用的with()
方法允许我们做更复杂的运算。对于计算某个月第一个周日这样的问题,新的API可以轻松完成。
要判断两个LocalDateTime的先后,可以使用isBefore()
,isAfter()
方法,对于LocalDate和LocalTime类似。
注意到LocalDateTime无法与时间戳进行转换,因为它没有时区,无法确定某一时刻。后面我们介绍的ZonedDateTime
相当于LocalDateTime加时区的组合,它具有时区,可以与long表示的时间戳进行转换。
Duration和Period
Duration表示两个时刻之间的时间间隔,Period表示两个日期之间的天数。
1 |
|
注意到两个LocalDateTime之间的差值使用Duration表示,类似PT1235H10M30S
,表示1235小时10分钟30秒。两个LocalDate之间的差值用Period表示,类似P1M21D
,表示1个月21天。
Duration和Period的表示方法也符合ISO 8601的格式,它以P...T...
的形式表示,P...T
之间表示日期间隔,T
后面表示时间间隔。如果是PT...
的格式表示仅有时间间隔。利用ofXxx()
或者parse()
方法也可以直接创建Duration:
1 |
|
ZonedDateTime
LocalDateTime总是表示本地日期和时间,要表示一个带时区的日期和时间,我们就需要ZonedDateTime
。可以简单的把ZonedDateTime
理解为LocalDateTime
加ZoneId
。ZoneId
是java.time
引入的新的时区类,注意和旧的java.util.TimeZone
区分。
要创建一个ZonedDateTime对象,有以下几种方法,一种是通过now()
方法返回当前时间。
1 |
|
另一种方式是通过给一个LocalDateTime附加一个ZoneId,就可以变成ZonedDateTime。
1 |
|
以这种方式创建的ZonedDateTime,它的日期和时间与LocalDateTime相同,但附加的时区不同,因此是两个不同的时刻。
时区转换
要转换时区,首先我们需要有一个ZonedDateTime
对象,然后,通过withZoneSameInstant()
将关联时区转换到另一个时区,转换后日期和时间都会相应调整。
1 |
|
要特别注意,由于夏令时的存在,时区转换时不同日期转换的结果很可能是不同的。涉及到时区时,千万不要自己计算时差,否则难以正确处理夏令时。
有了ZonedDateTime,将其转换为本地时间就非常简单了。转换为LocalDateTime,直接丢弃了时区信息。
1 |
|
DateTimeFormatter
使用旧的Date
对象时,我们用SimpleDateFormat
进行格式化显示。使用新的LocalDateTime
或ZonedLocalDateTime
时,我们要进行格式化显示,就要使用DateTimeFormatter
。
和SimpleDateFormat
不同的是,DateTimeFormatter
不但是不变对象,它还是线程安全的。线程的概念我们会在后面涉及到。现在我们只需要记住:因为SimpleDateFormat
不是线程安全的,使用的时候,只能在方法内部创建新的局部变量。而DateTimeFormatter
可以只创建一个实例,到处引用。
创建DateTimeFormatter
时,我们仍然通过传入格式化字符串实现:
1 |
|
格式化字符串的使用方式与SimpleDateFormat
完全一致。
另一种创建DateTimeFormatter
的方法是,传入格式化字符串时,同时指定Locale
:
1 |
|
这种方式可以按照Locale
默认习惯格式化。我们来看实际效果。
1 |
|
当我们直接调用System.out.println()
对一个ZonedDateTime
或者LocalDateTime
实例进行打印的时候,实际上,调用的是它们的toString()
方法,默认的toString()
方法显示的字符串就是按照ISO 8601
格式显示的,我们可以通过DateTimeFormatter
预定义的几个静态变量来引用:
1 |
|
小结
对ZonedDateTime或LocalDateTime进行格式化,需要使用DateTimeFormmter类。
DateTimeFormatter可以通过格式化字符串和Locale对日期和字符串进行定制化输出。
Instant
我们讲过,计算机存储的当前时间本质上是一个不断递增的整数。Java提供的System.currentTimeMillis()
返回的就是以毫秒表示的当前时间戳。这个当前时间戳在java.time
中以Instant
类型表示,我们用Instant.now()
获取当前时间戳,效果与System.currentTimeMillis()
类似。Instant
表示高精度时间戳。
实际上,Instant内部只有两个核心字段:
1 |
|
一个是以秒为单位的时间戳,一个是更精确的纳秒精度。它和System.currentTimeMillis()
返回的long相比,只是多了更精确的纳秒。
即然Instant就是时间戳,那么,给它附加上一个时区,就可以创建出ZonedDateTime
。
可见,对于某一个时间戳,给它关联上制定的ZoneId,就得到了ZonedDateTime,继而可以获得对应时区的LocalDateTime。所以,LocalDateTime
,ZoneId
,Instant
,ZonedDateTime
和long
都可以互相转换。转换的时候,只需要留意long类型的单位是秒还是毫秒就行了。
最佳实践
由于Java提供了新旧两套日期和时间的API,除非涉及到遗留代码,否则我们应该坚持使用新的API。如果需要与遗留代码打交道,如何在新旧API之间互相转换呢?
旧API转新API
如果要把旧的Date和Calendar转换为新API对象,可以通过toInstant()
方法转换为Instant对象,再继续转换为ZonedDateTime。
1 |
|
从上面的代码还可以看到,旧的TimeZone
提供了一个toZoneId()
,可以把自己变成新的ZoneId
。
新API转旧API
如果要把新的ZonedDateTime转换为旧的API对象,只能借助long型时间戳做一个中转。
1 |
|
从上面的代码可以看到,新的ZoneId转换为旧的TimeZone,需要借助ZoneId.getId()
返回的String完成。
在数据库中存储日期和时间
除了旧的java.util.Date,我们还可以找到另一个java.sql.Date
,它继承自java.util.Date,但会自动忽略所有时间相关的信息。这个奇葩的设计原因要追溯到数据库的日期与时间类型。
在数据库中,也存在几种日期和时间类型:
DATETIME
:表示日期和时间DATE
:仅表示日期TIME
:仅表示时间TIMESTAMP
:和DATETIME类似,但是数据库在创建或者更新记录的时候同时修改TIMESTAMP
在使用Java程序操作数据库时,我们需要把数据库类型与Java类型映射起来。下表是数据库类型与Java新旧API的映射关系:
数据库 | 对应Java类(旧) | 对应Java类(新) |
---|---|---|
DATETIME | java.util.Date | LocalDateTime |
DATE | java.sql.Date | LocalDate |
TIME | java.sql.Time | LocalTime |
TIMESTAMP | java.sql.Timestamp | LocalDateTime |
实际上,在数据库中,我们需要存储的最常用的是时刻(Instant),因为有了时刻信息,就可以根据用户自己选择的时区显示正确的本地时间。所以,最好的方法是直接用长整数long表示,在数据库中存储为BIGINT
类型。
通过存储一个long型时间戳,我们可以编写一个timestampToString()
方法,非常简单地为不同用户以不同的偏好来显示不同的本地时间。
1 |
|
小结
处理日期和时间时,尽量使用新的java.time包。
在数据库中存储时间戳时,尽量使用long型时间戳,它具有省空间、效率高、不依赖数据库的优点。