目录
Date和Calendar
标准库API
Date
Calendar
TimeZone
小结
LocalDateTime 使用
LocalDateTime
DateTimeFormatter
Duration和Period
小结
ZonedDateTime
时区转换
练习
小结
DateTimeFormatter
小结
Instant
小结
最佳实践 - Date与LocaDate转化
旧API转新API
新API转旧API
在数据库中存储日期和时间
小结
在计算机中,应该如何表示日期和时间呢?
我们经常看到的日期和时间表示方式如下:
如果直接以字符串的形式存储,那么不同的格式,不同的语言会让表示方式非常繁琐。
在理解日期和时间的表示方式之前,我们先要理解数据的存储和展示。
当我们定义一个整型变量并赋值时:
int n =123400;
编译器会把上述字符串(程序源码就是一个字符串)编译成字节码。在程序的运行期,变量n
指向的内存实际上是一个4字节区域:
┌──┬──┬──┬──┐
│00│01│e2│08│
└──┴──┴──┴──┘
注意到计算机内存除了二进制的0
/1
外没有其他任何格式。上述十六机制是为了简化表示。
当我们用System.out.println(n)
打印这个整数的时候,实际上println()
这个方法在内部把int
类型转换成String
类型,然后打印出字符串123400
。
类似的,我们也可以以十六进制的形式打印这个整数,或者,如果n
表示一个价格,我们就以$123,400.00
的形式来打印它:
可见,整数123400
是数据的存储格式,它的存储格式非常简单。而我们打印的各种各样的字符串,则是数据的展示格式。展示格式有多种形式,但本质上它就是一个转换方法:
String toDisplay(int n){...}
理解了数据的存储和展示,我们回头看看以下几种日期和时间:
它们实际上是数据的展示格式,分别按英国时区、中国时区、纽约时区对同一个时刻进行展示。而这个“同一个时刻”在计算机中存储的本质上只是一个整数,我们称它为Epoch Time
。
Epoch Time
是计算从1970年1月1日零点(格林威治时区/GMT+00:00)到现在所经历的秒数,例如:
1574208900
表示从从1970年1月1日零点GMT时区到该时刻一共经历了1574208900秒,换算成伦敦、北京和纽约时间分别是:
1574208900=北京时间2019-11-208:15:00
=伦敦时间2019-11-200:15:00
=纽约时间2019-11-1919:15:00
因此,在计算机中,只需要存储一个整数1574208900
表示某一时刻。当需要显示为某一地区的当地时间时,我们就把它格式化为一个字符串:
String displayDateTime(int n,String timezone){...}
Epoch Time
又称为时间戳,在不同的编程语言中,会有几种存储方式:
它们之间转换非常简单。而在Java程序中,时间戳通常是用long
表示的毫秒数,即:
long t =1574208900123L;
转换成北京时间就是2019-11-20T8:15:00.123
。要获取当前时间戳,可以使用System.currentTimeMillis()
,这是Java程序获取时间戳最常用的方法。
我们再来看一下Java标准库提供的API。Java标准库有两套处理日期和时间的API:
java.util
这个包里面,主要包括Date
、Calendar
和TimeZone
这几个类;java.time
这个包里面,主要包括LocalDateTime
、ZonedDateTime
、ZoneId
等。为什么会有新旧两套API呢?因为历史遗留原因,旧的API存在很多问题,所以引入了新的API。
那么我们能不能跳过旧的API直接用新的API呢?如果涉及到遗留代码就不行,因为很多遗留代码仍然使用旧的API,所以目前仍然需要对旧的API有一定了解,很多时候还需要在新旧两种对象之间进行转换。
本节我们快速讲解旧API的常用类型和方法。
java.util.Date
是用于表示一个日期和时间的对象,注意与java.sql.Date
区分,后者用在数据库中。如果观察Date的源码,可以发现它实际上存储了一个long类型的以毫秒表示的时间戳:
publicclassDateimplementsSerializable,Cloneable,Comparable{
privatetransientlong fastTime;
...
}
我们来看Date的基本用法:
注意getYear()
返回的年份必须加上1900
,getMonth()
返回的月份是0
~11
分别表示1~12月,所以要加1,而getDate()
返回的日期范围是1
~31
,又不能加1。
打印本地时区表示的日期和时间时,不同的计算机可能会有不同的结果。如果我们想要针对用户的偏好精确地控制日期和时间的格式,就可以使用SimpleDateFormat
对一个Date
进行转换。它用预定义的字符串表示格式化:
我们来看如何以自定义的格式输出:
Java的格式化预定义了许多不同的格式,我们以MMM
和E
为例:
上述代码在不同的语言环境会打印出类似Sun Sep 15, 2019
这样的日期。可以从JDK文档查看详细的格式说明。一般来说,字母越长,输出越长。以M
为例,假设当前月份是9月:
M
:输出9
MM
:输出09
MMM
:输出Sep
MMMM
:输出September
Date
对象有几个严重的问题:它不能转换时区,除了toGMTString()
可以按GMT+0:00
输出外,Date总是以当前计算机系统的默认时区为基础进行输出。此外,我们也很难对日期和时间进行加减,计算两个日期相差多少天,计算某个月第一个星期一的日期等。
Calendar
可以用于获取并设置年、月、日、时、分、秒,它和Date
比,主要多了一个可以做简单的日期和时间运算的功能。
我们来看Calendar
的基本用法:
注意到Calendar
获取年月日这些信息变成了get(int field)
,返回的年份不必转换,返回的月份仍然要加1,返回的星期要特别注意,1
~7
分别表示周日,周一,……,周六。
Calendar
只有一种方式获取,即Calendar.getInstance()
,而且一获取到就是当前时间。如果我们想给它设置成特定的一个日期和时间,就必须先清除所有字段:
利用Calendar.getTime()
可以将一个Calendar
对象转换成Date
对象,然后就可以用SimpleDateFormat
进行格式化了。
Calendar
和Date
相比,它提供了时区转换的功能。时区用TimeZone
对象表示:
时区的唯一标识是以字符串表示的ID,我们获取指定TimeZone
对象也是以这个ID为参数获取,GMT+09:00
、Asia/Shanghai
都是有效的时区ID。要列出系统支持的所有ID,请使用TimeZone.getAvailableIDs()
。
有了时区,我们就可以对指定时间进行转换。例如,下面的例子演示了如何将北京时间2019-11-20 8:15:00
转换为纽约时间:
可见,利用Calendar
进行时区转换的步骤是:
SimpleDateFormat
并设定目标时区;Date
对象(注意Date
对象无时区信息,时区信息存储在SimpleDateFormat
中)。因此,本质上时区转换只能通过SimpleDateFormat
在显示的时候完成。Calendar
也可以对日期和时间进行简单的加减:
计算机表示的时间是以整数表示的时间戳存储的,即Epoch Time,Java使用long
型来表示以毫秒为单位的时间戳,通过System.currentTimeMillis()
获取当前时间戳。
Java有两套日期和时间的API:
分别位于java.util
和java.time
包中。
从Java 8开始,java.time
包提供了新的日期和时间API,主要涉及的类型有:
LocalDateTime
,LocalDate
,LocalTime
;ZonedDateTime
;Instant
;ZoneId
,ZoneOffset
;Duration
。以及一套新的用于取代SimpleDateFormat
的格式化类型DateTimeFormatter
。
和旧的API相比,新API严格区分了时刻、本地日期、本地时间和带时区的日期时间,并且,对日期和时间进行运算更加方便。
此外,新API修正了旧API不合理的常量设计:
最后,新API的类型几乎全部是不变类型(和String类似),可以放心使用不必担心被修改。
我们首先来看最常用的LocalDateTime
,它表示一个本地日期和时间:
本地日期和时间通过now()获取到的总是以当前默认时区返回的,和旧API不同,LocalDateTime
、LocalDate
和LocalTime
默认严格按照ISO 8601规定的日期和时间格式进行打印。
上述代码其实有一个小问题,在获取3个类型的时候,由于执行一行代码总会消耗一点时间,因此,3个类型的日期和时间很可能对不上(时间的毫秒数基本上不同)。为了保证获取到同一时刻的日期和时间,可以改写如下:
LocalDateTime dt = LocalDateTime.now(); // 当前日期和时间
LocalDate d = dt.toLocalDate(); // 转换到当前日期
LocalTime t = dt.toLocalTime(); // 转换到当前时间
反过来,通过指定的日期和时间创建LocalDateTime
可以通过of()
方法:
// 指定日期和时间:
LocalDate d2 = LocalDate.of(2019, 11, 30); // 2019-11-30, 注意11=11月
LocalTime t2 = LocalTime.of(15, 16, 17); // 15:16:17
LocalDateTime dt2 = LocalDateTime.of(2019, 11, 30, 15, 16, 17);
LocalDateTime dt3 = LocalDateTime.of(d2, t2);
因为严格按照ISO 8601的格式,因此,将字符串转换为LocalDateTime
就可以传入标准格式:
LocalDateTime dt = LocalDateTime.parse("2019-11-19T15:16:17");
LocalDate d = LocalDate.parse("2019-11-19");
LocalTime t = LocalTime.parse("15:16:17");
注意ISO 8601规定的日期和时间分隔符是T
。标准格式如下:
如果要自定义输出的格式,或者要把一个非ISO 8601格式的字符串解析成LocalDateTime
,可以使用新的DateTimeFormatter
:
LocalDateTime
提供了对日期和时间进行加减的非常简单的链式调用:
注意到月份加减会自动调整日期,例如从2019-10-31
减去1个月得到的结果是2019-09-30
,因为9月没有31日。
对日期和时间进行调整则使用withXxx()
方法,例如:withHour(15)
会把10:11:12
变为15:11:12
:
示例代码如下:
同样注意到调整月份时,会相应地调整日期,即把2019-10-31
的月份调整为9
时,日期也自动变为30
。
实际上,LocalDateTime
还有一个通用的with()
方法允许我们做更复杂的运算。例如:
对于计算某个月第1个周日这样的问题,新的API可以轻松完成。
要判断两个LocalDateTime
的先后,可以使用isBefore()
、isAfter()
方法,对于LocalDate
和LocalTime
类似:
注意到LocalDateTime
无法与时间戳进行转换,因为LocalDateTime
没有时区,无法确定某一时刻。后面我们要介绍的ZonedDateTime
相当于LocalDateTime
加时区的组合,它具有时区,可以与long
表示的时间戳进行转换。
Duration
表示两个时刻之间的时间间隔。另一个类似的Period
表示两个日期之间的天数:
注意到两个LocalDateTime
之间的差值使用Duration
表示,类似PT1235H10M30S
,表示1235小时10分钟30秒。而两个LocalDate
之间的差值用Period
表示,类似P1M21D
,表示1个月21天。
Duration
和Period
的表示方法也符合ISO 8601的格式,它以P…T…
的形式表示,P…T
之间表示日期间隔,T
后面表示时间间隔。如果是PT…
的格式表示仅有时间间隔。利用ofXxx()
或者parse()
方法也可以直接创建Duration
:
Duration d1 = Duration.ofHours(10); // 10 hours
Duration d2 = Duration.parse("P1DT2H3M"); // 1 day, 2 hours, 3 minutes
有的童鞋可能发现Java 8引入的java.time
API。怎么和一个开源的Joda Time很像?难道JDK也开始抄袭开源了?其实正是因为开源的Joda Time设计很好,应用广泛,所以JDK团队邀请Joda Time的作者Stephen Colebourne共同设计了java.time
API。
Java 8引入了新的日期和时间API,它们是不变类,默认按ISO 8601标准格式化和解析;
使用LocalDateTime
可以非常方便地对日期和时间进行加减,或者调整日期和时间,它总是返回新对象;
使用isBefore()
和isAfter()
可以判断日期和时间的先后;
使用Duration
和Period
可以表示两个日期和时间的“区间间隔”。
LocalDateTime
总是表示本地日期和时间,要表示一个带时区的日期和时间,我们就需要ZonedDateTime
。
可以简单地把ZonedDateTime
理解成LocalDateTime
加ZoneId
。ZoneId
是java.time
引入的新的时区类,注意和旧的java.util.TimeZone
区别。
要创建一个ZonedDateTime
对象,有以下几种方法,一种是通过now()
方法返回当前时间:
观察打印的两个ZonedDateTime
,发现它们时区不同,但表示的时间都是同一时刻(毫秒数不同是执行语句时的时间差):
2019-09-15T20:58:18.786182+08:00[Asia/Shanghai]
2019-09-15T08:58:18.788860-04:00[America/New_York]
另一种方式是通过给一个LocalDateTime
附加一个ZoneId
,就可以变成ZonedDateTime
:
以这种方式创建的ZonedDateTime
,它的日期和时间与LocalDateTime
相同,但附加的时区不同,因此是两个不同的时刻:
2019-09-15T15:16:17+08:00[Asia/Shanghai]
2019-09-15T15:16:17-04:00[America/New_York]
要转换时区,首先我们需要有一个ZonedDateTime
对象,然后,通过withZoneSameInstant()
将关联时区转换到另一个时区,转换后日期和时间都会相应调整。
下面的代码演示了如何将北京时间转换为纽约时间:
要特别注意,时区转换的时候,由于夏令时的存在,不同的日期转换的结果很可能是不同的。这是北京时间9月15日的转换结果:
2019-09-15T21:05:50.187697+08:00[Asia/Shanghai]
2019-09-15T09:05:50.187697-04:00[America/New_York]
这是北京时间11月15日的转换结果:
2019-11-15T21:05:50.187697+08:00[Asia/Shanghai]
2019-11-15T08:05:50.187697-05:00[America/New_York]
两次转换后的纽约时间有1小时的夏令时时差。
涉及到时区时,千万不要自己计算时差,否则难以正确处理夏令时。
有了ZonedDateTime
,将其转换为本地时间就非常简单:
ZonedDateTime zdt = ...
LocalDateTime ldt = zdt.toLocalDateTime();
转换为LocalDateTime
时,直接丢弃了时区信息。
某航线从北京飞到纽约需要13小时20分钟,请根据北京起飞日期和时间计算到达纽约的当地日期和时间。
提示:ZonedDateTime
仍然提供了plusDays()
等加减操作。
下载练习:flight-time练习 (推荐使用IDE练习插件快速下载)
ZonedDateTime
是带时区的日期和时间,可用于时区转换;
ZonedDateTime
和LocalDateTime
可以相互转换。
使用旧的Date
对象时,我们用SimpleDateFormat
进行格式化显示。使用新的LocalDateTime
或ZonedLocalDateTime
时,我们要进行格式化显示,就要使用DateTimeFormatter
。
和SimpleDateFormat
不同的是,DateTimeFormatter
不但是不变对象,它还是线程安全的。线程的概念我们会在后面涉及到。现在我们只需要记住:因为SimpleDateFormat
不是线程安全的,使用的时候,只能在方法内部创建新的局部变量。而DateTimeFormatter
可以只创建一个实例,到处引用。
创建DateTimeFormatter
时,我们仍然通过传入格式化字符串实现:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
格式化字符串的使用方式与SimpleDateFormat
完全一致。
另一种创建DateTimeFormatter
的方法是,传入格式化字符串时,同时指定Locale
:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("E, yyyy-MMMM-dd HH:mm", Locale.US);
这种方式可以按照Locale
默认习惯格式化。我们来看实际效果:
在格式化字符串中,如果需要输出固定字符,可以用'xxx'
表示。
运行上述代码,分别以默认方式、中国地区和美国地区对当前时间进行显示,结果如下:
2019-09-15T23:16 GMT+08:00
2019 9月 15 周日 23:16
Sun, September/15/2019 23:16
当我们直接调用System.out.println()
对一个ZonedDateTime
或者LocalDateTime
实例进行打印的时候,实际上,调用的是它们的toString()
方法,默认的toString()
方法显示的字符串就是按照ISO 8601
格式显示的,我们可以通过DateTimeFormatter
预定义的几个静态变量来引用:
var ldt = LocalDateTime.now();
System.out.println(DateTimeFormatter.ISO_DATE.format(ldt));
System.out.println(DateTimeFormatter.ISO_DATE_TIME.format(ldt));
得到的输出和toString()
类似:
2019-09-15
2019-09-15T23:16:51.56217
对ZonedDateTime
或LocalDateTime
进行格式化,需要使用DateTimeFormatter
类;
DateTimeFormatter
可以通过格式化字符串和Locale
对日期和时间进行定制输出。
我们已经讲过,计算机存储的当前时间,本质上只是一个不断递增的整数。Java提供的System.currentTimeMillis()
返回的就是以毫秒表示的当前时间戳。
这个当前时间戳在java.time
中以Instant
类型表示,我们用Instant.now()
获取当前时间戳,效果和System.currentTimeMillis()
类似:
打印的结果类似:
1568568760
1568568760316
实际上,Instant
内部只有两个核心字段:
public final class Instant implements ... {
private final long seconds;
private final int nanos;
}
一个是以秒为单位的时间戳,一个是更精确的纳秒精度。它和System.currentTimeMillis()
返回的long
相比,只是多了更高精度的纳秒。
既然Instant
就是时间戳,那么,给它附加上一个时区,就可以创建出ZonedDateTime
:
// 以指定时间戳创建Instant:
Instant ins = Instant.ofEpochSecond(1568568760);
ZonedDateTime zdt = ins.atZone(ZoneId.systemDefault());
System.out.println(zdt); // 2019-09-16T01:32:40+08:00[Asia/Shanghai]
可见,对于某一个时间戳,给它关联上指定的ZoneId
,就得到了ZonedDateTime
,继而可以获得了对应时区的LocalDateTime
。
所以,LocalDateTime
,ZoneId
,Instant
,ZonedDateTime
和long
都可以互相转换:
┌─────────────┐
│LocalDateTime│────┐
└─────────────┘ │ ┌─────────────┐
├───>│ZonedDateTime│
┌─────────────┐ │ └─────────────┘
│ ZoneId │────┘ ▲
└─────────────┘ ┌─────────┴─────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Instant │<───>│ long │
└─────────────┘ └─────────────┘
转换的时候,只需要留意long
类型以毫秒还是秒为单位即可。
Instant
表示高精度时间戳,它可以和ZonedDateTime
以及long
互相转换。
由于Java提供了新旧两套日期和时间的API,除非涉及到遗留代码,否则我们应该坚持使用新的API。
如果需要与遗留代码打交道,如何在新旧API之间互相转换呢?
如果要把旧式的Date
或Calendar
转换为新API对象,可以通过toInstant()
方法转换为Instant
对象,再继续转换为ZonedDateTime
:
// Date -> Instant:
Instant ins1 = new Date().toInstant();
// Calendar -> Instant -> ZonedDateTime:
Calendar calendar = Calendar.getInstance();
Instant ins2 = Calendar.getInstance().toInstant();
ZonedDateTime zdt = ins2.atZone(calendar.getTimeZone().toZoneId());
从上面的代码还可以看到,旧的TimeZone
提供了一个toZoneId()
,可以把自己变成新的ZoneId
。
如果要把新的ZonedDateTime
转换为旧的API对象,只能借助long
型时间戳做一个“中转”:
// ZonedDateTime -> long:
ZonedDateTime zdt = ZonedDateTime.now();
long ts = zdt.toEpochSecond() * 1000;
// long -> Date:
Date date = new Date(ts);
// long -> Calendar:
Calendar calendar = Calendar.getInstance();
calendar.clear();
calendar.setTimeZone(TimeZone.getTimeZone(zdt.getZone().getId()));
calendar.setTimeInMillis(zdt.toEpochSecond() * 1000);
从上面的代码还可以看到,新的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()
的方法,非常简单地为不同用户以不同的偏好来显示不同的本地时间:
对上述方法进行调用,结果如下:
2019年11月20日 上午8:15
Nov 19, 2019, 7:15 PM
处理日期和时间时,尽量使用新的java.time
包;
在数据库中存储时间戳时,尽量使用long
型时间戳,它具有省空间,效率高,不依赖数据库的优点。