Java中的时间日期API知识点总结
自从14年发布Java8以后，我们古老java.util.Date终于不再是我们Java里操作日期时间的唯一的选择。
其实Java里的日期时间的相关API一直为世猿诟病，不仅在于它设计分上工不明确，往往一个类既能处理日期又能处理时间，很混乱，还在于某些年月日期的数值映射存储反人类，例如：0对应月份一月，11对应月份十二月，118对应年份2018（1900+118）等。
往往我们得到某个年月值还需要再做相应的运算才能得到准确的年月日信息，直到我们的Java8，借鉴了第三方开源库Joda-Time的优秀设计，重新设计了一个日期时间API，相比之前，可以说好用百倍，相关API接口全部位于包java.time下。
古老的日期时间接口
表示时刻信息的Date
世界上所有的计算机内部存储时间都使用一个long类型的整数，而这个整数的值就是相对于英国格林尼治标准时间（1970年1月1日0时0分0秒）的毫秒数。例如：
publicstaticvoidmain(String[]args){
//January1,197000:00:00GMT.
Datedate=newDate(1000);
System.out.println(date);
}
输出结果：
//1970-1-18:00:01 ThuJan0108:00:01CST1970
很多人可能会疑惑，1000表示的是距离标准时间往后1秒，那为什么时间却多走了八个小时？
这和「时区」有关系，如果你位于英国的格林尼治区，那么结果会如预想一样，但是我们位于中国东八区，时间要早八个小时，所以不同时区基于的基础值不同。
Date这个类以前真的扮演过很多角色，从它的源码就可以看出来，有可以操作时刻的方法，有可以操作年月日的方法，甚至它还能管时区。可以说，日期时间的相关操作有它一个人就足够了。
但这个世界就是这样，你管的东西多了，自然就不能面面俱到，Date中很多方法的设计并不是很合理，之前我们也说了，甚至有点反人类。所以，现在的Date类中接近百分之八十的方法都已废弃，被标记为@Deprecated。
sun公司给Date的目前定位是，唯一表示一个时刻，所以它的内部应该围绕着那个整型的毫秒，而不再着重于各种年历时区等信息。
Date允许通过以下两种构造器实例化一个对象：
privatetransientlongfastTime;
publicDate(){
this(System.currentTimeMillis());
}
publicDate(longdate){
fastTime=date;
}
这里的fastTime属性存储的就是时刻所对应的毫秒数，两个构造器还是很简单，如果调用的是无参构造器，那么虚拟机将以系统当前的时刻值对fastTime进行赋值。
还有几个为数不多没有被废弃的方法：
- publiclonggetTime()：返回内部存储的毫秒数
- publicvoidsetTime(longtime)：重新设置内存的毫秒数
- publicbooleanbefore(Datewhen)：比较给定的时刻是否早于当前Date实例
- publicbooleanafter(Datewhen)：比较给定的时刻是否晚于当前Date实例
还有两个方法是jdk1.8以后新增的，用于向Java8新增接口的转换，待会介绍。
描述年历的Calendar
Calendar用于表示年月日等日期信息，它是一个抽象类，所以一般通过以下四种工厂方法获取它的实例对象。
publicstaticCalendargetInstance() publicstaticCalendargetInstance(TimeZonezone) publicstaticCalendargetInstance(LocaleaLocale) publicstaticCalendargetInstance(TimeZonezone,LocaleaLocale)
其实内部最终会调用同一个内部方法：
privatestaticCalendarcreateCalendar(TimeZonezone,LocaleaLocale)
该方法需要两个参数，一个是时区，一个是国家和语言，也就是说，构建一个Calendar实例最少需要提供这两个参数信息，否则将会使用系统默认的时区或语言信息。
因为不同的时区与国家语言对于时刻和年月日信息的输出是不同的，所以这也是为什么一个Calendar实例必须传入时区和国家信息的一个原因。看个例子：
publicstaticvoidmain(String[]args){
Calendarcalendar=Calendar.getInstance();
System.out.println(calendar.getTime());
Calendarcalendar1=Calendar.getInstance
(TimeZone.getTimeZone("GMT"),Locale.ENGLISH);
System.out.println(calendar1.get(Calendar.YEAR)+":"+
calendar1.get(Calendar.HOUR)+":"+
calendar1.get(Calendar.MINUTE));
}
输出结果：
SatApr2110:32:20CST2018 2018:2:32
可以看到，第一个输出为我们系统默认时区与国家的当前时间，而第二个Calendar实例我们指定了它位于格林尼治时区（0时区），结果也显而易见了，相差了八个小时，那是因为我们位于东八区，时间早于0时区八个小时。
可能有人会疑惑了，为什么第二个Calendar实例的输出要如此复杂的拼接，而不像第一个Calendar实例那样直接调用getTime方法简洁呢？
这涉及到Calendar的内部实现，我们一起看看：
protectedlongtime;
publicfinalDategetTime(){
returnnewDate(getTimeInMillis());
}
和Date一样，Calendar的内部也维护着一个时刻信息，而getTime方法实际上是根据这个时刻构建了一个Date对象并返回的。
而一般我们构建Calendar实例的时候都不会传入一个时刻信息，所以这个time的值在实例初始化的时候，程序会根据系统默认的时区和当前时间计算得到一个毫秒数并赋值给time。
所以，所有未手动修改time属性值的Calendar实例的内部，time的值都是当时系统默认时区的时刻数值。也就是说，getTime的输出结果是不会理会当前实例所对应的时区信息的，这也是我觉得Calendar设计的一个缺陷所在，因为这样会导致两个不同时区Calendar实例的getTime输出值只取决于实例初始化时系统的运行时刻。
Calendar中也定义了很多静态常量和一些属性数组：
publicfinalstaticintERA=0; publicfinalstaticintYEAR=1; publicfinalstaticintMONTH=2; publicfinalstaticintWEEK_OF_YEAR=3; publicfinalstaticintWEEK_OF_MONTH=4; publicfinalstaticintDATE=5; .... protectedintfields[]; protectedbooleanisSet[]; ...
有关日期的所有相关信息都存储在属性数组中，而这些静态常量的值往往表示的就是一个索引值，通过get方法，我们传入一个属性索引，返回得到该属性的值。例如：
CalendarmyCalendar=Calendar.getInstance(); intyear=myCalendar.get(Calendar.YEAR);
这里的get方法实际上就是直接取的fields[1]作为返回值，而fields属性数组在Calendar实例初始化的时候就已经由系统根据时区和语言计算并赋值了，注意，这里会根据你指定的时区进行计算，它不像time始终是依照的系统默认时区。
个人觉得Calendar的设计有优雅的地方，也有不合理的地方，毕竟是个「古董」了，终将被替代。
DateFormat格式化转换
从我们之前的一个例子中可以看到，Calendar想要输出一个预期格式的日期信息是很麻烦的，需要自己手动拼接。而我们的DateFormat就是用来处理格式化字符串和日期时间之间的转换操作的。
DateFormat和Calendar一样，也是一个抽象类，我们需要通过工厂方式产生其实例对象，主要有以下几种工厂方法：
//只处理时间的转换 publicfinalstaticDateFormatgetTimeInstance() //只处理日期的转换 publicfinalstaticDateFormatgetDateInstance() //既可以处理时间，也可以处理日期 publicfinalstaticDateFormatgetDateTimeInstance()
当然，它们各自都有各自的重载方法，具体的我们待会儿看。
DateFormat有两类方法，format和parse。
publicfinalStringformat(Datedate) publicDateparse(Stringsource)
format方法用于将一个日期对象格式化为字符串，parse方法用于将一个格式化的字符串装换为一个日期对象。例如：
publicstaticvoidmain(String[]args){
Calendarcalendar=Calendar.getInstance();
DateFormatdateFormat=DateFormat.getDateTimeInstance();
System.out.println(dateFormat.format(calendar.getTime()));
}
输出结果：
2018-4-2116:58:09
显然，使用工厂构造的DateFormat实例并不能够自定义输出格式化内容，即输出的字符串格式是固定的，不能满足某些情况下的特殊需求。一般我们会直接使用它的一个实现类，SimpleDateFormat。
SimpleDateFormat允许在构造实例的时候传入一个pattern参数，自定义日期字符的输出格式。例如：
publicstaticvoidmain(String[]args){
DateFormatdateFormat=newSimpleDateFormat("yyyy年MM月dd日");
System.out.println(dateFormat.format(newDate()));
}
输出结果：
2018年04月21日
其中，
- yyyy：年份用四位进行输出
- MM：月份用两位进行输出
- dd：两位表示日信息
- HH：两位来表示小时数
- mm：两位表示分钟数
- ss：两位来表示秒数
- E：表示周几，如果Locale在中国则会输出星期x，如果在美国或英国则会输出英文的星期
- a：表示上午或下午
当然，对于字符串转日期也是很方便的，允许自定义模式，但必须遵守自己制定的模式，否则程序将无法成功解析。例如：
publicstaticvoidmain(String[]args){
Stringstr="2018年4月21日17点17分星期六";
DateFormatsDateFormat=newSimpleDateFormat("yyyy年M月dd日HH点mm分E");
sDateFormat.parse(str);
System.out.println(sDateFormat.getCalendar().getTime());
}
输出结果：
SatApr2117:17:00CST2018
显然，程序是正确的解析的我们的字符串并转换为Calendar对象存储在DateFormat内部的。
总的来说，Date、Calendar和DateFormat已经能够处理一般的时间日期问题了，但是不可避免的是，它们依然很繁琐，不好用。
限于篇幅，我们下篇将对比Java8的新式日期时间API，你会发现它更加优雅的设计和简单的操作性。