21世纪已过两个十年！

• 国际化支持得并不是好，比如跨时区操作、夏令时等等

Java 自己也实在忍不了这么难用的日期时间API了，于是在2014年随着Java 8的发布引入了全新的JSR 310日期时间。JSR-310源于精品时间库joda-time打造，解决了上面提到的所有问题，是整个Java 8最大亮点之一。

JSR 310日期/时间 所有的 API都在java.time这个包内，没有例外。
 

观察打印结果，除了符合模式规则外，还能在String -> Date解析时总结出两点结论：

1. 英文单词，不分区大小写。如SatUrday sunDay都是没问题，但是不能有拼写错误
2. 若有多个part表示一个意思，那么last win。如Sat SatUrday sunDay最后一个生效

对于Locale地域参数，因为中文不存在格式、缩写方面的特性，因此这些规则只对英文地域(如Locale.US生效)

• Number：格式化(Date -> String)，模式字母的数量是数字的【最小】数量，较短的数字被零填充到这个数量。对于解析(String -> Date)，模式字母的数量将被忽略，除非需要分隔两个相邻的字段
• Year：对于格式化和解析，如果模式字母的数量是4个或更多，则使用特定于日历的长格式。否则，使用日历特定的简短或缩写形式
• Month：如果模式字母的数量是3个或更多，则被解释为文本;否则，它将被解释为一个数字。
• 通用时区：如果该时区有名称，如Pacific Standard Time、PST、CST等那就用名称，否则就用GMT规则的字符串，如：GMT-08:00
• RFC 822时区：遵循RFC 822格式，向下兼容通用时区(名称部分除外)
• ISO 8601时区：对于格式化，如果与GMT的偏移值为0(也就是格林威治时间喽)，则生成“Z”;如果模式字母的数量为1，则忽略小时的任何分数。例如，如果模式是“X”，时区是“GMT+05:30”，则生成“+05”。在进行解析时，“Z”被解析为UTC时区指示符。一般时区不被接受。如果模式字母的数量是4个或更多，在构造SimpleDateFormat或应用模式时抛出IllegalArgumentException。

这个规则理解起来还是比较费劲的，在开发中一般不太建议使用此种模式。若要使用请务必本地做好测试

SimpleDateFormat的使用很简单，重点是了解其规则模式。最后关于SimpleDateFormat的使用再强调这两点哈：

1. SimpleDateFormat并非线程安全类，使用时请务必注意并发安全问题
2. 若使用SimpleDateFormat去格式化成非本地区域(默认Locale)的话，那就必须在构造的时候就指定好，如Locale.US
3. 对于Date类型的任何格式化、解析请统一使用SimpleDateFormat

JSR 310类型

曾经有个人做了个很有意思的投票，统计对Java API的不满意程度。最终Java Date/Calendar API斩获第二烂(第一烂是Java XML/DOM)，体现出它烂的点较多，这里给你例举几项：

定义并不一致，在java.util和java.sql包中竟然都有Date类，而且呢对它进行格式化/解析类竟然又跑到java.text去了，精神分裂啊

java.util.Date等类在建模日期的设计上行为不一致，缺陷明显。包括易变性、糟糕的偏移值、默认值、命名等等

java.util.Date同时包含日期和时间，而其子类java.sql.Date却仅包含日期，这是什么神继承?

（编辑：衡水站长网）

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