1.更改時間代碼

在國際化應(yīng)用中，對日期/時間的處理遠(yuǎn)比你想象中的更難，特別是當(dāng)涉及到時區(qū)的時候?yàn)槭裁磿@么難？我們該如何解決它？請聽我為你一一解析幾乎所有的系統(tǒng)都離不開“時間”的概念，以至于大多數(shù)語言（及其默認(rèn)庫）都定義了日期/時間等類型。

2.代碼時間格式

但是，我們?nèi)粘Ｋf的“時間”這個詞實(shí)際上包含了多個相似卻有微妙差異的概念如果不能分清它們，會給你的開發(fā)工作帶來很多煩惱基本概念時區(qū)（Timezone）在應(yīng)用濃綠的拼音怎么寫系統(tǒng)中，對時間的混淆往往和時區(qū)有關(guān)這是很多系統(tǒng)從本地化應(yīng)用發(fā)展成全球化應(yīng)用時的一大障礙。

3.一鍵更改修改時間和日期代碼

由于各地日出日落的時刻不同，所以全球一共分為 24 個時區(qū)，每個時區(qū)橫跨 360/24=15 個經(jīng)度比如倫敦位于北京的西面，那么當(dāng)北京的太陽已經(jīng)升起的時候，倫敦還要再過 8 小時才能迎來黎明也就是說，倫敦比北京晚 8 小時。

4.代碼時間超限怎么辦

而東京位于北京的東面，所以東京的日出比北京早 1 小時如果我們想知道當(dāng)北京是中午 12:00 的時候，東京是什么時間，可以先用 12:00 減去當(dāng)前時區(qū) +08:00，換算成倫敦時間 04:00，再加上目標(biāo)時區(qū) +09:00，就得到了東濃綠的拼音怎么寫京時間 13:00。

5.顯示時間代碼

零時區(qū)地球是圓的，北京比倫敦早8小時其實(shí)就等于比倫敦晚16小時，到底誰比誰早呢？我們既可以把這個時差表示為+8，也可以表示為-16，到底該怎么寫呢？我們要先確定一個標(biāo)準(zhǔn)首先，要確定一個零時區(qū)雖然任何一個地方都可以作為零時區(qū)，但擁有世界上第一座航海鐘的英國格林威治天文臺奪得了這項(xiàng)殊榮，而經(jīng)過那里的子午線（經(jīng)線），被稱為本初子午線。

6.代碼時間轉(zhuǎn)換

它左右各7.5度的范圍叫做零時區(qū)，再往西一個時區(qū)就叫做西一區(qū)當(dāng)我們自東往西旅行的時候，是在追著太陽走，因此每過一個時區(qū)，就要把表撥慢一個小時才能跟當(dāng)?shù)貢r間保持一致，我們把這個“撥慢”的動作，記作 -01:00，反之則是濃綠的拼音怎么寫 +01:00。

7.更改時間指令

如果從倫敦往北京走，需要從西往東走八個時區(qū)，因此北京的時區(qū)就記作 +08:00日界線（國際日期變更線）在球面上，與它相對的那條子午線，正好是 +12:00 區(qū)和 -12:00 區(qū)的分界線這條線很特殊，因?yàn)楫?dāng)你自西向東越過它的時候，既是比倫敦早了13小時，從另一個方向來看，也是比倫敦晚了11小時。

8.代碼時間怎么設(shè)置

就像數(shù)學(xué)中的進(jìn)位一樣，它們的日期應(yīng)該是不同的當(dāng)自西向東越過日界線的時候（迎著朝陽），日期應(yīng)該減一，反之（追趕夕陽），則應(yīng)該加一假設(shè)有一個人于中午 12:00 坐飛機(jī)從倫敦出發(fā)，自東向西（追著太陽）做環(huán)球旅行。

9.日期時間代碼

以這架飛機(jī)的速度，恰好每小時濃綠的拼音怎么寫飛過一個時區(qū)，于是，每過一個小時，他都要把表撥慢一個小時（-01:00）換句話說，我們的主人公一直生活在中午 12:00，而太陽也確實(shí)一直在他的頭頂，他的感知時間和表上的時間是一致的，這樣就避免了他頂著大太陽說“現(xiàn)在是午夜”的荒謬感。

10.調(diào)整代碼

但是，當(dāng)他到達(dá)日界線的時候，還要做另一件事由于他是在自東向西穿越日界線，所以他還要把日期加一他繼續(xù)向前，等回到倫敦走下飛機(jī)的時候，他表上的時間是第二天中午 12:00，而當(dāng)?shù)貢r間也恰好是第二天的 12:00，他自己恰好在天上飛了一整天。

這樣，所有的時間就都對上了但是如果我們仔細(xì)看時區(qū)表，就會發(fā)現(xiàn)有些時區(qū)被標(biāo)記為+13:00、+14:00，這是怎么回事濃綠的拼音怎么寫呢？還是因?yàn)槿战缇€因?yàn)殡m然日界線大部分位于海上，但還是會穿過有人生活的陸地如果把同一個地方的人劃分到不同的日期，會帶來很多不便，于是日界線在中間拐了幾個彎，而這些拐彎的地方，自然就出現(xiàn)了像 +13:00、+14:00 這樣的怪異時區(qū)。

夏時制一到夏天，白天就變得很長，特別是高緯度地區(qū)會更明顯，到了北極或南極，太陽整天都不會落下去，這就是極晝?yōu)榱顺浞掷么笞匀坏酿佡?，有些地方會?shí)行夏時制，也就是說到了夏天，就人為把表撥快一個小時，讓人們早點(diǎn)起床、早點(diǎn)睡覺，這樣可以節(jié)省一些照明的電費(fèi)。

中國曾經(jīng)短暫實(shí)行過幾年夏時制，不過后來認(rèn)為它帶來的負(fù)面影響超過收益，就取消了但是世界上仍然有很多地方實(shí)施夏時制，當(dāng)設(shè)濃綠的拼音怎么寫計全球化應(yīng)用的時候，必須得考慮它時刻（Instant）也許你意識到了，當(dāng)倫敦是中午十二點(diǎn)時（太陽正當(dāng)空），位于倫敦西面的巴黎應(yīng)該是下午一點(diǎn)（太陽略偏西）。

但實(shí)際上它們指的是一定是同一個時間想象一下，如果我中午十二點(diǎn)從倫敦給巴黎的朋友打一個電話，他接電話時手機(jī)上顯示的應(yīng)該是下午一點(diǎn)但無論是倫敦的中午十二點(diǎn)，還是巴黎的下午一點(diǎn)，都只是同一個客觀時間的兩種不同表示而已。

這個與時區(qū)無關(guān)的客觀時間，我們稱之為“時刻”事實(shí)上，在大部分場景下，我們應(yīng)該關(guān)注的都是這個時刻，而其它的時間，全都作為它的衍生物或等價物用這種客觀時刻作為記錄時唯一的一種時間，可以避免很多的概念混淆GMT —— 格林威治標(biāo)準(zhǔn)時間

自從確濃綠的拼音怎么寫定了時區(qū)之后，國際上就把格林威治時間記作 GMT+0對于同一個時刻，可以有 12:00 GMT+00:00、13:00 GMT+01:00 等多種等價的表示形式UTC —— 協(xié)調(diào)世界時現(xiàn)代科技對時間精度的要求越來越高，GMT 依靠天文觀測（地球自轉(zhuǎn)）得來的時間已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)代科技的精度要求。

于是人們改用原子鐘來實(shí)現(xiàn)高精度計時，但是 GMT 已經(jīng)有了很多歷史應(yīng)用，直接把它替換成原子鐘計時會帶來一些不兼容問題所以，人們創(chuàng)建了 UTC 時間，以便在新應(yīng)用中代替 GMT由于 UTC 不再依靠天文觀測來獲取，所以地球自轉(zhuǎn)一天的時間也不再一定等于 86400 秒。

如果地球自轉(zhuǎn)稍微慢了一丟丟呢？那一天的濃綠的拼音怎么寫最后一分鐘可能就有 61 秒，這叫做閏秒事實(shí)上，由于潮汐作用，地球的自轉(zhuǎn)確實(shí)一直在微不可查地減速所以，如果在某些系統(tǒng)中看到 23:59:60 這樣的表示法，請不要急著喊 BUG，先看看當(dāng)時的新聞上有沒有發(fā)過閏秒公告。

當(dāng)然，為了減少不必要的換算，UTC 在設(shè)計的時候刻意向 GMT 看齊，在絕大部分場景下，兩者沒有值得注意的差別日歷我們時常提到日期，但實(shí)際上并沒有一個叫做日期的獨(dú)立概念所有的日期，其實(shí)都是在某個日歷系統(tǒng)中的日期。

比如說我們既可以用“1911 年 10 月 10 日”表示發(fā)生辛亥革命的日期，也可以用“宣統(tǒng)三年八月十九”表示這兩個都對所以，當(dāng)我們要把一個時間顯示給用戶的時候，其日期部分濃綠的拼音怎么寫必須指定一個日歷才能正確地格式化。

我們?nèi)粘Ｊ褂玫哪J(rèn)日歷系統(tǒng)，都是指格里高利日歷系統(tǒng)，由于采納它的國家最多，因此也被稱為公歷而中國的傳統(tǒng)歷法叫做農(nóng)歷或陰歷類似的，還有伊斯蘭歷和佛教歷等日歷系統(tǒng)而年、月、日、星期等，也都是與特定日歷系統(tǒng)緊密相關(guān)的概念。

所以，一旦遇到“下個月”、“第 2 周”這樣的概念，先要明白它是指公歷系統(tǒng)中的一些語言或其默認(rèn)庫中把日期的概念綁死在了公歷系統(tǒng)上，比如 Java 的 Date 類，這會導(dǎo)致它在國際化時難以適應(yīng)不同的日歷系統(tǒng)，容易引起混淆。

所以 Date 類的一些方法和屬性被棄用，并在 Java 8 中引入了一些新的時間/日期類時間的表示格式無論使用哪種時間/日期系濃綠的拼音怎么寫統(tǒng)，也無論它們寫成什么格式，背后所代表的都是時刻這點(diǎn)差異非常重要，如果混淆了它們，在設(shè)計國際化應(yīng)用時，就會陷入歧義。

Unix 時間戳（Time stamp）當(dāng) Unix 系統(tǒng)誕生的時候，需要一種數(shù)據(jù)結(jié)構(gòu)來表示時間，在計算機(jī)系統(tǒng)資源非常有限的條件下，系統(tǒng)的設(shè)計師選擇使用 32 位整數(shù)來表示時間，并以 UTC 時間的 1970年1月1日0時0分0秒 作為起點(diǎn)。

隨著 Unix 和 Linux 系統(tǒng)的廣泛流行，這種表示法的使用范圍也越來越廣然而，由于它是 32 位整數(shù)，因此它最多只能表示到 2038 年初不過，在新系統(tǒng)中，已經(jīng)改用 64 位整數(shù)表示時間戳，它可以表示到2900億年之后，相當(dāng)于不存在最大濃綠的拼音怎么寫時間限制了。

但考慮到存在很多遺留系統(tǒng)，這種遷移將是一個巨大的工程除了兼容性問題之外，Unix 時間戳在調(diào)試、追蹤方面也很不友好，你很難一眼看出它是什么時間，所以，在 API 和日志中盡量不要再用這種格式傳輸或存儲時間數(shù)據(jù)。

RFC2822在互聯(lián)網(wǎng)協(xié)議中傳輸?shù)淖址?，通常?RFC2822 格式的比如 Thu, 10 Dec 2020 13:49:45 GMT這種形式雖然冗長，但不存在精度限制，所以在一些對存儲空間不很敏感、但注重可讀性的場合卻很合適。

不過，這種格式涉及一點(diǎn)英語，這對非英語國家的人不太友好因此雖然對開發(fā)和調(diào)試的影響不大，但在國際化應(yīng)用中最好不要把它直接顯示給最終用戶ISO8601 濃綠的拼音怎么寫/ RFC3339另一種常用的字符串表示法是 ISO8601 格式，比如 2020-12-01T00:49:45.001Z。

ISO8601 包含很多種子格式事實(shí)上，中國使用的日期格式標(biāo)準(zhǔn)就是 ISO8601，但我們?nèi)粘Ｖ饕褂闷洹澳?月-日”部分從名字就可以看出，它是一個 ISO 標(biāo)準(zhǔn)，幾乎所有的現(xiàn)代語言和庫都能很好地支持它，不會造成歧義。

而且，它只會使用阿拉伯?dāng)?shù)字和兩個字母，以及幾個可選的分隔符，對于非英語用戶比較友好在互聯(lián)網(wǎng)領(lǐng)域，定義了另一個與 ISO8601 基本兼容的標(biāo)準(zhǔn) RFC3339，也就是“{年}-{月}-{日}T{時}:{分}:{秒}.{毫秒}{時區(qū)}”格式，其中的年要用零補(bǔ)齊濃綠的拼音怎么寫為4位，月日時分秒則補(bǔ)齊為2位。

毫秒部分是可選的最后一部分是時區(qū)，前面例子中的 Z 其實(shí)是零時區(qū) Zulu 的縮寫，它也可能是 +08:00 或 -08:00 等這兩個標(biāo)準(zhǔn)非常相似，但又不完全兼容，在編程語境下常用的 ISO8601，指的是一個像 RFC3339 一樣五臟俱全的子版本。

也就是前面舉例過的 2020-12-01T00:49:45.001Z 這種形式人類可讀格式（Human-readable）雖然我們已經(jīng)有了很多種存儲格式，但人類用戶的需求是多樣的，比如有時候用戶只希望看到“月-日”或時間中的其它部分，甚至還有“剛剛、五分鐘前、上月”等“人類友好格式”，這些信息顯然是不全的，而且很濃綠的拼音怎么寫不規(guī)范，無法作為存儲格式使用。

他們存在的意義，就在于供人類閱讀還有另一種容易混淆的人類可讀格式，比如 2020-12-01 00:49:45.001，為什么說它是人類可讀格式而不是 ISO8601 呢？問題的關(guān)鍵不在于它少一個 T，而在于它丟了時區(qū)信息！這樣一來，當(dāng)我把這個時間給一位倫敦同學(xué)看的時候，我們默認(rèn)都會把它當(dāng)做本地時間，看似一樣，但實(shí)際的時刻差了足足八小時，什么事都耽誤了！

與時間有關(guān)的編程要點(diǎn)只存儲時刻Unix 時間戳、RFC2822 和 ISO8601 存儲的都是時刻，而人類可讀格式卻非如此，因?yàn)樗ǔ鄙僦陵P(guān)重要的時區(qū)信息所以，不要在數(shù)據(jù)庫中存儲人類可讀格式，而應(yīng)該存儲時刻，否濃綠的拼音怎么寫則會丟失信息。

只有在把時間顯示給人類的時候，才應(yīng)該臨時轉(zhuǎn)換成人類可讀格式只傳輸時刻在 API 中，我們只應(yīng)該傳輸時刻因?yàn)?API 的提供者和消費(fèi)者很可能不在同一個時區(qū)，如果傳輸缺少時區(qū)的人類可讀格式，就會被解釋為各自時區(qū)的時間，從而帶來歧義。

正確設(shè)置服務(wù)器時刻在服務(wù)器的內(nèi)部，存儲時刻通常使用 Unix 時間戳，這意味著它是 UTC 時刻當(dāng)你要在服務(wù)器上設(shè)置時間的時候，通常會輸入本地時間，并且由服務(wù)器內(nèi)部換算為時刻后生效這就要求服務(wù)器上必須正確設(shè)置了你輸入的本地時間所對應(yīng)的時區(qū)，否則換算時就會出錯，讓服務(wù)器所理解的時刻不同于你期望的時刻，從而導(dǎo)致錯誤。

如果你使用遠(yuǎn)程登錄的方式去管理服務(wù)器，可以把濃綠的拼音怎么寫當(dāng)前會話的時區(qū)臨時設(shè)置為你所在的時區(qū)，這樣你就可以自由輸入本地時間了，服務(wù)器會自動幫你換算當(dāng)然，如果你要以另一個時區(qū)的用戶身份在服務(wù)器上查詢，也可以把當(dāng)前會話的時區(qū)設(shè)置為該用戶的時區(qū)，這樣你就可以自由使用該用戶期望的時間了。

也可以采用另一種方案：把服務(wù)器設(shè)置為零時區(qū)，并且每次會話時不再設(shè)置時區(qū)這樣可以防止遺忘，但你就要自己把本地時間換算到零時區(qū)時間才能在服務(wù)器上輸入了比如你要查詢北京時間今天 00:0012:00 的日志，當(dāng)在服務(wù)器上做維護(hù)的時候就要換算成服務(wù)器上（零時區(qū)）的時間也就是昨天16:00今天4:00。

這兩種方案各有利弊，但無論采用哪種方案，都要記住時區(qū)只是表象，真實(shí)時刻才是根本必須濃綠的拼音怎么寫確保所有服務(wù)器上的真實(shí)時刻保持一致，這樣才會記錄一個唯一的“真相”，以保持?jǐn)?shù)據(jù)的一致性比如，如果服務(wù)器設(shè)置為零時區(qū)，輸入的時間時卻是你的本地時間，顯然會導(dǎo)致錯誤。

讓各個節(jié)點(diǎn)的真實(shí)時刻保持一致并不容易不過好在互聯(lián)網(wǎng)建立之初就設(shè)計了一個協(xié)議：網(wǎng)絡(luò)時間協(xié)議 NTP它可以幫助各個網(wǎng)絡(luò)節(jié)點(diǎn)自動同步其真實(shí)時刻，在互聯(lián)網(wǎng)上大部分區(qū)域，其同步精度可以達(dá)到 1~50 毫秒最好讓上下游服務(wù)器的時區(qū)保持一致

無論采用哪種方案，都最好確保上下游服務(wù)器之間的時區(qū)保持一致，特別是應(yīng)用服務(wù)器與相應(yīng)的數(shù)據(jù)庫服務(wù)器比如應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器如果分別設(shè)置成了本地時區(qū)和零時區(qū)，并且在應(yīng)用服務(wù)器上發(fā)送一條 SQL，以查詢 2020-濃綠的拼音怎么寫01-01 和 2020-01-02 之間的數(shù)據(jù)，那么這個時刻到底指的是什么呢？應(yīng)用服務(wù)器以為它在查本地時區(qū)的，而數(shù)據(jù)庫服務(wù)器以為它要查零時區(qū)的，這顯然是錯誤的。

在保存數(shù)據(jù)的時候，這種問題更嚴(yán)重如果一個表中某些時間字段是由應(yīng)用服務(wù)器填寫的，而另一些字段是由數(shù)據(jù)庫服務(wù)器填寫的，那么這種時區(qū)設(shè)置方面的差異就可能帶來災(zāi)難性的錯誤為了防范這種問題，最簡單的辦法是讓這些服務(wù)器的時區(qū)保持一致。

如果無法保持一致該怎么辦呢？這就要涉及接下來的幾個要點(diǎn)了不要使用“日期”剛才提到的問題，其表面問題在時區(qū)，本質(zhì)問題卻在于“日期”這兩個日期有什么問題呢？問題就在于它沒有自帶時區(qū)信息！所以，應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器之間濃綠的拼音怎么寫，將無法就時區(qū)達(dá)成一致！各類信息丟失問題是很多 BUG 的根源，這里同樣如此。

更嚴(yán)重的是，它還丟失了時間信息既然我要傳的是“日期”，為什么還需要帶時間信息呢？很簡單，因?yàn)闆]有所謂“日期”！我們?nèi)粘Ｋf的今天，其實(shí)是個時間段，指的是本時區(qū)今天 00:00:00 到明天 00:00:00 之間。

如果換個時區(qū)，今天可能就不是今天了，而是從昨天 16:00:00 到 今天 16:00:00當(dāng)你說的今天指的到底是哪一天呢？所以，雖然和用戶交互時，我們會使用日期的概念，但是在真正的程序中，我們應(yīng)該始終使用時刻，這樣才能保持概念一致性。

保存時使用來自應(yīng)用服務(wù)器的時刻雖然可以讓數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器保持一致濃綠的拼音怎么寫，但為了簡化邏輯，保存數(shù)據(jù)時，盡量由應(yīng)用服務(wù)器來提供時刻，而不要由數(shù)據(jù)庫服務(wù)器提供，這樣可以簡化時刻的來源，更容易保持一致性而對于客戶端提供的時間，我們無法信任，因?yàn)榭蛻舳斯?jié)點(diǎn)通常不在我們的控制范圍內(nèi)，使用客戶端數(shù)據(jù)會帶來數(shù)據(jù)錯誤，甚至帶來安全漏洞。

所以，對于需要保存的數(shù)據(jù)，把應(yīng)用服務(wù)器上的時刻作為真相之源通常是最佳選擇查詢時使用來自用戶的時刻查詢通常是來自用戶視角的，比如當(dāng)用戶在北京查詢今天的數(shù)據(jù)時，他一般是希望查詢北京時間今天 00:00:00 到明天 00:00:00 之間的數(shù)據(jù)，而不會關(guān)心服務(wù)器在哪里。

所以，如果我們要設(shè)計一個查詢今天數(shù)據(jù)的 API，那么就不能把一個日期傳給應(yīng)用服務(wù)器，濃綠的拼音怎么寫因?yàn)榭蛻舳撕头?wù)端的時區(qū)可能不同，服務(wù)端就無法準(zhǔn)確理解客戶端的意圖我們應(yīng)該傳給它兩個參數(shù)：本時區(qū)今天的起始時刻和結(jié)束時刻。

使用“閉-開”區(qū)間表示時間段當(dāng)我們用時間段來表示日期的時候，需要注意區(qū)間的右側(cè)應(yīng)該是開區(qū)間，也就是說，查詢要今天的數(shù)據(jù)就要查詢今天午夜零點(diǎn)到明天午夜零點(diǎn)之間的數(shù)據(jù)，但不包含明天午夜的零點(diǎn)否則即使我們用 11:59:59.999 來查詢，仍然可能存在一條今天的數(shù)據(jù)出現(xiàn)在這個時間點(diǎn)之后。

用 SQL 在查數(shù)據(jù)庫時有一個坑：BETWEEN 是個閉區(qū)間，也就是說其結(jié)束時間是包含在統(tǒng)計范圍內(nèi)的所以，我們應(yīng)該用 今晚零點(diǎn) >= 時間 AND 時間 < 明晚零點(diǎn) 才能準(zhǔn)確查出今天的數(shù)據(jù)強(qiáng)制濃綠的拼音怎么寫指定時區(qū)。

有時候，用戶期望使用的時區(qū)并不是自己所在的時區(qū)，比如當(dāng)用戶到其它時區(qū)出差時，可能關(guān)心的仍然是自己原來的時區(qū)除了讓用戶強(qiáng)制修改客戶端的時區(qū)之外，還可以允許當(dāng)前用戶指定一個時區(qū)，在應(yīng)用服務(wù)器上用這個時區(qū)進(jìn)行換算。

不過，這種情況下客戶端需要對日期選擇器進(jìn)行特殊處理，以便讓用戶感知的日期與實(shí)際使用的日期保持一致指定數(shù)據(jù)庫會話的時區(qū)我們經(jīng)常需要根據(jù)年月日周等標(biāo)準(zhǔn)進(jìn)行統(tǒng)計這時候只通過指定區(qū)間就不容易統(tǒng)計了我們可以把數(shù)據(jù)庫會話的時區(qū)修改為用戶期望的時區(qū)。

比如 alter session set time_zone = ‘+08:00’;這樣一來，我們在 SQL 中使用的函數(shù)就能得到正確的年月日周等濃綠的拼音怎么寫時區(qū)相關(guān)的結(jié)果了總結(jié)時間包含很多相關(guān)卻又容易混淆的概念特別是我們的日常用語往往不是很精確，這就留下了不少隱患。

仔細(xì)區(qū)分這些概念，并且在思考的時候刻意使用這些精確的概念，可以避免很多與時間有關(guān)的 BUG文/Thoughtworks汪志成原文鏈接：https://insights.thoughtworks.cn/timezone-timestamp-format/

更多精彩洞見，請關(guān)注微信公眾號：Thoughtworks洞見