# 前言 你好，我是A哥(YourBatman)。 好看的程式碼，千篇一律！難看的程式碼，臥槽臥槽~其實沒有什麼程式碼是“史上最爛”的，要有也只有“史上更爛”。 日期是商業邏輯計算的一個**關鍵部分**，任何企業的程式都需要正確的處理日期時間問題，否則很可能帶來事故和損失。為此本系列僅著眼於這一個點就寫了好幾篇文章，目的是幫助你係統化的搞定所有問題/難題。 平時我們都熱衷於吐槽同事的程式碼有多爛，今天我們就來玩點狠的：吐槽吐槽JDK，看看它的日期時間API設計得到底有多爛。 > 說明：本文指的日期時間API是Date/Calendar系列，而非Java 8新的API。畢竟一般我們稱後者為JSR 310日期時間，請注意區分哈 ## 本文提綱  ## 版本約定 - JDK：8 # 正文 誠然，Java的API絕大多數設計得都是非常優秀且成功的，否則Java也不可能成為程式語言界的常青藤，並且還常年霸榜。**但是**，JDK也有失手的地方，存在設計得非常爛的API，先來了解下。 ## 最爛API投票 談到對Java API不滿意程度的調研，最出名的當屬2010年國外一個大佬Tiago Fernandez發起的一個很有意思的投票，投票結果的資料統計圖表如下：  對橫向標題欄的各個單詞解釋一下，從左到右依次為：  計算最終得分的公式為： ```java Score = (I can live with) + (Painful * 2) + (Crappy * 3) + (Hellish * 4) ``` 按照此公式，計算出各API的得分，畫成直方圖直觀的展示出來：  好，排名出來了。從最爛 -> 最好的名次依次為： 1. EJB 2.x，簡直“遙遙領先” 2. **Date/Time/Calendar，今天的豬腳** 3. XML/DOM 4. AWT/Swing 5. ... 爛歸爛，想一想什麼樣的爛API對你的產生影響會是最大的呢？答：**很常用卻很爛的**。倘若一個API設計得很爛但你很少用或者幾乎不用接觸，你也不會對它產生很大厭惡感。打個比方，一堆屎本身很臭，但若你並不需要走到它身旁也就聞不到，自然就不會覺得它有多礙眼了。 回到這個統計結果來，EJB 2.x的API設計得最爛這個結果無可厚非，但站在時間維度的現在(2021年)回頭來看，是可以完全忽略它了，畢竟現在的我們絕無可能再接觸到它，再爛又有何干呢？ EJB 2.x這個老古董，相信在看文章的絕大部分同學都沒見過甚至沒聽過它吧，A哥2015年入行，一上來Spring 4.x嘎嘎就是幹，從未接觸過EJB。 > 說明：這個統計是2010年做的，那會EJB2.x的使用量還比較大，因此上了“榜首” XML/DOM設計得也不好，但已完全被第三庫（如dom4j）取代，後者成為了事實的標準；AWT/Swing是市場的抉擇，你用Java開發介面才會用到，否則不會接觸，屬於正常。 最後再看“屈居”第二名的Date/Time/Calendar日期時間API，它就不得了了。畢竟此API有個很大的特點：哪怕到了現在(2021年)依舊非常常用。所以，它設計得爛帶來的實際影響是蠻大的。 下面就來具體瞭解下它有哪些坑爹的設計和槽點，一起不吐不快。 ## 日期時間API的七宗罪  ### 罪狀一：Date同時表示日期和時間 java.util.Date被設計為日期 + 時間的結合體。也就是說如果只需要日期，或者只需要單純的時間，用Date是做不到的。 ```java @Test public void test1() { System.out.println(new Date()); } 輸出： Fri Jan 22 00:25:06 CST 2021 ``` 這就導致語義非常的不清晰，比如說： ```java /** * 是否是假期 */ private static boolean isHoliday(Date date){ return ...; } ``` 判斷某一天是否是假期，只和日期有關，和具體時間沒有關係。如果程式碼這樣寫語義只能靠註釋解釋，方法本身無法達到自描述的效果，也無法通過強型別去約束，因此容易出錯。 > 說明：本文所有例子不考慮時區問題，下同 ### 罪狀二：坑爹的年月日 ```java @Test public void test2() { Date date = new Date(); System.out.println("當前日期時間：" + date); System.out.println("年份：" + date.getYear()); System.out.println("月份：" + date.getMonth()); } 輸出： 當前日期時間：Fri Jan 22 00:25:16 CST 2021 年份：121 月份：0 ``` what？年份是121年，這什麼鬼？月份返回0，這又是什麼鬼？ 無奈，看看這兩個方法的Javadoc：   尼瑪，原來 2021 - 1900 = 121是這麼來的。那麼問題來了，為何是1900這個數字呢？ 月份，竟然從0開始，這是學的誰呢？簡直打破了我認為的只有index索引值才是從0開始的認知啊，這種做法非常的不符合人類思維有木有。 > 索引值從0開始就算了，畢竟那是給計算機看的無所謂，但是你這月份主要是給人看的呀 ### 罪狀三：Date是可變的 oh my god，也就是說我把一個Date日期時間物件傳給你，你竟然還能給我改掉，真是太沒安全感可言了。 ```java @Test public void test() { Date currDate = new Date(); System.out.println("當前日期是①：" + currDate); boolean holiday = isHoliday(currDate); System.out.println("是否是假期：" + holiday); System.out.println("當前日期是②：" + currDate); } /** * 是否是假期 */ private static boolean isHoliday(Date date) { // 架設等於這一天才是假期，否則不是 Date holiday = new Date(2021 - 1900, 10 - 1, 1); if (date.getTime() == holiday.getTime()) { return true; } else { // 模擬寫程式碼時不注意，使壞 date.setTime(holiday.getTime()); return true; } } 輸出： 當前日期是①：Fri Jan 22 00:41:59 CST 2021 是否是假期：true 當前日期是②：Fri Oct 01 00:00:00 CST 2021 ``` 我就像讓你幫我判斷下遮天是否是假期，然後你竟然連我的日期都給我改了？過分了啊。這是多麼可怕的事，存在重大安全隱患有木有。 針對這種case，一般來說我們函式內部操作的引數只能是**副本**：要麼呼叫者傳進來的就是副本，要麼內部自己生成一個副本。 在本利中提高程式健壯性只需在isHoliday首行加入這句程式碼即可： ```java private static boolean isHoliday(Date date) { date = (Date) date.clone(); ... } ``` 再次執行程式，輸出： ```java 當前日期是①：Fri Jan 22 00:44:10 CST 2021 是否是假期：true 當前日期是②：Fri Jan 22 00:44:10 CST 2021 ``` bingo。 但是呢，Date作為高頻使用的API，並不能要求每個程式設計師都有這種安全意識，畢竟即使百密也會有一疏。所以說，把Date設計為一個可變的類是非常糟糕的設計。 ### 罪狀四：無法理喻的java.sql.Date 來，看看java.util.Date類的繼承結構：  它的三個子類均處於java.sql包內。且先不談這種垮包繼承的合理性問題，直接看下面這個使用例子： ```java @Test public void test3() { // 竟然還沒有空構造器 // java.util.Date date = new java.sql.Date(); java.util.Date date = new java.sql.Date(System.currentTimeMillis()); // 按到當前的時分秒 System.out.println(date.getHours()); System.out.println(date.getMinutes()); System.out.println(date.getSeconds()); } ``` 執行程式，暴雷了： ```java java.lang.IllegalArgumentException at java.sql.Date.getHours(Date.java:187) at com.yourbatman.formatter.DateTester.test3(DateTester.java:65) ... ``` what？又是一打破認知的結果啊，第一句getHours()就報錯啦。走進java.sql.Date的方法原始碼進去一看，握草重寫了父類方法：  還有這麼重寫父類方法的？還有王法嗎？這也算是JDK能幹出來的事？赤裸裸的違背里氏替換原則等眾多設計原則，子類能力竟然比父類小，使用起來簡直讓人云裡霧裡。 java.util.Date的三個子類均位於java.sql包內，他們三是通過Javadoc描述來進行分工的： - java.sql.Date：只表示日期 - java.sql.Time：只表示時間 - java.sql.Timestamp：表示日期 + 時間 這麼一來，似乎可以“理解”java.sql.Date為何重寫父類的getHours()方法改為丟擲IllegalArgumentException異常了，畢竟它只能表示日期嘛。但是這種通過繼承再閹割的實現手法你們接受得了？反正我是不能的~ ### 罪狀五：無法處理時區 因為日期時間的特殊性，不同的國家地區在**同一時刻**顯示的日期時間應該是不一樣的，但Date做不到，因為它底層程式碼是這樣的：  也就是說它表示的是一個具體時刻（時間戳），這個數值放在全球任何地方都是一模一樣的，也就是說new Date()和System.currentTimeMillis()沒啥兩樣。 JDK提供了TimeZone表示時區的概念，但它在Date裡並無任何體現，只能使用在格式化器上，這種設計著實讓我再一次看不懂了。 ### 罪狀六：執行緒不安全的格式化器 關於Date的格式化，站在架構設計的角度來看，首先不得不吐槽的是Date明明屬於java.util包，那麼它的格式化器DateFormat為毛卻跑到java.text裡去了呢？這種依賴管理的什麼鬼？是不是有點太過於隨意了呢？ 另外，JDK提供了一個DateFormat的子類實現SimpleDateFormat專門用於格式化日期時間。**但是**它卻被設計為了執行緒不安全的，一個定位為模版元件的API竟然被設計為執行緒不安全的類，實屬瞎整。 就因為這個坑的存在，讓多少初中級工程師淚灑職場，算了說多了都是淚。另外，因為執行緒不安全問題並非必現問題，因此在黑盒/白盒測試、功能測試階段都可能測不出來，留下潛在風險。 > 這就是“靈異事件”：測試環境測試得好好的，為何到線上就出問題了呢？ ### 罪狀七：Calendar難當大任 從JDK 1.1 開始，Java日期時間API似乎進步了些，引入了Calendar類，並且對職責進行了劃分： - Calendar類：日期和時間欄位之間轉換 - DateFormat類：格式化和解析字串 - Date類：**只**用來承載日期和時間 有了Calendar後，原有Date中的大部分方法均標記為廢棄，交由Calendar代替。  Date終於單純了些：只需要展示日期時間而無需再顧及年月日操作、格式化操作等等了。值得注意的是，這些方法只是被標記為過期，並未刪除。即便如此，請在實際開發中也**一定不要使用**它們。 引入了一個Calendar似乎分離了職責，但Calendar難當大任，設計上依舊存在很多問題。 ```java @Test public void test4() { Calendar calendar = Calendar.getInstance(TimeZone.getDefault()); calendar.set(2021, 10, 1); // -> 依舊是可變的 System.out.println(calendar.get(Calendar.YEAR)); System.out.println(calendar.get(Calendar.MONTH)); System.out.println(calendar.get(Calendar.DAY_OF_MONTH)); } 輸出： 2021 10 1 ``` 年月日的處理上似乎可以接受沒有問題了。從結果中可以發現，Calendar年份的傳值不用再減去1900了，這和Date是不一樣的，不知道這種行為不一致會不會讓有些人抓狂。 > 說明：Calendar相關的API是由IBM捐過來的，所以和Date不一樣貌似也“情有可原” 另外，還有個重點是Calendar依舊是可變的，所以存在不安全因素，參與計算改變值時請使用其副本變數。 總的來說，Calendar在Date的基礎上做了改善，但僅限於修修補補，**並未從根本上解決問題**。最重要的是Calendar的API使用起來真的很不方便，而且該類在語義上也完全不符合日期/時間的含義，使用起來更顯尷尬。 總之，無論是Date，還是Calendar，還是格式化DateFormat都用著太方便，且存在各式各樣的安全隱患、執行緒安全問題等等，這是API沒有設計好的地方。 ## 並不孤單 日期時間API屬於基礎API，在各個語言中都是必備的。然而不僅僅是Java面臨著API設計很爛的處境，有些其它流行語言一樣如此，湧現出1個(1堆)三方庫比乙方庫設計更好的情況，比如： - **Python**：日期時間處理庫Arrow - **JavaScript**：日期時間處理庫Moment.js - **.Net**：日期時間處理庫Joda-Time 所以說，Java它並不孤單（自我安慰一把） ## 自我救贖：JSR 310 因為原生的Date日期時間體系存在“**七宗罪**”，催生了第三方Java日期時間庫的誕生，如大名鼎鼎的Joda-Time的流行甚至一度成為標配。 對於Java來說，如此重要的API模組豈能被第三方庫給佔據，開發者本就想簡單的處理個日期時間還得匯入第三方庫，使用也太不方便了吧。當時的Java如日中天，因此就開啟了“收編”Joda-Time之旅。 2013年9月份，具有劃時代意義的Java 8大版本正式釋出，該版本帶來了非常多的新特性，其中最引入矚目之一便是全新的日期時間API：JSR 310。  JSR 310規範的領導者是Stephen Colebourne，此人也是Joda-Time的締造者。不客氣的說JSR 310是在Joda-Time的基礎上建立的，參考了其絕大部分的API實現，因此若你之前是Joda-Time的重度使用者，現在遷移到Java 8原生的JSR 310日期時間上來幾乎無縫。 即便這樣，也並不能說JSR 310就完全等於Joda-Time的官方版本，還是有些許詫異的，例舉如下： 1. 首先當然是包名的差別，org.joda.time -> java.time標準日期時間包 2. **JSR 310不接受null值，Joda-Time把Null值當0處理** 3. JSR 310所有丟擲的異常是DateTimeException，它是個RuntimeException，而Joda-Time都是checked exception 簡單感受下JSR 310 API： ```java @Test public void test5() { System.out.println(LocalDate.now(ZoneId.systemDefault())); System.out.println(LocalTime.now(ZoneId.systemDefault())); System.out.println(LocalDateTime.now(ZoneId.systemDefault())); System.out.println(OffsetTime.now(ZoneId.systemDefault())); System.out.println(OffsetDateTime.now(ZoneId.systemDefault())); System.out.println(ZonedDateTime.now(ZoneId.systemDefault())); System.out.println(DateTimeFormatter.ISO_LOCAL_DATE.format(LocalDate.now())); System.out.println(DateTimeFormatter.ISO_LOCAL_TIME.format(LocalTime.now())); System.out.println(DateTimeFormatter.ISO_LOCAL_DATE_TIME.format(LocalDateTime.now())); } ``` JSR 310的所有物件都是**不可變**的，所以執行緒安全。和老的日期時間API相比，**最主要**的特徵對比如下： **JSR 310** | **Date/Calendar** | **說明** -------- | ----- | ----- 流暢的API | 難用的API | API設計的好壞最直接影響程式設計體驗，前者大大大大優於後者 例項不可變 | 例項可變 | 對於日期時間例項，設計為可變確實不合理也不安全。都不敢放心的傳遞給其它函式使用 執行緒安全 | 執行緒不安全 | 此特性直接決定了編碼方式和健壯性 關於JSR 310日期時間更多介紹此處就不展開了，畢竟前面文章囉嗦過好多次了。總之它是Java的新一代日期時間API，設計得非常好，**幾乎沒有缺點可言**，可用於100%替代老的日期時間API。 如果你到現在2021年了還沒擁抱它，那麼請問你還在等啥呢？ # 總結 日期時間API因為過於常用，因此你可能都覺得它毫不起眼。坦白的說，如果你沒有複雜的日期時間需求要處理，如涉及到時區、偏移量、跨時區轉換、國際化顯示等等，那麼可能覺得Date也能將就。 **如果你不想做個將就的人，如果你想擁有更好的日期時間程式設計體驗，棄用Date，擁抱JSR 310吧。** ## 本文思考題 本文所屬專欄：**JDK日期時間**，後臺回覆專欄名即可獲取全部內容。本文已被*https://www.yourbatman.cn*收錄。 **看完了不一定懂，看懂了不一定會**。來，文末3個思考題幫你覆盤： 1. 偏移量Z代表什麼含義？ 2. ZoneId和ZoneOffset是如何建立對應關係的？ 3. 若某個城市不在ZoneId列表裡面，想要獲取其UTC偏移量該怎麼破？ ## 推薦閱讀 - [GMT UTC CST ISO 夏令時 時間戳，都是些什麼鬼？](https://mp.weixin.qq.com/s/VdoQt88JfjPJTL9XgohZJQ) - [全網最全！徹底弄透Java處理GMT/UTC日期時間](https://mp.weixin.qq.com/s/R2OTG9xkUBUsd4xqQ1ND9A) - [LocalDateTime、OffsetDateTime、ZonedDateTime互轉，這一篇絕對餵飽你](https://mp.weixin.qq.com/s/_Zt4JcUokea-zha0gCFnsA)  ```java System.out.println("點個贊吧!"); print_r('關注【BAT的烏托邦】！'); var_dump('點個贊吧！'); NSLog(@"關注【BAT的烏托邦】！"); console.log("點個贊吧！"); print("關注【BAT的烏托邦】！"); printf("點個贊吧！"); cout << "關注【BAT的烏托邦】！" << endl; Console.WriteLine("點個贊吧！"); fmt.Println("關注【BAT的烏托邦】！"); Response.Write("點個贊吧！"); alert("關注【BAT的烏托邦】！"); echo("點個贊吧！"); ``` 作者簡介：A哥(YourBatman)，Spring Framework/Boot開源貢獻者，Java架構師，愛分享。**非常注重基本功修養**，底層基礎決定上層建築，才能煥發程式設計師更強生命力。非常擅長結構化講述專題，抽絲剝繭頗具深度。這些專題也許可能大概是**全網最好或獨一份**哦，歡迎自取。