建站
咨詢
售后
建站咨詢
新聞中心
1 背景
成都網(wǎng)站設計、網(wǎng)站制作,成都做網(wǎng)站公司-創(chuàng)新互聯(lián)已向1000+企業(yè)提供了,網(wǎng)站設計,網(wǎng)站制作,網(wǎng)絡營銷等服務!設計與技術結合,多年網(wǎng)站推廣經(jīng)驗,合理的價格為您打造企業(yè)品質網(wǎng)站。
Java8前，處理日期時間時，使用的“三大件”
- Date
- Calender
- SimpleDateFormat
以聲明時間戳、使用日歷處理日期和格式化解析日期時間。但這些類的API可讀性差、使用繁瑣，且非線程安全，如同設計的翔一樣的IO，也是Java讓人詬病的一大原因。
于是Java8推出全新日期時間類。這些類的API功能強大簡便、線程安全。
但畢竟Java8剛出這些類，諸如序列化、數(shù)據(jù)訪問等類庫都不支持Java8日期時間類，需在新老類中來回切換。比如，在業(yè)務邏輯層使用LocalDateTime，存入數(shù)據(jù)庫或者返回前端的時候還要切換回Date。因此，還不如沿用老的日期時間類。
不過我們生活在最好的時代，基本主流類庫都支持新日期時間類型，但還有項目因還是用祖?zhèn)魅掌跁r間類，出現(xiàn)很多古今交錯的錯誤實踐。
比如
- 通過隨意修改時區(qū)，使讀取到的數(shù)據(jù)匹配當前時鐘
- 直接對讀取到的數(shù)據(jù)做加、減幾個小時的操作，來“修正數(shù)據(jù)”
本文旨在分析古今時間錯亂的本質原因，看看使用遺留日期時間類，來處理日期時間初始化、格式化、解析、計算等可能會遇到的問題，以及如何使用新日期時間類解決。
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改造后，初始化時年參數(shù)直接使用當前年即可，月0~11。亦可直接使用Calendar.DECEMBER初始化月份，肯定不會犯錯。
分別使用當前時區(qū)和紐約時區(qū)初始化兩個相同日期：
日志輸出
顯示兩個不同時間，說明時區(qū)發(fā)生作用。但更習慣年/月/日 時:分:秒日期時間格式，對現(xiàn)在輸出的日期格式還不滿意，那就格式化日期時間
3 時區(qū)問題
全球有24個時區(qū)，同一個時刻不同時區(qū)(比如中國上海和美國紐約)的時間不同。全球化項目，若初始化時間時未提供時區(qū)，那就不是真正意義上的時間，只能認為是我看到的當前時間的一個表示。
3.1 Date類
Date無時區(qū)概念，任一機器使用new Date()初始化得到時間相同。因為，Date中保存的是UTC時間，其為以原子鐘為基礎的統(tǒng)一時間，不以太陽參照計時，無時區(qū)劃分
Date中保存的是一個時間戳，代表從1970年1月1日0點(Epoch時間)到現(xiàn)在的毫秒數(shù)。嘗試輸出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
對于國際化項目，處理好時間和時區(qū)問題首先就是要正確保存日期時間。
這里有兩種
3.2 如何正確保存日期時間
- 保存UTC
保存的時間無時區(qū)屬性，不涉及時區(qū)時間差問題的世界統(tǒng)一時間。常說的時間戳或Java中的Date類就是這種方式，也是推薦方案
- 保存字面量
比如年/月/日 時:分:秒，務必同時保存時區(qū)信息。有了時區(qū)，才能知道該字面量時間真正的時間點，否則它只是一個給人看的時間表示且只在當前時區(qū)有意義。
而Calendar才具有時區(qū)概念，所以通過使用不同時區(qū)初始化Calendar，才能得到不同時間。
正確地保存日期時間后，就是正確展示，即要使用正確時區(qū)，將時間點展示為符合當前時區(qū)的時間表示。至此也就能理解為何會發(fā)生“時間錯亂”。
從字面量解析成時間 & 從時間格式化為字面量
對同一時間表示，不同時區(qū)轉換成Date會得到不同時間戳
比如2020-11-11 11:11:11
對當前上海時區(qū)/紐約時區(qū)，轉化為UTC時間戳不同
- Wed Nov 11 11:11:11 CST 2020:1605064271000
- Thu Nov 12 00:11:11 CST 2020:1605111071000
這就是UTC的意義，并非時間錯亂。對同一本地時間的表示，不同時區(qū)的人解析得到的UTC時間必定不同，反過來不同本地時間可能對應同一UTC。
格式化后出現(xiàn)的錯亂
即同一Date，在不同時區(qū)下格式化得到不同時間表示。
在當前時區(qū)和紐約時區(qū)格式化2020-11-11 11:11:11
輸出如下，當前時區(qū)Offset(時差)是+8小時，對于-5小時的紐約
因此，有時數(shù)據(jù)庫中相同時間，由于服務器時區(qū)設置不同，讀取到的時間表示不同。這不是時間錯亂，而是時區(qū)作用，因為UTC時間需根據(jù)當前時區(qū)解析為正確的本地時間。
所以要正確處理時區(qū)，在于存和讀兩階段
- 存，需使用正確的當前時區(qū)來保存，這樣UTC時間才會正確
- 讀，也須正確設置本地時區(qū)，才能把UTC時間轉換為正確當?shù)貢r間
Java8處理時區(qū)問題
時間日期類ZoneId、ZoneOffset、LocalDateTime、ZonedDateTime和DateTimeFormatter，使用起來更簡單清晰。
初始化上海、紐約和東京三時區(qū)
可使用ZoneId.of初始化一個標準時區(qū)，也可使用ZoneOffset.ofHours通過一個offset初始化一個具有指定時間差的自定義時區(qū)。
日期時間表示
- LocalDateTime無時區(qū)屬性，所以命名為本地時區(qū)的日期時間
- ZonedDateTime=LocalDateTime+ZoneId，帶時區(qū)屬性
因此，LocalDateTime僅是一個時間表示，ZonedDateTime才是一個有效時間。這里將把2020-01-02 22:00:00這個時間表示，使用東京時區(qū)解析得到一個ZonedDateTime。
使用DateTimeFormatter格式化時間
可直接通過withZone直接設置格式化使用的時區(qū)。最后，分別以上海、紐約和東京三個時區(qū)來格式化這個時間輸出：
日志輸出：相同時區(qū)，經(jīng)過解析存和讀的時間表示一樣(比如最后一行)
對不同時區(qū)，比如上海/紐約，輸出本地時間不同。
+9小時時區(qū)的晚上10點，對上海時區(qū)+8小時，所以上海本地時間為早10點
而紐約時區(qū)-5小時，差14小時，為晚上9點
小結
要正確處理國際化時間問題，推薦Java8的日期時間類，即
使用ZonedDateTime保存時間
然后使用設置了ZoneId的DateTimeFormatter配合ZonedDateTime進行時間格式化得到本地時間表示
本文轉載自微信公眾號「 JavaEdge」，可以通過以下二維碼關注。轉載本文請聯(lián)系 JavaEdge公眾號。
文章標題：大廠如何使用Java8日期時間?
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/dhosodg.html
