大廠如何使用Java8日期時間?
1 背景
Java8前，處理日期時間時，使用的“三大件”
- Date
- Calender
- SimpleDateFormat
以聲明時間戳、使用日歷處理日期和格式化解析日期時間。但這些類的API可讀性差、使用繁瑣，且非線程安全，如同設計的翔一樣的IO，也是Java讓人詬病的一大原因。
于是Java8推出全新日期時間類。這些類的API功能強大簡便、線程安全。
但畢竟Java8剛出這些類，諸如序列化、數據訪問等類庫都不支持Java8日期時間類，需在新老類中來回切換。比如，在業務邏輯層使用LocalDateTime，存入數據庫或者返回前端的時候還要切換回Date。因此，還不如沿用老的日期時間類。
不過我們生活在最好的時代，基本主流類庫都支持新日期時間類型，但還有項目因還是用祖傳日期時間類，出現很多古今交錯的錯誤實踐。
比如
- 通過隨意修改時區，使讀取到的數據匹配當前時鐘
- 直接對讀取到的數據做加、減幾個小時的操作，來“修正數據”
本文旨在分析古今時間錯亂的本質原因，看看使用遺留日期時間類，來處理日期時間初始化、格式化、解析、計算等可能會遇到的問題，以及如何使用新日期時間類解決。
2 初始化日期時間
初始化2020年11月11日11點11分11秒時間，這樣可行嗎?
日志輸出時間是3029年12月11日11點11分11秒：
- date : Sat Dec 11 11:11:11 CST 3920
這明顯是彩筆才會寫的垃圾代碼，因為
- 年應該是和1900差值
- 月應該是 0~11 而非 1~12
- 時應該是 0~23，而非 1~24
修正上述代碼如下：
- Date date = new Date(2020 - 1900, 10, 11, 11, 11, 11);
日志輸出：
- Mon Nov 11 11:11:11 CST 2019
當有國際化需求時，又得使用Calendar類初始化時間。
使用Calendar改造后，初始化時年參數直接使用當前年即可，月0~11。亦可直接使用Calendar.DECEMBER初始化月份，肯定不會犯錯。
分別使用當前時區和紐約時區初始化兩個相同日期：
日志輸出
顯示兩個不同時間，說明時區發生作用。但更習慣年/月/日 時:分:秒日期時間格式，對現在輸出的日期格式還不滿意，那就格式化日期時間
3 時區問題
全球有24個時區，同一個時刻不同時區(比如中國上海和美國紐約)的時間不同。全球化項目，若初始化時間時未提供時區，那就不是真正意義上的時間，只能認為是我看到的當前時間的一個表示。
3.1 Date類
Date無時區概念，任一機器使用new Date()初始化得到時間相同。因為，Date中保存的是UTC時間，其為以原子鐘為基礎的統一時間，不以太陽參照計時，無時區劃分
Date中保存的是一個時間戳，代表從1970年1月1日0點(Epoch時間)到現在的毫秒數。嘗試輸出Date(0)：
- System.out.println(new Date(0));
- System.out.println(TimeZone.getDefault().getID() + ":" +
- TimeZone.getDefault().getRawOffset()/3600000);
得到1970年1月1日8點。我的機器在中國上海，相比UTC時差+8小時：
- Thu Jan 01 08:00:00 CST 1970
- Asia/Shanghai:8
對于國際化項目，處理好時間和時區問題首先就是要正確保存日期時間。
這里有兩種
3.2 如何正確保存日期時間
- 保存UTC
保存的時間無時區屬性，不涉及時區時間差問題的世界統一時間。常說的時間戳或Java中的Date類就是這種方式，也是推薦方案
- 保存字面量
比如年/月/日 時:分:秒，務必同時保存時區信息。有了時區，才能知道該字面量時間真正的時間點，否則它只是一個給人看的時間表示且只在當前時區有意義。
而Calendar才具有時區概念，所以通過使用不同時區初始化Calendar，才能得到不同時間。
正確地保存日期時間后，就是正確展示，即要使用正確時區，將時間點展示為符合當前時區的時間表示。至此也就能理解為何會發生“時間錯亂”。
從字面量解析成時間 & 從時間格式化為字面量
對同一時間表示，不同時區轉換成Date會得到不同時間戳
比如2020-11-11 11:11:11
對當前上海時區/紐約時區，轉化為UTC時間戳不同
- Wed Nov 11 11:11:11 CST 2020:1605064271000
- Thu Nov 12 00:11:11 CST 2020:1605111071000
這就是UTC的意義，并非時間錯亂。對同一本地時間的表示，不同時區的人解析得到的UTC時間必定不同，反過來不同本地時間可能對應同一UTC。
格式化后出現的錯亂
即同一Date，在不同時區下格式化得到不同時間表示。
在當前時區和紐約時區格式化2020-11-11 11:11:11
輸出如下，當前時區Offset(時差)是+8小時，對于-5小時的紐約
因此，有時數據庫中相同時間，由于服務器時區設置不同，讀取到的時間表示不同。這不是時間錯亂，而是時區作用，因為UTC時間需根據當前時區解析為正確的本地時間。
所以要正確處理時區，在于存和讀兩階段
- 存，需使用正確的當前時區來保存，這樣UTC時間才會正確
- 讀，也須正確設置本地時區，才能把UTC時間轉換為正確當地時間
Java8處理時區問題
時間日期類ZoneId、ZoneOffset、LocalDateTime、ZonedDateTime和DateTimeFormatter，使用起來更簡單清晰。
初始化上海、紐約和東京三時區
可使用ZoneId.of初始化一個標準時區，也可使用ZoneOffset.ofHours通過一個offset初始化一個具有指定時間差的自定義時區。
日期時間表示
- LocalDateTime無時區屬性，所以命名為本地時區的日期時間
- ZonedDateTime=LocalDateTime+ZoneId，帶時區屬性
因此，LocalDateTime僅是一個時間表示，ZonedDateTime才是一個有效時間。這里將把2020-01-02 22:00:00這個時間表示，使用東京時區解析得到一個ZonedDateTime。
使用DateTimeFormatter格式化時間
可直接通過withZone直接設置格式化使用的時區。最后，分別以上海、紐約和東京三個時區來格式化這個時間輸出：
日志輸出：相同時區，經過解析存和讀的時間表示一樣(比如最后一行)
對不同時區，比如上海/紐約，輸出本地時間不同。
+9小時時區的晚上10點，對上海時區+8小時，所以上海本地時間為早10點
而紐約時區-5小時，差14小時，為晚上9點
小結
要正確處理國際化時間問題，推薦Java8的日期時間類，即
使用ZonedDateTime保存時間
然后使用設置了ZoneId的DateTimeFormatter配合ZonedDateTime進行時間格式化得到本地時間表示
本文轉載自微信公眾號「 JavaEdge」，可以通過以下二維碼關注。轉載本文請聯系 JavaEdge公眾號。
