本文主要探討和時區(qū)相關(guān)的概念罚屋，并以jdk8的Date/Time API為例，明確我們在處理和時區(qū)相關(guān)的問題時榜聂，應當如何正確理解和使用已有的API，其他的編程語言和工具涝桅，應當也是可以觸類旁通的拜姿。

提出問題

時間是我們最熟悉不過的概念，日常工作中也經(jīng)常要處理和時間相關(guān)的業(yè)務需求冯遂，比如用戶創(chuàng)建時間蕊肥、最后更新時間等等，常用的編程語言一般都提供了成熟的工具類庫和API蛤肌，來協(xié)助我們實現(xiàn)時間的生成壁却、轉(zhuǎn)化、格式化顯示等需求裸准，因此大多數(shù)場景下時間的處理并不是一個復雜的問題展东。

但是時區(qū)正是其中比較復雜和容易出錯的一類問題，這個復雜性主要來源于兩個方面：一是和時區(qū)相關(guān)的概念紛繁復雜炒俱，常見的像如UTC時間盐肃、DST時間、GMT权悟、CST砸王、本地時間等等；另外一個原因是我們常見的應用不太會垮時區(qū)部署峦阁，因此也不太會關(guān)注時區(qū)的處理谦铃，一般都是用系統(tǒng)默認時區(qū)即可，因此一旦出現(xiàn)和時區(qū)相關(guān)的問題榔昔，往往感覺模棱兩可驹闰。

雖然我們直接使用時區(qū)的場景不多，但是編寫代碼時常用的工具類庫撒会、數(shù)據(jù)庫等系統(tǒng)嘹朗，都隱含了對時區(qū)的處理，導致我們不經(jīng)意之間一直在使用時區(qū)诵肛，如果不能對這些時區(qū)概念有正確的理解屹培，就很容易觸發(fā)一些隱含的問題。

本文將從一個最簡單的時區(qū)轉(zhuǎn)化問題出發(fā)曾掂，闡明處理時區(qū)問題時所涉及的概念惫谤。

• 問題：歐冠決賽在北京時間2020年8月24日 03:00開始壁顶，那么比賽開始時珠洗，倫敦的當?shù)貢r間是什么時候？

從日常經(jīng)驗來看若专，北京位于東八區(qū)许蓖，而倫敦位于零時區(qū)，北京時間應該比倫敦時間快8個小時，那真正的結(jié)果是這樣嗎膊爪？我們在代碼中應當如何做這個時區(qū)的轉(zhuǎn)化呢自阱？

概念解讀

分析時區(qū)問題時有一個最基本的準則，那就是：

• 絕對時間 = 本地時間 & 時區(qū)偏移量 （AbsoluteTime = LocalDateTime & Offset）

具體含義是米酬，本地時間和時區(qū)偏移量的信息組合可以描述一個絕對時間沛豌。

絕對時間、本地時間赃额、時區(qū)偏移量的概念將在下面一一解讀加派。

1.絕對時間（AbsoluteTime）

絕對時間可以理解為一個放之四海而皆準的時間，舉個例子跳芳，UTC時間就是一個絕對時間芍锦，當我們記錄一個時間為1970-01-01T00:00:00Z（UTC描述時間的標準格式）時，這個時間的定義是沒有任何歧義的飞盆，它指向絕對時間線上的一個確定的時刻娄琉；從另一個角度說，在同一時刻吓歇，地球上的任何角落同時發(fā)生的事情孽水，他們的UTC時間也一定是相同的，這就是絕對時間照瘾。

另外一個常見的絕對時間是Unix時間戳匈棘，它也指向絕對時間線上的一個確定的時刻，不受所在地的影響析命。

正是因為絕對時間對時間的描述不存在任何歧義主卫，因此將時間轉(zhuǎn)化為絕對時間來處理是非常可靠的鹃愤，這也是我們在處理時區(qū)問題時的不二法門簇搅。

2.本地時間（LocalDateTime）

先舉個本地時間的例子，上面的描述中“歐冠決賽在北京時間2020年8月24日 03:00開始“软吐，其中的“北京時間2020年8月24日 03:00”是我們這里所說的本地時間嗎瘩将？答案是否定的，這里的本地時間是指“2020年8月24日 03:00”凹耙，并不包含“北京時間”這個和時區(qū)相關(guān)的描述姿现。本地時間僅僅是指的關(guān)于年月日、時分秒等信息的一個描述肖抱，并不包含所在的時區(qū)备典，這是一個非常容易混淆的地方。再次明確一遍意述，我們確實是在某一個時區(qū)下得到了“本地時間”提佣，但是我們得到的“本地時間”本身是不包含時區(qū)的吮蛹，這是理解時區(qū)問題時非常關(guān)鍵的一點。

為了進一步區(qū)分絕對時間和本地時間的概念拌屏，我們對常見的時間類型做些歸類潮针。

3.時區(qū)偏移量（Offset）

全球分為24個時區(qū)每篷，每個時區(qū)和零時區(qū)相差了數(shù)個小時，也就是這里所說的時區(qū)偏移量Offset端圈，比如東八區(qū)和零時區(qū)有+08:00的偏移量雳攘。還是回到上面的例子，“北京時間2020年8月24日 03:00”本質(zhì)上是一個絕對時間枫笛，表示成UTC時間是2020-08-24T03:00:00+08:00吨灭，其中的2020-08-24T03:00:00是本地時間，而+08:00表示的是時區(qū)偏移量刑巧。UTC的表示方法正印證了上面所闡述的準則：絕對時間=本地時間&時區(qū)偏移量喧兄。

時區(qū)偏移量的概念比較簡單，但是計算卻比較復雜啊楚，其計算方式是：

• 時區(qū)偏移量 = 地區(qū) & 規(guī)則 （Offset = Zone & Rules）

這里的規(guī)則（Rules）可能是一個變化的值吠冤，如果我們單純地認為中國的時區(qū)偏移量是8個小時，就出錯了恭理，事實是拯辙，中國采用的不一定總是東八區(qū)時間，也可能是東九區(qū)時間颜价，出現(xiàn)這個情況因為夏令時的存在（夏令時即DST時間涯保，1992年之后中國已經(jīng)沒有再實行過夏令時了，所以大家對這個概念并不熟悉周伦，這是一個比較有意思的時間規(guī)定夕春，感興趣的同學可以參看文末附錄），當實行夏令時的時候专挪，中國標準時間的時區(qū)偏移量就是+09:00及志。因此，一個地區(qū)的時區(qū)偏移量是多少寨腔，是由當?shù)氐恼邲Q定的速侈，可能會隨著季節(jié)而發(fā)生變化，這就是上面所說的“規(guī)則”（Rules）迫卢。

好在倚搬，這些復雜的規(guī)則一般都被我們的API支持了，但是我們必須意識到的一點是靖避，“Asia/Shanghai”和“+08:00”是不同的時區(qū)描述潭枣，“Asia/Shanghai”只是描述了地區(qū)，而“+08:00”描述了準確的時區(qū)偏移量幻捏，不能將它們看作等價盆犁，比如在實行夏令時的時候，這兩種描述得到的本地時間就是不同的篡九。

實際上谐岁，時區(qū)還有更多復雜的規(guī)定，我們不再去深究榛臼，目前已知的這些足夠我們處理日常的需求了伊佃。

Java jdk8的Date/Time API介紹

jdk8之前的Date/Time API被吐槽已久，如果你不幸是從jdk8之前的Date Calendar類開始了解時間類的處理沛善，很可能會一頭霧水航揉，其用法和缺點我們這里不再探討，強烈推薦直接使用jdk8提供了新的Date/Time API金刁。

1.Date/Time API常用類的介紹

jdk8 Date/Time API中常用的類完全符合我們上述提到的概念：

• 絕對時間：java.time.Instant, java.time.OffsetDateTime, java.time.ZonedDateTime

• 本地時間：java.time.LocalDateTime

• 時區(qū)偏移量：java.time.ZoneOffset

1.1 java類庫中的絕對時間

Instant本質(zhì)上是一個Unix時間戳帅涂，Unix時間戳是可以表示絕對時間的，只不過Instant內(nèi)部用了兩個long的對象分別表示秒和納秒尤蛮，從而將精度支持到了納秒級別媳友。

OffsetDateTime是一個包含了時區(qū)（offset）信息的時間類型，內(nèi)部保存了LocalDateTime（本地時間）和offset产捞，由于本地時間和時區(qū)信息都是完整的醇锚，所以OffsetDateTime是一個絕對時間。

ZonedDateTime是一個包含了地區(qū)（zone）信息的時間類型坯临，內(nèi)部保存了LocalDateTime(本地時間)和zone焊唬，由上述兩個值可以計算出時區(qū)（offset），因此也是一個絕對時間看靠。

這里有兩個問題可以探討：

• 問題一：這三個類都是絕對時間求晶，那么他們是否可以互相轉(zhuǎn)化呢？

• 問題二：鑒于ZonedDateTime和OffsetDateTime定義是很接近的衷笋，那么使用時該如何選擇呢芳杏？

問題一我們在這里直接回答：答案是只能進行有限的轉(zhuǎn)化，因為三者所包含的信息量是不同的辟宗，如圖爵赵。

image-20201227203413024

從外圍向內(nèi)部的轉(zhuǎn)化是支持的，而從內(nèi)部向外圍的轉(zhuǎn)化必需要補充一些額外的信息（當然這些信息可能是隱含補入的泊脐，如本機所在的時區(qū)）空幻；否則只能進行一些特殊的轉(zhuǎn)化，比如將OffsetDateTime直接轉(zhuǎn)成ZonedDateTime的API文檔說明了這一點：This creates the simplest possible ZonedDateTime using the offset as the zone ID.

問題二我們在后面單獨討論容客。

1.2 java類庫中的本地時間

java中對本地時間的描述非常簡單明確秕铛，LocalDateTime類约郁，內(nèi)部包含了LocalDate和LocalTime兩個成員變量，其中LocalDate表示年月日的日期組合但两，而LocalTime表示時分秒納秒的時間組合鬓梅，本質(zhì)上，LocalDateTime只是一個關(guān)于日期和時間的描述谨湘，沒有任何時區(qū)信息绽快，符合我們對本地時間的定義。

當我們描述的只是一個關(guān)于日期或時間的組合紧阔，而不是一個絕對時間的時候坊罢，直接使用本地時間即可，比如記錄一個人的生日擅耽。

1.3 java類庫中的時區(qū)偏移量

ZoneOffset對應了一個確定的時區(qū)偏移量活孩。至于上面提到的

• 時區(qū)偏移量 = 地區(qū) & 規(guī)則（Offset = Zone & Rules）

其中地區(qū)（Zone）在java中對應著ZoneRegion類，Rules對應ZoneRules類乖仇。同時诱鞠，為了簡化用戶的使用，Java對此做了進一步抽象这敬，設計了ZoneId類用來統(tǒng)籌ZoneOffset和ZoneRegion航夺，通過ZoneId.of("Asia/Shanghai")可以直接生成ZoneRegion，而ZoneId.of("+8")可以生成ZoneOffset崔涂。

其他使用具體API的最佳實踐阳掐，java提供的官方文檔十分明確，且網(wǎng)絡上隨處可查冷蚂，本文不再贅述缭保，相信明確了上述概念之后，再見到這些繁多的API時已經(jīng)能做到心中有數(shù)蝙茶。

2.使用ZonedDateTime還是OffsetDateTime艺骂？

這個問題OffsetDateTime的官方文檔中的解答是

It is intended that {@code ZonedDateTime} or {@code Instant} is used to model data in simpler applications. 
This class(OffsetDateTime) may be used when modeling date-time concepts in more detail, or when communicating to a database or in a network protocol.

具體來看，其中modeling date-time concepts in more detail應當是針對Instant來說的隆夯，OffsetDateTime比Instant信息更豐富（多了時區(qū)信息）钳恕，而communicating to a database or in a network protocol是針對ZonedDateTime來說的，也就是當我們使用數(shù)據(jù)庫以及網(wǎng)絡通信時要使用OffsetDateTime蹄衷，那么原因是什么呢忧额？

因為ZonedDateTime存儲的是地區(qū)（Zone）信息，再通過Rules計算出具體的offset愧口，而問題就在于睦番，Rules是一個政策性的規(guī)則，是不穩(wěn)定的，存在不同的版本托嚣，不同客戶端使用的Rules也可能是不同的巩检，尤其是當我們處理一個未來時間的時候這個問題更加突出，畢竟未來的政策又有誰能預測呢示启？這就導致我們發(fā)送的時間和其他應用解讀到的時間可能會產(chǎn)生差異兢哭，我們保存在數(shù)據(jù)庫中的時間，當未來讀取出來時也可能做出不同的解讀丑搔，所以這種這種情況下，推薦使用OffsetDateTime提揍，因為直接傳遞和保存確定的offset是不會產(chǎn)生歧義的啤月。

那么ZonedDateTime在什么情況下使用呢？當我們必須要使用夏令時或其他地區(qū)性規(guī)則的時候劳跃，應當轉(zhuǎn)化為ZonedDateTime來使用谎仲。

問題分析和解決

那么我們回到最開始的問題：

• 問題：歐冠決賽在北京時間2020年8月24日 03:00開始，那么比賽開始時刨仑，倫敦的當?shù)貢r間是什么時候郑诺？

在明確了上述概念的基礎(chǔ)上，我們可以對問題做進一步分析杉武，因為比賽開始的絕對時間是相同的辙诞，所以有：

歐冠決賽開始的絕對時間 = 北京的本地時間 & 北京的時區(qū)偏移量 = 倫敦的本地時間 & 倫敦的時區(qū)偏移量

因此只要確定北京和倫敦的時區(qū)偏移量，就可以求得倫敦的本地時間了轻抱。分析到這里飞涂，我們已經(jīng)可以通過Java提供的API來解決上述問題了，Java工具類內(nèi)部會進行時區(qū)偏移量的計算祈搜，不需要我們親自處理较店。

1.Java jdk8的Date/Time API解決時區(qū)轉(zhuǎn)化問題

// Step#1：北京地區(qū)
// 地區(qū)：
ZoneId zoneOfBeijing = ZoneId.of("Asia/Shanghai");
// 本地時間：2020-08-24 03:00
LocalDateTime localDateTimeOfBeijing = LocalDateTime.of(2020, 8, 24, 3, 0);
// 絕對時間：ZonedDateTime表示
ZonedDateTime zonedDateTimeOfBeijing = ZonedDateTime.of(localDateTimeOfBeijing, zoneOfBeijing);

// Step#2：絕對時間轉(zhuǎn)化成Instant類型（時間戳類型）
Instant absoluteInstant = zonedDateTimeOfBeijing.toInstant();

// Step#3：倫敦地區(qū)
// 地區(qū)：
ZoneId zoneOfLondon = ZoneId.of("Europe/London");
// 絕對時間：將Instant絕對時間轉(zhuǎn)化成倫敦地區(qū)的ZonedDateTime
ZonedDateTime zonedDateTimeOfLondon = ZonedDateTime.ofInstant(absoluteInstant, zoneOfLondon);
// 本地時間：
LocalDateTime localDateTimeOfLondon = zonedDateTimeOfLondon.toLocalDateTime();

System.out.println("北京本地時間：" + localDateTimeOfBeijing);
System.out.println("北京時區(qū)偏移量：" + zonedDateTimeOfBeijing.getOffset());
System.out.println("倫敦本地時間：" + localDateTimeOfLondon);
System.out.println("倫敦時區(qū)偏移量：" + zonedDateTimeOfLondon.getOffset());

/*
北京本地時間：2020-08-24T03:00
北京時區(qū)偏移量：+08:00
倫敦本地時間：2020-08-23T20:00
倫敦時區(qū)偏移量：+01:00
 */

最終得出的結(jié)果，倫敦的本地時間是2020年8月23日 20:00容燕，北京時間比倫敦時間快了7個小時梁呈，這是因為倫敦當時正在實行夏令時，時區(qū)偏移量是+01:00蘸秘。

2.普通的計算方法解決時區(qū)轉(zhuǎn)化問題

如果拋開API官卡，用普通的算數(shù)方法，我們需要進一步明確上述關(guān)系中的&該如何具體化醋虏，直接給出一種方法味抖，我們利用零時區(qū)時間表示的絕對時間來做一個過渡，已知滿足：

• 零時區(qū)的時間（絕對時間） = 本地時間 - 本地時區(qū)偏移量

可以得到：

北京的本地時間 - 北京的時區(qū)偏移量 = 倫敦的本地時間 - 倫敦的時區(qū)偏移量

即：

倫敦的本地時間 = 北京的本地時間 - (北京的時區(qū)偏移量 - 倫敦的時區(qū)偏移量)

對于時區(qū)偏移量我們直接給出結(jié)論：北京時間2020年8月24日 03:00灰粮，北京的時區(qū)偏移量為+08:00仔涩，而倫敦的時區(qū)偏移量為+01:00（倫敦當時正在實行夏令時）。

因此：

倫敦的本地時間 = 2020年8月24日 03:00 - (+08:00 - +01:00) = 2020年8月23日 20:00

結(jié)論

本文看似是上繞了一個很大的圈子粘舟，解決了一個非常簡單的時區(qū)轉(zhuǎn)化問題熔脂，過程中唯一要注意的坑不過是一個夏令時而已佩研，是但在分析這個問題的過程中，把相關(guān)的概念做了詳細的介紹霞揉，我們也看到了jdk8 Date/Time的API設計在概念上是非常清晰的旬薯，理解這些概念也便于我們正確使用API，避免做一些想當然的轉(zhuǎn)化适秩。

在實際應用中绊序，和時區(qū)相關(guān)的還有一些更重要的問題，比如在數(shù)據(jù)庫中如何保存時間秽荞，以及可能存在哪些隱含的問題等骤公，這些問題的分析也要建立在充分理解上述概念的基礎(chǔ)上，篇幅所限扬跋，將在后面的文章中做進一步探討阶捆。

附

隨著人認知的不斷加深、測量方法的不斷提升钦听，時間的表示規(guī)范也在不斷演化洒试，也引入了眾多的和時間相關(guān)的標準，但是不管怎么樣朴上，這些標準的目標都是為了規(guī)范時間的表示垒棋，使我們從類似于2020-02-02 20:20:20Z這樣的描述下，能定位到一個公認的痪宰、確定的時刻捕犬。下面就主要介紹一下當前使用的主要時間標準，主要介紹的概念是UTC酵镜、GMT碉碉、DST、CST淮韭，其他的僅做了解即可垢粮。

當前，使用的最廣泛的世界時間標準是世界協(xié)調(diào)時（Coordinated Universal Time）靠粪，簡稱UTC蜡吧，這個簡稱是由英文縮寫（CUT）和法文縮寫（TUC）妥協(xié)而來。

UTC有個比較特別的地方占键，存在一個閏秒的機制昔善，閏秒是為了將UTC時間和世界時（UT，下面會介紹世界時）對齊畔乙，確切的說是保證UTC和UT1（世界時的一種形式）相差不超過0.9s君仆。那么UTC和UT1為什么會出現(xiàn)差距呢？簡單說是因為二者對1s的計量方式不同，UTC采用的是原子時（TAI）的1秒（這也是當前對于1秒的標準定義）返咱，而UT1的1s和地球的自轉(zhuǎn)速度有關(guān)钥庇，觀測發(fā)現(xiàn)，相對于原子時咖摹，地球的自轉(zhuǎn)速度是逐漸變慢的评姨，導致UT1會逐漸慢于UTC，因此UTC每隔一段時間（幾年）就要加1s等一等UT1萤晴，上一次閏秒就出現(xiàn)在2015年吐句，當時我們可以看到2015年6月30日23:59:60這樣的時間。

另外一個問題店读，為什么UTC一定要和UT1對齊呢嗦枢，直接使用UTC時間不就可以了？我認為两入，這是因為UTC是要服從于歷法的净宵，UTC仍舊是采用了年月日時分秒這樣的格式敲才，這顯然是歷法規(guī)定的格式裹纳，而太陽東升西落一次就是一天，四季輪回一次就是一年紧武，這是歷法的要求剃氧，也符合人類的認知習慣，UTC只是一套按照歷法的格式描述時間的標準而已阻星，不應當打破歷法本身朋鞍。因此，UTC引入了不太優(yōu)雅的閏秒機制來修正和歷法之間的沖突妥箕，當然也有一些聲音希望能有一套不需要閏秒的時間標準取代UTC滥酥，現(xiàn)在仍然存在著爭議。

上面提到了世界時（UT）和原子時（TAI）只需要簡單理解就可以畦幢，因為日常生活中我們不會直接使用到它們坎吻。世界時有多個形式，UT0宇葱、UT1等等瘦真，分別考慮了不同的因素，但他們最終的結(jié)果和UTC都相差不大黍瞧，我們只要知道世界時主要是和地球自轉(zhuǎn)相關(guān)的時間標準就可以了诸尽；而原子時（TAI）就是原子鐘定義的時間，實際上印颤，出于某些原因您机，原子時當前和UTC時間相差30多秒，所以我們?nèi)粘Ｉ钪懈惶赡苁褂玫剿?/p>

另外，不得不提的兩個時間是GMT（Greenwich Mean Time）和DST（daylight saving time）往产。

GMT時間和UTC時間很容易混淆被碗，二者從時間表示的結(jié)果上來看是一樣的，所以也經(jīng)撤麓澹看到UTC/GMT時間這樣的說法锐朴，但是二者其實是不一樣的概念。從歷史上來說蔼囊，UTC出現(xiàn)之前焚志，GMT時間就是世界標準時間，后來這個地位被UTC取代了畏鼓，GMT和UTC的差別主要在于酱酬，GMT實際上是指的一個時區(qū)，而UTC是一套世界標準云矫，不指代任何時區(qū)膳沽，因此，我們可以討論英國當前是處在GMT時區(qū)還是BST時區(qū)让禀，卻不會說是處在UTC時區(qū)（參考：https://www.timeanddate.com/time/gmt-utc-time.html）挑社。但是在一般的理解上，把GMT和UTC時間看作相同的時間巡揍，也是沒什么問題的痛阻。

DST即夏令時，是一套相對比較復雜的時間標準腮敌，大體上是在夏季時撥快1小時的時鐘阱当，通過影響人的作息安排，以達到節(jié)省照明用電的目的糜工。我們之所以對夏令時比較陌生喻犁，是因為中國1992年之后就沒有再使用過夏令時了敌蜂，但是世界上仍然還有70多個國家在使用夏令時江滨，以歐洲和北美國家為主厦章。

另外我們經(jīng)常見到的一個時間是CST時間，比如我們在命令行中執(zhí)行date命令钮莲，可以看到

~ date
Mon Dec 28 23:21:19 CST 2020

CST一般表示的是中國標準時間（China Standard Time）免钻，是一個時區(qū)的縮寫，和GMT時區(qū)崔拥、BST時區(qū)等屬于同一類极舔，但是CST作為時區(qū)是存在歧義的，可以指代多個時區(qū)链瓦，美國中部時間拆魏、澳大利亞中部時間盯桦、古巴標準時間、中國的標準時間的縮寫都是CST渤刃。編寫代碼時用CST表示時區(qū)可能會引發(fā)錯誤拥峦，不建議使用。

上述歸納有作者個人理解卖子，如有問題歡迎指正略号。