看完本文，您將瞭解爲什麼會有時區、時區爲什麼這麼設計，以及時間是如何測量、統一的。
MySQL中的時區、日期和時間處理，參見《MySQL日期與時間函數（日期/時間格式化、增減、對比、時區等）》
文章目錄
時區
爲什麼需要時區
世界各地的時間是“不一樣”的
古人的一天，習慣用日升日落來計算，比如太陽最高就是正午（12時）：這就是地方時。
這是千百年來形成的一種習慣和文化。
而地球自轉的原因，不同地區陽光照射的角度不同，因此地方時是不同的。
地球自轉是自西向東的，所以東邊比西邊先看到太陽。因爲上面的地方時特點，同一客觀時刻，東邊使用的時間也比西邊的早。
所以客觀上同一時刻，從不同地區人的意識和表達上，時間是不同的。
全世界需要一個統一的時間標準
隨着地區、國家的形成、全球化的推進，不同地方時的人之間有更多的交流。但不同的時間表達，給記錄、溝通帶來了混亂。
所以世界需要一種統一的時間標準。
最簡單的方式，選一個某一個地區的地方時作爲時間標準。但這樣一來，當這個地區處於正午時、假定是12點，在地球其他經度上，人們可能正處於早晨、深夜、傍晚。人們的表達可能會變成，“12點了，要喫早飯了”、“12點了、要喫晚飯了”，這嚴重違背了人們千百年形成的習慣，完全沒辦法接受。
所以在兼顧人們習慣的同時，還要有一個可以協調一致的方案，讓大家各自表達各自時間的同時，客觀上的時間可以對應上。
時區就是爲了解決了這個問題而出現。
時區的設計
時區的設計，既要統一世界的時間，也要兼顧各地區習慣、不同地區還要容易換算。
時區劃分規則
1884年，在華盛頓的國際經度會議規定：將全球按經線從東到西劃分爲24個時區，其中東、西各12個時區，每個時區跨越經度15°，0區和12區跨越東西各7.5°）。規定相鄰區域的時間相差1小時（這樣24個時區剛好是24小時，地球自轉一週），這代表着在同一區域內的東端和西端的人看到太陽昇起的時間最多相差不過1小時。
當人們跨過一個區域，就將自己的時鐘校正1小時（向西減1小時，向東加1小時），跨過幾個區域就加或減幾小時。這樣使用起來就很方便。
但這個方法也有個問題：如果連續跨越24個時區回到原點，那麼時間將會多出或少去一天。
爲了避免這種“日期錯亂”現象,國際上統一規定180°經線爲“國際日期變更線”。當你由西向東跨越國際日期變更線時,必須在你的計時系統中減去一天；反之,由東向西跨越國際日期變更線，就必須加上一天
圖片來自香港天文臺1
百度的時區圖片，更詳細，但有防盜鏈不能引用。
上面的標準是指導意義，而各地實際遵照的時區，並不一定嚴格對照所處經度。因爲有很多國家或地區同時跨越多個時區，爲了照顧到行政上的方便，常將1個國家或1個省份劃在一起時區裏。所以時區並不嚴格按南北直線來劃分，而是按自然條件來劃分。例如，中國幅員寬廣，差不多跨5個時區，但爲了使用方便簡單，實際上在只用東八時區的標準時即北京時間爲準。
第一個世界時：GMT
確定時區規則後，會議還規定英國（格林尼治天文臺舊址）爲零時區。這就誕生了第一個世界時（Universal Time，縮寫爲UT）：格林尼治標準時間（Greenwich Mean Time，縮寫爲GMT，又稱格林尼治平時）。
GMT 12:00就是指格林尼治天文臺當地的中午12:00，而GMT+8 12:00，則是指的東八區的北京當地時間的12:00。
GMT最早只是英國的基準時間。
格林尼治天文臺建於1675年，當時，英國航海事業發展迅速，爲了解決在海上測定經度的需要，英國當局決定在倫敦東南郊距市中心約20多千米，泰晤士河畔的皇家格林尼治花園中建立天文臺。
1835年以後，格林尼治天文臺在傑出的天文學家埃裏的領導下，得到擴充並更新了設備。他首創利用“子午環”測定格林尼治平太陽時。該臺成爲當時世界上測時手段較先進的天文臺。
19實際上半葉，當時很多國家建立了自己的本初子午線，但隨着世界航海事業的發展，各地區同步時間變得很不方便。後來在1884年的的國際精度會議上，決定以通過當時格林尼治天文臺埃裏中星儀所在的經線，GMT也成爲了世界基準時間。
儘管1884年才確立這個時間系統概念，但實際上1924年開始，格林威治天文臺每小時就會向全世界播報時間。此後，GTM由英國倫敦的格林威治皇家天文臺計算並維護，並在往後的幾十年往歐陸其他國家擴散。
時間的“長度”和“座標”
GMT的時間測量
在剛開始的幾十年，GMT 的測量方法非常簡單：觀測者隨時監控太陽在天空的位置，並且把每天太陽爬升到仰角最高的時候記錄下來，這個時間點稱呼爲“過中天”。一般人對於一天 24 小時的理解，大致上就相等於兩次太陽過中天的時間間隔。
但由於地球是以橢圓軌道繞着太陽，在軌道上的行進速率不一，導致一年之中會有“比較長的一天”與“比較短的一天”，所以格林威治的觀測者必須要至少連續觀測一年，然後求取 365 個長度不一的“天”，再把他們全部平均後，得到固定的一天長度，之後再細分成時、分、秒等單位。
因爲這些特性，實際上GMT是有秒級誤差的。
後來科學家發現了由於地軸擺動、不同地點測量的世界時會有差別，爲此制定了新的標準UT1，之前的GMT稱之爲UT0；再後來科學家發現由於地球自轉率的季節性變動，UT1具有周期性變化，修正上述影響後，得到了更均勻的UT2。
國際原子時
在1960年以前，GMT儘管有些許不精確，但仍作爲基本時間計量系統被廣泛應用。
（中間短暫的被曆書時代替）
1967年第十三屆國際計量大會(CGPM)決定，把秒的定義改成原子鐘導出的原子時秒。
銫 -133 原子基態的兩個超精細能級間在零磁場下躍遷輻射9,192,631,770周所持續的時間
自此時間測量就與地球自轉脫節了。這個只利用原子鐘計算時間與日期的系統，稱作國際原子時 （International Atomic Time，簡稱TAI），這是一種只有“天”的系統，時分秒都以“天”的小數點零頭來表示。
國際原子時是一個連續性指標， 由1958年1月1日0時0分0秒起，以日、時、分、秒計算，準確度爲每日數納秒，而UT的準確度爲每日數毫秒。在確定原子時起點之後，由於地球自轉速度不均勻，UT與原子時之間的時差便逐年積累。
TAI的起點是這樣規定的：
取1958年1月1日0時0分0秒世界時(UT)的瞬間作爲同年同月同日0時0分0秒TAI。（事後發現，在該瞬間原子時與世界時的時刻之差爲0.0039秒。這一差值就作爲歷史事實而保留下來。
UTC
儘管獲得了更精確的時間測量，但許多應用部門要求時間系統接近世界時。
既要以國際原子時爲計算基準，但時間又要儘量接近UT、讓一般人都方便使用，UTC就是爲了這個目標而設計。
誕生
1972年誕生了一個折衷方案：協調世界時（Universal Time Coordinated，縮寫爲UTC）1 2。UTC是當前的世界標準時間。
協調世界時，即以我爲基準，向我看齊的意思。（英語：Coordinated Universal Time，法語：Temps Universel Coordonné，簡稱UTC）是最主要的世界時間標準，由於英文（CUT）和法文（TUC）的縮寫不同，作爲妥協，簡稱UTC。
中國大陸採用ISO 8601的《數據元和交換格式信息交換日期和時間表示法》（GB/T 7408-1994）稱之爲國際協調時間，代替原來的GB/T 7408-1994；中國臺灣採用CNS 7648的《資料元及交換格式–資訊交換–日期及時間的表示法》，稱之爲世界統一時間
爲了確保UTC與GMT相差不會超過0.9秒，在有需要的情況下會在UTC內加上正或負閏秒。所以，UTC與GMT基本上等同，誤差不超過0.9秒。所以在實際上，UTC與GMT近乎相同。
- 按國際無線電諮詢委員會（CCIR）通過的關於UTC的修正案，從1972年1月1日起UTC與UT1（在UT中加入極移改正得到）之間的差值最大可以達到±0.9s。位於巴黎的國際地球自轉事務中央局負責決定何時加入閏秒。一般會在每年的6月30日、12月31日的最後一秒進行調整。
- UTC與TAI之間會出現若干整數秒的差別，但兩者頻率保持一致。
這樣UTC按原子時的頻率、保持了時間尺度的均勻性，又能近似地反映地球自轉的變化。
由於 UTC直接與國際度量衡標準相聯繫，所以目前所有的國際通訊系統，像是衛星、航空、GPS 等等，全部都協議採用UTC 時間。
隨着UTC的誕生，之前的各種計時方案使用越來越少。儘管如此，GMT等世界時，在日常生活、天文導航、大地測量和宇宙飛行等方面仍屬必需；同時，世界時反映地球自轉速率的變化，是地球自轉參數之一，仍爲天文學和地球物理學的基本資料。
格式
國際標準化組織規定了日期和時間的表示方法，ISO 8601規定了日期和時間相關的數據交換時的格式。UTC的標準格式爲2019-11-11T00:00:00.000Z，由三個部分組成：
T代表使用UTC時間Z是UTC偏移量，表示UTC時間與本地時的差別、即時差。Z本身表示0時區，讀作Zulu。寫作Z或不寫的時候，表示不偏移、即GTM/0時區的時間。- 需要偏移時，將Z替換爲真實的偏移量。偏移量可用以下形式表示:
±[hh]:[mm]、±[hh][mm]、±[hh] - 目前有39個UTC偏移量（當伊朗試行夏令時時只有38個）
- 偏移量除了數字，也可以寫時區名
- 時間數值。表示在限定UTC格式和偏移量的情況下，偏移時區的本地時間。
看一個例子：
- GMT時間無需偏移，寫作
2019-11-11T00:00:00.000。 - 北京在東8區、比GMT要早8小時，寫作
2019-11-11T08:00:00.000+0800
計算機世界的時間：UNIX TIME
定義
Unix時間(Unix Time)，也叫做POSIX時間或紀元時間(Epoch Time)，是用來記錄時間的流逝，所以也常被叫做時間戳3 4。
定義爲從1970-01-01T00:00:00開始流逝的秒數，不考慮閏秒。之後的時間是正數，之前的是負數。
從定義可以看到，它只代表了從Unix紀元開始流逝的秒數，所以你身處地球上何處，這個時間都是一樣的。
一般Unix時間都是精確到秒，但也有些地方Unix時間是精確到毫秒的（比如MySQL 5.6.4之後開始支持到微秒）。
使用場景
Unix時間主要用於Unix或類Unix系統，但在文件系統、數據庫系統、開發語言等方面也有廣泛應用，如C/C++、Java、MySQL等。也存在一些其他操作系統或者編程語言，使用的就是不一樣的紀元起始日期了，比如MFC使用的是1899-12-30T00:00:00。
Unix系統中計算機內部的時間都是使用Unix時間的。而給用戶看時，就需要轉換成日期和時間的這種對人友好的形式。
在類Unix系統上，可通過命令date +%s查看當前Unix時間：
幾點疑問
爲什麼Unix紀元時間是1970-01-01T00:00:00？
這個問題得去問Unix之父：Ken Thompson 和 Dennis Ritchie了，是他們選擇這個時間作爲Unix系統的紀元時間的4。
第一版的Unix程序員手冊是1971年11月份出版的，上面定義Unix時間是“從1971-01-01T00:00:00開始，單位是一秒的六十分之一”。這意味在Unix時間的最早版本中，時間計數器以60Hz的頻率(芯片的振盪器頻率)遞增，每隔1/60秒，計數器就加一。當時使用的整數計數器是32位的，這樣Unix時間能夠表示的範圍就非常受限了，232/60/3600/24/30/12≈2.3年。所以後來經過多次更改，頻率變成了1Hz，紀元時間改爲了1970-01-01T00:00:00。
有一種說法是Unix操作系統誕生於1970年，但實際上並不是的，在1969年左右，Unix的概念就已經誕生了，Unix的最早版本已經誕生了。Wired網站上的一篇文章寫道
Ritchie說這個時間其實是隨意選擇的，因爲需要一個統一的日期來作爲時間的起點，而1970年的元旦，看起來是最方便的。
時間戳存滿了怎麼辦？
目前已知操作系統、文件系統、數據庫系統、開發語言等，都可能因使用或借鑑了Unix，存在類似問題。
在32位系統中一般時間戳佔用4字節，還有一些系統如MySQL也如此。
32位、去除符號位，剩餘位數最多表示2^31-1=2147483647秒≈24855天≈68年，有人計算過是2038-01-19T03:14:07。到了那個時刻，時間戳字段存滿就會溢出；如果在那個時候，目前大多數系統或語言還沒有修改時間戳的長度，計算機世界的世界末日就來了！5
對於操作系統而言，目前我們大部分的系統都已經升級到64位系統，理論上可以一直表達到15:30:08 UTC on Sun, 4 December 292,277,026,596，也就是幾千億年後。可惜太陽系幾十億年後就要毀滅了，人類不一定能見到那個時刻；要是人類倖存下來了，應該有的是辦法解決這個問題了。
是否會發生2038年問題，並不絕對取決於是32位系統還是64位系統。而是由具體系統中對
time_t類型的實現決定。NetBSD和OpenBSD的早期版本在amd64平臺上仍然使用了32位time_t，因此仍然會發生2038年問題。如今也有一些32位系統開始使用64位的time_t類型。64位Linux上已經在使用64位的time_t了，而32位Linux上則似乎仍然是32位。Mac OS也已經不用擔心2038問題，親測1萬年以上沒問題。
除了操作系統，開發語言或數據庫系統，有些不一定依賴於系統的time_t，是否已解決了2038問題，要看其支持情況。目前Java是沒有該問題的，MySQL 8.0的timstamp還有該問題。
要想知道你的電腦不幸到2038年還沒壞，會不會遇上末日，可以用下面的方法嘗試：
在GNU/Linux上執行
date -ud @2147483648
在BSD上執行date -u -r 2147483648：
如果系統使用了64位時間，結果應該是Tue Jan 19 03:14:08 UTC 2038，即超出32位時間戳最大值1秒。這樣就可以度過末日了。
UNIX這塊，本人對計算機歷史、系統原理了解有限，大量參考了http://ju.outofmemory.cn/entry/95734這篇文章。原文還有很多擴展，感興趣的朋友可以去讀一下。
- MySQL中的時間取值範圍和存儲原理，可參考《MySQL字段長度、取值範圍、存儲開銷（5.6/5.7/8.x的主要類型，區分顯示寬度/有無符號/定點浮點）》
- MySQL中的時區、日期和時間處理，可參考《MySQL日期與時間函數（日期/時間格式化、增減、對比、時區等）》
- 一個看時間的網站：https://time.is/
以上。感謝您的閱讀。
本文未盡事項，後續有機會補充
- 時區名
- ISO8601的詳細解讀
- UNIX時間戳的限制，廣泛存在於多種計算機系統中，具體的區別、改造情況有哪些
香港天文臺 - 世界時區圖：http://gb.weather.gov.hk/gts/time/clock/clockHc.htm# ↩︎ ↩︎
百度 - UTC：https://baike.baidu.com/item/%E5%8D%8F%E8%B0%83%E4%B8%96%E7%95%8C%E6%97%B6/787659?fr=aladdin ↩︎
UNIX時間戳 - 百度百科 ：https://baike.baidu.com/item/unix%E6%97%B6%E9%97%B4%E6%88%B3/2078227?fr=aladdin ↩︎
UNIX時間 - 維基百科：https://en.wikipedia.org/wiki/Unix_time ↩︎ ↩︎
UNIX時間2038問題：https://en.wikipedia.org/wiki/Year_2038_problem ↩︎