自從 14 年發布 java 8 以后，我們古老 java.util.date 終于不再是我們 java 里操作日期時間的唯一的選擇。
其實 java 里的日期時間的相關 api 一直為世猿詬病，不僅在于它設計分上工不明確，往往一個類既能處理日期又能處理時間，很混亂，還在于某些年月日期的數值映射存儲反人類，例如：0 對應月份一月，11 對應月份十二月，118 對應年份 2018（1900 + 118）等。
往往我們得到某個年月值還需要再做相應的運算才能得到準確的年月日信息，直到我們的 java 8 ，借鑒了第三方開源庫 joda-time 的優秀設計，重新設計了一個日期時間 api，相比之前，可以說好用百倍，相關 api 接口全部位于包 java.time 下。
古老的日期時間接口
表示時刻信息的 date
世界上所有的計算機內部存儲時間都使用一個 long 類型的整數，而這個整數的值就是相對于英國格林尼治標準時間（1970年1月1日0時0分0秒）的毫秒數。例如：
|
1
2
3
4
5
|
public static void main(string[] args){ //january 1, 1970 00:00:00 gmt. date date = new date(1000); system.out.println(date);} |
輸出結果：
|
1
2
|
//1970-1-1 8:00:01thu jan 01 08:00:01 cst 1970 |
很多人可能會疑惑，1000 表示的是距離標準時間往后 1 秒，那為什么時間卻多走了 八個小時？
這和「時區」有關系，如果你位于英國的格林尼治區，那么結果會如預想一樣，但是我們位于中國東八區，時間要早八個小時，所以不同時區基于的基礎值不同。
date 這個類以前真的扮演過很多角色，從它的源碼就可以看出來，有可以操作時刻的方法，有可以操作年月日的方法，甚至它還能管時區。可以說，日期時間的相關操作有它一個人就足夠了。
但這個世界就是這樣，你管的東西多了，自然就不能面面俱到，date 中很多方法的設計并不是很合理，之前我們也說了，甚至有點反人類。所以，現在的 date 類中接近百分之八十的方法都已廢棄，被標記為 @deprecated。
sun 公司給 date 的目前定位是，唯一表示一個時刻，所以它的內部應該圍繞著那個整型的毫秒，而不再著重于各種年歷時區等信息。
date 允許通過以下兩種構造器實例化一個對象：
|
1
2
3
4
5
6
7
8
9
|
private transient long fasttime;public date() { this(system.currenttimemillis());}public date(long date) { fasttime = date;} |
這里的 fasttime 屬性存儲的就是時刻所對應的毫秒數，兩個構造器還是很簡單，如果調用的是無參構造器，那么虛擬機將以系統當前的時刻值對 fasttime 進行賦值。
還有幾個為數不多沒有被廢棄的方法：
- public long gettime() ：返回內部存儲的毫秒數
- public void settime(long time)：重新設置內存的毫秒數
- public boolean before(date when)：比較給定的時刻是否早于當前 date 實例
- public boolean after(date when)：比較給定的時刻是否晚于當前 date 實例
還有兩個方法是 jdk1.8 以后新增的，用于向 java 8 新增接口的轉換，待會介紹。
描述年歷的 calendar
calendar 用于表示年月日等日期信息，它是一個抽象類，所以一般通過以下四種工廠方法獲取它的實例對象。
|
1
2
3
4
5
6
7
|
public static calendar getinstance()public static calendar getinstance(timezone zone)public static calendar getinstance(locale alocale)public static calendar getinstance(timezone zone,locale alocale) |
其實內部最終會調用同一個內部方法：
|
1
|
private static calendar createcalendar(timezone zone,locale alocale) |
該方法需要兩個參數，一個是時區，一個是國家和語言，也就是說，構建一個 calendar 實例最少需要提供這兩個參數信息，否則將會使用系統默認的時區或語言信息。
因為不同的時區與國家語言對于時刻和年月日信息的輸出是不同的，所以這也是為什么一個 calendar 實例必須傳入時區和國家信息的一個原因。看個例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public static void main(string[] args){ calendar calendar = calendar.getinstance(); system.out.println(calendar.gettime()); calendar calendar1 = calendar.getinstance (timezone.gettimezone("gmt"), locale.english); system.out.println( calendar1.get(calendar.year) + ":" + calendar1.get(calendar.hour) + ":" + calendar1.get(calendar.minute)); } |
輸出結果：
|
1
2
|
sat apr 21 10:32:20 cst 20182018:2:32 |
可以看到，第一個輸出為我們系統默認時區與國家的當前時間，而第二個 calendar 實例我們指定了它位于格林尼治時區（0 時區），結果也顯而易見了，相差了八個小時，那是因為我們位于東八區，時間早于 0 時區八個小時。
可能有人會疑惑了，為什么第二個 calendar 實例的輸出要如此復雜的拼接，而不像第一個 calendar 實例那樣直接調用 gettime 方法簡潔呢？
這涉及到 calendar 的內部實現，我們一起看看：
|
1
2
3
4
5
|
protected long time;public final date gettime() { return new date(gettimeinmillis());} |
和 date 一樣，calendar 的內部也維護著一個時刻信息，而 gettime 方法實際上是根據這個時刻構建了一個 date 對象并返回的。
而一般我們構建 calendar 實例的時候都不會傳入一個時刻信息，所以這個 time 的值在實例初始化的時候，程序會根據系統默認的時區和當前時間計算得到一個毫秒數并賦值給 time。
所以，所有未手動修改 time 屬性值的 calendar 實例的內部，time 的值都是當時系統默認時區的時刻數值。也就是說，gettime 的輸出結果是不會理會當前實例所對應的時區信息的，這也是我覺得 calendar 設計的一個缺陷所在，因為這樣會導致兩個不同時區 calendar 實例的 gettime 輸出值只取決于實例初始化時系統的運行時刻。
calendar 中也定義了很多靜態常量和一些屬性數組：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public final static int era = 0;public final static int year = 1;public final static int month = 2;public final static int week_of_year = 3;public final static int week_of_month = 4;public final static int date = 5;....protected int fields[];protected boolean isset[];... |
有關日期的所有相關信息都存儲在屬性數組中，而這些靜態常量的值往往表示的就是一個索引值，通過 get 方法，我們傳入一個屬性索引，返回得到該屬性的值。例如：
|
1
2
|
calendar mycalendar = calendar.getinstance();int year = mycalendar.get(calendar.year); |
這里的 get 方法實際上就是直接取的 fields[1] 作為返回值，而 fields 屬性數組在 calendar 實例初始化的時候就已經由系統根據時區和語言計算并賦值了，注意，這里會根據你指定的時區進行計算，它不像 time 始終是依照的系統默認時區。
個人覺得 calendar 的設計有優雅的地方，也有不合理的地方，畢竟是個「古董」了，終將被替代。
dateformat 格式化轉換
從我們之前的一個例子中可以看到，calendar 想要輸出一個預期格式的日期信息是很麻煩的，需要自己手動拼接。而我們的 dateformat 就是用來處理格式化字符串和日期時間之間的轉換操作的。
dateformat 和 calendar 一樣，也是一個抽象類，我們需要通過工廠方式產生其實例對象，主要有以下幾種工廠方法：
|
1
2
3
4
5
6
7
8
|
//只處理時間的轉換public final static dateformat gettimeinstance()//只處理日期的轉換public final static dateformat getdateinstance()//既可以處理時間，也可以處理日期public final static dateformat getdatetimeinstance() |
當然，它們各自都有各自的重載方法，具體的我們待會兒看。
dateformat 有兩類方法，format 和 parse。
|
1
2
3
|
public final string format(date date)public date parse(string source) |
format 方法用于將一個日期對象格式化為字符串，parse 方法用于將一個格式化的字符串裝換為一個日期對象。例如：
|
1
2
3
4
5
|
public static void main(string[] args){ calendar calendar = calendar.getinstance(); dateformat dateformat = dateformat.getdatetimeinstance(); system.out.println(dateformat.format(calendar.gettime()));} |
輸出結果：
2018-4-21 16:58:09
顯然，使用工廠構造的 dateformat 實例并不能夠自定義輸出格式化內容，即輸出的字符串格式是固定的，不能滿足某些情況下的特殊需求。一般我們會直接使用它的一個實現類，simpledateformat。
simpledateformat 允許在構造實例的時候傳入一個 pattern 參數，自定義日期字符的輸出格式。例如：
|
1
2
3
4
|
public static void main(string[] args){ dateformat dateformat = new simpledateformat("yyyy年mm月dd日"); system.out.println(dateformat.format(new date()));} |
輸出結果：
2018年04月21日
其中，
- yyyy：年份用四位進行輸出
- mm：月份用兩位進行輸出
- dd：兩位表示日信息
- hh：兩位來表示小時數
- mm：兩位表示分鐘數
- ss：兩位來表示秒數
- e：表示周幾，如果 locale 在中國則會輸出 星期x，如果在美國或英國則會輸出英文的星期
- a：表示上午或下午
當然，對于字符串轉日期也是很方便的，允許自定義模式，但必須遵守自己制定的模式，否則程序將無法成功解析。例如：
|
1
2
3
4
5
6
|
public static void main(string[] args){ string str = "2018年4月21日 17點17分 星期六"; dateformat sdateformat = new simpledateformat("yyyy年m月dd日 hh點mm分 e"); sdateformat.parse(str); system.out.println(sdateformat.getcalendar().gettime());} |
輸出結果：
sat apr 21 17:17:00 cst 2018
顯然，程序是正確的解析的我們的字符串并轉換為 calendar 對象存儲在 dateformat 內部的。
總的來說，date、calendar 和 dateformat 已經能夠處理一般的時間日期問題了，但是不可避免的是，它們依然很繁瑣，不好用。
限于篇幅，我們下篇將對比 java 8 的新式日期時間 api，你會發現它更加優雅的設計和簡單的操作性。
原文鏈接：https://www.cnblogs.com/yangming1996/p/8902484.html
