Java 中的時間日期 API

YangAM發表於2019-03-04
JavaAPI

自從 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秒）的毫秒數。例如：

public static void main(String[] args){
    //January 1, 1970 00:00:00 GMT.
    Date date = new Date(1000);
    System.out.println(date);
}
複製程式碼

輸出結果：

//1970-1-1 8:00:01
Thu Jan 01 08:00:01 CST 1970
複製程式碼

很多人可能會疑惑，1000 表示的是距離標準時間往後 1 秒，那為什麼時間卻多走了 八個小時？

這和「時區」有關係，如果你位於英國的格林尼治區，那麼結果會如預想一樣，但是我們位於中國東八區，時間要早八個小時，所以不同時區基於的基礎值不同。

Date 這個類以前真的扮演過很多角色，從它的原始碼就可以看出來，有可以操作時刻的方法，有可以操作年月日的方法，甚至它還能管時區。可以說，日期時間的相關操作有它一個人就足夠了。

但這個世界就是這樣，你管的東西多了，自然就不能面面俱到，Date 中很多方法的設計並不是很合理，之前我們也說了，甚至有點反人類。所以，現在的 Date 類中接近百分之八十的方法都已廢棄，被標記為 @Deprecated。

sun 公司給 Date 的目前定位是，唯一表示一個時刻，所以它的內部應該圍繞著那個整型的毫秒，而不再著重於各種年曆時區等資訊。

Date 允許通過以下兩種構造器例項化一個物件：

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 用於表示年月日等日期資訊，它是一個抽象類，所以一般通過以下四種工廠方法獲取它的例項物件。

public static Calendar getInstance()

public static Calendar getInstance(TimeZone zone)

public static Calendar getInstance(Locale aLocale)

public static Calendar getInstance(TimeZone zone,Locale aLocale)
複製程式碼

其實內部最終會呼叫同一個內部方法：

private static Calendar createCalendar(TimeZone zone,Locale aLocale)
複製程式碼

該方法需要兩個引數，一個是時區，一個是國家和語言，也就是說，構建一個 Calendar 例項最少需要提供這兩個引數資訊，否則將會使用系統預設的時區或語言資訊。

因為不同的時區與國家語言對於時刻和年月日資訊的輸出是不同的，所以這也是為什麼一個 Calendar 例項必須傳入時區和國家資訊的一個原因。看個例子：

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));
    }
複製程式碼

輸出結果：

Sat Apr 21 10:32:20 CST 2018
2018:2:32
複製程式碼

可以看到，第一個輸出為我們系統預設時區與國家的當前時間，而第二個 Calendar 例項我們指定了它位於格林尼治時區（0 時區），結果也顯而易見了，相差了八個小時，那是因為我們位於東八區，時間早於 0 時區八個小時。

可能有人會疑惑了，為什麼第二個 Calendar 例項的輸出要如此複雜的拼接，而不像第一個 Calendar 例項那樣直接呼叫 getTime 方法簡潔呢？

這涉及到 Calendar 的內部實現，我們一起看看：

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 中也定義了很多靜態常量和一些屬性陣列：

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 方法，我們傳入一個屬性索引，返回得到該屬性的值。例如：

Calendar myCalendar = Calendar.getInstance();
int year = myCalendar.get(Calendar.YEAR);
複製程式碼

這裡的 get 方法實際上就是直接取的 fields[1] 作為返回值，而 fields 屬性陣列在 Calendar 例項初始化的時候就已經由系統根據時區和語言計算並賦值了，注意，這裡會根據你指定的時區進行計算，它不像 time 始終是依照的系統預設時區。

個人覺得 Calendar 的設計有優雅的地方，也有不合理的地方，畢竟是個「古董」了，終將被替代。

DateFormat 格式化轉換

從我們之前的一個例子中可以看到，Calendar 想要輸出一個預期格式的日期資訊是很麻煩的，需要自己手動拼接。而我們的 DateFormat 就是用來處理格式化字串和日期時間之間的轉換操作的。

DateFormat 和 Calendar 一樣，也是一個抽象類，我們需要通過工廠方式產生其例項物件，主要有以下幾種工廠方法：

//只處理時間的轉換
public final static DateFormat getTimeInstance()

//只處理日期的轉換
public final static DateFormat getDateInstance()

//既可以處理時間，也可以處理日期
public final static DateFormat getDateTimeInstance()
複製程式碼

當然，它們各自都有各自的過載方法，具體的我們待會兒看。

DateFormat 有兩類方法，format 和 parse。

public final String format(Date date)

public Date parse(String source)
複製程式碼

format 方法用於將一個日期物件格式化為字串，parse 方法用於將一個格式化的字串裝換為一個日期物件。例如：

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 引數，自定義日期字元的輸出格式。例如：

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：表示上午或下午

當然，對於字串轉日期也是很方便的，允許自定義模式，但必須遵守自己制定的模式，否則程式將無法成功解析。例如：

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，你會發現它更加優雅的設計和簡單的操作性。

文章中的所有程式碼、圖片、檔案都雲端儲存在我的 GitHub 上：

(https://github.com/SingleYam/overview_java)

歡迎關注微信公眾號：撲在程式碼上的高爾基，所有文章都將同步在公眾號上。

image

相關文章