時區

時區是一個遵守法律，商業和社會目的的統一標準時間的區域。時區傾向於遵循國家及其細分之間的界限，而不是嚴格遵循經度，因為它可以方便地進行頻繁溝通以保持同一時間。

時區定義為與協調的通用時間（UTC）的一兩個偏移，並且（如果使用兩個偏移量）在偏移發生變化時。由於日光節省時間（DST），全年的某些時區域會切換在偏移之間。 UTC偏移量的範圍從UTC -12：00到UTC+14：00 ，通常是整個小時數，但是一些區域被額外的30或45分鐘所抵消（例如在印度，南澳大利亞和尼泊爾） 。

極端緯度的區域更有可能使用DST。 DST通常使用大約一半，通常是通過在春季和夏季在當地時間增加一個小時。

UTC偏移列表

在下表中，當DST無效時，使用日光節省時間（DST）的位置在其UTC偏移中列出。當DST生效時，大約在春季和夏季，它們的UTC偏移量增加了一個小時（除了豪島勳爵（Lord Howe Island ），它增加了30分鐘）。例如，在DST期間，加利福尼亞觀察UTC -07：00 ，英國觀察UTC+01：00 。

歷史

由於地球的球形形狀，太陽在天空中的明顯位置，因此太陽時間因位置而異。這種變化對應於每個經度的每個時間的四分鐘時間，因此，例如，當它在倫敦的太陽中午時，它是在布里斯托爾太陽中午的10分鐘前，西方約2.5度。

皇家天文台格林威治（Greenwich）成立於1675年，建立了格林威治的平均時間（GMT），即該位置的平均太陽時間，以幫助水手們確定海上的經度，提供標準的參考時間，而英格蘭的每個位置則保持不同時間。

鐵路時間

在19世紀，隨著運輸和電信的改善，每個位置觀察自己的太陽能時間變得越來越不便。 1840年11月，偉大的西部鐵路開始使用便攜式天文紀錄器保存的GMT。這種做法很快在英國的其他鐵路公司之後，被稱為鐵路時間。

1852年8月23日左右，皇家天文台電報首先傳輸了時間信號。到1855年，英國98％的公眾時鍾正在使用GMT，但直到1880年8月2日才使該島的合法時間成為合法的時間。這一時期的一些英國時鐘有兩分鐘的手，一個是當地時間，一個是GMT。

1868年11月2日，當時的新西蘭英國殖民地正式採用了整個殖民地的標準時間。它基於格林威治以東172°30'的經度，即GMT比11小時30分鐘。該標準被稱為新西蘭平均時間。

19世紀，北美鐵路上的計時很複雜。每條鐵路都使用自己的標準時間，通常是基於總部或最重要的終點站的當地時間，而鐵路的火車時間表則是使用自己的時間出版的。幾條鐵路提供的一些連接處的每條鐵路都有一個時鐘，每個鐵路都顯示了不同的時間。

查爾斯·杜德（Charles F.邊界，第一個以華盛頓特區為中心，但到1872年，第一個以格林威治西部75°以西的子午線為中心，並帶有自然邊界，例如阿巴拉契亞山脈的各個部分。道德的系統從未被北美鐵路所接受。取而代之的是，美國和加拿大鐵路實施了旅行者官方鐵路指南的編輯威廉·艾倫（William F. Allen）提出的版本。其時區的邊界經常在主要城市的火車站橫渡。例如，其東部和中央時區之間的邊界穿過底特律，布法羅，匹茲堡，亞特蘭大和查爾斯頓。它於1883年11月18日星期日開幕式，也稱為“兩個中午的一天”，當時每個火車站時鐘都被重置為標準時間中午在每個時區內。

北美地區被命名為殖民地，東部，中央，山和太平洋。在所有人口超過10,000（約200個城市）的城市中，有85％的人使用標準時間。底特律是一個值得注意的例外（位於東部和中央時間的子午線之間的一半），該時間一直持續到1900年，然後在1915年5月的《 1915年5月的法令》之前嘗試了中央標準時間，當地平均時間和東部標準時間（EST） EST並於1916年8月通過普選投票批准。當美國國會在1918年3月19日的《標準時間法》中正式通過標準時區正式通過了標準時區時，這種混亂就結束了。

全球時區

意大利數學家Quirico Filopanti在他的書Miranda中介紹了全球時區系統的想法！ ，於1858年出版。他提出了24小時的時區，他稱之為“縱向日”，這是第一個以羅馬子午線為中心的。他還提出了一個普遍的時間，用於天文學和電報。但是，他的書直到他去世很久才引起人們的注意。

蘇格蘭- 加拿大出生的加拿大桑福德·弗萊明爵士（Sandford Fleming）於1876年提出了一個全球範圍內的時區系統 - 參見桑德福德·弗萊明（Sandford Fleming）§世界標準時間的發明者。該提案將世界分為二十四個時區，標有AY（跳過J），每個區域都覆蓋了15度的經度。每個區域內的所有時鐘都將與其他區域設置為同一時間，但與相鄰區域中的所有時鐘都不同。他在包括國際子午線會議在內的幾個國際會議上提倡自己的系統，並在那裡得到了一些考慮。該系統尚未直接採用，但是有些地圖將世界分為24個時區，並將信件分配給它們，類似於弗萊明的系統。

到1900年左右，地球上幾乎所有居住的地方都採用了標準時區，但只有一些人使用GMT的小時偏移。許多人在當地的天文天文台上運用了整個國家的時間，而無需提及GMT。花了數十年的時間才基於GMT的一些標準偏移或協調的通用時間（UTC）。到1929年，大多數國家都採用了小時的時區，儘管伊朗，印度，緬甸和澳大利亞部分地區等一些國家的時區有30分鐘的偏移。尼泊爾是最後一個採用標準偏移的國家，在1986年略微轉移到UTC+05：45。

目前，所有國家目前都將標準時區用於世俗目的，但並非所有國家都將該概念應用於最初的構想。幾個國家和分區使用半小時或四分之一小時的偏離標準時間。一些國家（例如中國和印度）使用一個時區，即使其領土的程度遠遠超過了一個小時的理想經度。西班牙和阿根廷等其他國家使用基於標準的偏移，但不一定是由其地理位置決定的偏移。在某些地區，後果會影響當地公民的生活，在極端情況下，造成了更大的政治問題，例如在中國西部範圍內。在有11個時區的俄羅斯，在2010年撤離了兩個時區，並於2014年恢復。

符號

ISO 8601

ISO 8601是國際標準化組織建立的標準，定義了以文本形式表示日期和時間的方法，包括表示時區的規格。

如果時間是在協調的通用時間（UTC），則在沒有分離空間的情況下直接添加“ Z”。 “ Z”是零UTC偏移的區域指定器。因此，“ 09:30 UTC”表示為“ 09：30z”或“ 0930z”。同樣，“ 14:45:15 UTC”也寫為“ 14：45：15z”或“ 144515Z”。 UTC時間也被稱為“ Zulu”時間，因為“ Zulu”是字母“ Z”的語音字母代碼單詞。

UTC的偏移以格式±HH：mm，±hhmm或±HH（提前或後面的UTC後數小時）。例如，如果所描述的時間比UTC提前一小時（例如冬季在德國的時間），則區域指示符將為“ +01：00 ”，“ +0100”或簡單地“ +01”。該時區的數字表示與當地時代相同的方式與字母時區縮寫（或上面的“ Z”）相同。 UTC的偏移隨著日光節省時間的變化，例如在北美中央時區的芝加哥的時間偏移為冬季的“ -06：00 ”（中央標準時間）和“ -05：00 ”。夏天（中央日光時間）。

縮寫

時區通常以字母縮寫為代表，例如“ EST”，“ WST”和“ CST”，但這些不是國際時間和日期標準ISO 8601的一部分。這樣的名稱可能是模棱兩可的。例如，“ CST”可以表示（北美）中央標準時間（UTC -06：00），古巴標準時間（UTC -05：00）和中國標準時間（UTC+08：00），也是一個ACST的廣泛使用變體（澳大利亞中央標準時間，UTC+09：30）。

轉換

時區之間的conversion依遵守關係

“ a” - “ - ” a“ a” =“ b” b'-“ b” - “ utc偏移量的時間”的“時間”偏移，b”，b”，b“

其中等式的每一側等效於UTC。

轉換方程可以重新排列到

“區域B中的時間” =“區域A” - “ UTC偏移a” +“ UTC偏移量為b”的時間。

例如，紐約證券交易所於09:30開放（ EST ，UTC Offset = -05：00）。在加利福尼亞（ PST ，UTC Offset = -08：00）和印度（ IST ，UTC Offset = +05：30），紐約證券交易所開放

加利福尼亞的時間= 09：30-（-05：00） +（-08：00）= 06:30;

印度的時間= 09：30-（-05：00） +（+05：30）= 20:00。

這些計算在到達或從日光節省時間的時間切換中變得更加複雜，因為該區域的UTC偏移成為UTC時間的函數。

時間差異也可能導致不同的日期。例如，當星期一在埃及（UTC+02：00）的22:00時，它是星期二在巴基斯坦的01:00（UTC+05：00）。

表“一天中的時間”表概述了不同區域之間的時間關係。

航海時區

自1920年代以來，海洋上的船隻一直在運營一種航海標準時間系統。作為陸地時區系統的理想形式，航海時區包括GMT 15°偏移的GORS組成的整個小時。航海日期是第180個子午線之後，將一個15°戈爾分成兩個7.5°戈爾斯，與GMT不同，差異為±12小時。

但是，實際上，每艘船可以選擇在每個位置觀察的時間。船隻可能會在方便的時間（通常在晚上，不完全跨越一定的經度時）調整其時鐘。在整個行程中，有些船隻僅留在出發港口的時間。

時區偏斜

理想的時區（例如航海時區）基於該區域中部特定子午線的平均太陽時間，邊界位於子午線東部和西部7.5度。但是，在實踐中，許多時區域邊界在西方的範圍更遠，有些國家完全位於其理想時區。

例如，即使主要子午線（0°）通過西班牙和法國，但它們的平均太陽時間是東部15度（中歐時間）而不是0度（格林威治平均時間）。法國以前曾使用過GMT，但在第二次世界大戰期間德國占領該國期間，在中歐時代（中歐時代）改用，戰後沒有轉移。同樣，在第二次世界大戰之前，荷蘭觀察到了“阿姆斯特丹時代”，這比格林威治的平均時間提前二十分鐘。他們必須在戰爭期間跟隨德國時間，然後將其保留。在1970年代中期，荷蘭與其他歐洲州一樣，開始觀察日光（夏季）時間。

劃定其理想子午線西部時區域邊界的原因之一是允許更有效地利用下午的陽光。這些位置中的一些還使用日光節省時間（DST），進一步增加了與當地太陽能時間的差異。結果，在夏季，西班牙維戈城的太陽能中午發生在14:41時鐘時間。西班牙大陸最西端的地區儘管位於赤道以北42度，但即使在冬天，也從未在18:00時鐘之前經曆日落。在夏至附近，Vigo在22:00之後有日落時間，類似於斯德哥爾摩的日落時間，斯德哥爾摩的時區位於同一時區，北部為17度。不過，斯德哥爾摩的日出要早得多。

一個更極端的例子是阿拉斯加諾米（Nome） ，位於165°24'的經度 - 位於理想化的薩摩亞時區中心（ 165°W ）的中心以西。儘管如此，諾姆（Nome）用DST觀察了阿拉斯加時間（ 135°W ），因此冬天比太陽高兩個多小時，夏季超過三個小時。阿拉斯加的科茲布（Kotzebue）也附近同一個子午線，但在北極圈以北，在八月初的同一天有兩個日落。

中國向西延伸至73°E ，但其中的所有部分都使用UTC+08：00 （ 120°E ），因此在中國西部（如新疆）的西部地區，太陽能“中午”可以在15:00發生。阿富汗 - 中國邊界是地球上最大的地面時區差異，阿富汗的UTC+4：30與中國的UTC+08：00之間的差異為3.5小時。

在不同位置的時鐘時間和太陽時間之間的不匹配的可視化。在藍色區域，時鐘時間落後於太陽能時間；在紅色區域，相反是正確的。兩者在白色區域同步。

夏令時節省時間

許多國家，有時甚至只是國家的某些地區，採用了夏令時（DST）（DST），也稱為夏季時間。這通常涉及在春季開始附近前進一個小時，並在秋季進行調整（ “春季向前”，“倒退”）。現代DST於1907年首次提議，並於1916年廣泛使用，作為旨在保護煤炭的戰時措施。儘管有爭議，但許多國家從那以後就使用了它。細節因位置而異，並偶爾更改。赤道周圍的國家通常不會觀察到夏令時，因為陽光的季節性差異很小。

計算機系統

許多計算機操作系統包括基於各個時區的所有（或幾乎所有）本地時間的必要支持。在內部，操作系統通常將UTC用作其基本時間保存標準，同時提供用於將本地時間轉換為往返UTC的服務，並且能夠在各個時間內自動更改當地時間轉換時自動更改本地時間轉換區域。 （有關此方面的更多詳細信息，請參見有關日光節省時間的文章）。

網絡服務器主要針對單個時區域的受眾或有限的時區域呈現網頁，通常顯示為當地時間，也許在括號中使用UTC時間。更多以國際為導向的網站可以僅在UTC中顯示時間或使用任意時區。例如，國際英語版本的CNN包括GMT和香港時間，而美國版則顯示東部時間。美國東部時間和太平洋時間也很常用於許多具有全球讀者群的美國英語網站。該格式通常基於W3C註釋“ DateTime”。

電子郵件系統和其他消息傳遞系統（ IRC聊天等）使用UTC的時間戳記消息，否則將發件人的時區作為消息的一部分，允許接收程序顯示消息在收件人的本地發送消息的日期和時間時間。

數據庫記錄包括時間戳通常使用UTC，尤其是當數據庫是跨越多個時區的系統的一部分時。不建議將當地時間用於時間stamping記錄，以實現日光節省時間的時區，因為每年有一個小時的當地時間模棱兩可。

如今，日曆系統通常將其時間戳與UTC聯繫在一起，並在不同時區的計算機上以不同的方式顯示它們。在舉行電話或互聯網會議時，這種情況有效。它在旅行時效果不佳，因為假定日曆事件發生在計算機或智能手機創建事件時的時區域。該事件可以在錯誤的時間顯示。例如，如果紐約人計劃在上午9點在洛杉磯與某人見面，並在上午9點（計算機假設是紐約時間）進行日曆條目，則日曆條目將在凌晨6點，如果花了計算機的時間區。在Microsoft Outlook的較新版本中，還有一個選項，可以輸入事件發生的時區，但通常不在其他日曆系統中。日曆軟件還必須處理日光節省時間（DST）。如果出於政治原因，日期節省時間的起點和結束日期發生了變化，即使它們可能會在UTC時間轉移，日曆條目也應在當地時代保持不變。因此，在Microsoft Outlook中，在沒有DST偏移的情況下存儲和通信時間戳記。因此，即使該活動實際上將在13:00 UTC舉行，夏季中午在倫敦的一個約會將被代表為12:00（UTC+00：00）。在Google日曆中，日曆事件存儲在UTC中（儘管在當地時間顯示），並且可能會通過時區更改進行更改，儘管正常的日光節省開始和結束是補償的（類似於其他許多日曆軟件）。

作業系統

Unix

大多數類似Unix的系統，包括Linux和Mac OS X ，都將系統保持時間_t格式，代表自00:00:00自00:00:00自1月1日（星期四）以來經過的秒數（不包括LEAP秒）。 ，1970年。默認情況下，外部表示為UTC（協調的通用時間），儘管單個過程可以使用TZ環境變量指定時區。這允許多個時區的用戶使用同一計算機，並將其各自的本地時間正確顯示給每個用戶。時區信息最常來自IANA時區數據庫。實際上，許多系統，包括使用GNU C庫的任何系統，都可以使用此數據庫。

微軟Windows

Windows 2000之前使用的基於Windows的計算機系統使用了本地時間，但是Windows 2000及以後可以將UTC用作基本系統時間。系統註冊表包含包括UTC偏移量的時區信息以及指示在每個區域節省日光的起點和結束日期的規則。與用戶的互動通常使用本地時間，並且應用程序軟件能夠計算各個區域的時間。終端服務器允許遠程計算機將其時區設置重定向到終端服務器，以便用戶在桌面/應用程序會話中看到其時區的正確時間。終端服務使用終端服務器和客戶端時區信息上的服務器基礎時間來計算會話中的時間。

程式設計語言

爪哇

雖然大多數應用程序軟件將使用基礎操作系統進行時區信息，但版本1.3.1的Java平台已維護了自己的時區數據庫。每當時區規則更改時，都會更新此數據庫。 Oracle為此提供了更新工具。

作為與Java平台捆綁在一起的時區信息的替代方案，程序員可以選擇使用Joda Time庫。該庫包括基於IANA時區數據庫的自己的時區數據。

從Java 8開始，有一個新的日期和時間API可以幫助轉換時區。 Java 8日期時間

JavaScript

傳統上，時區支持JavaScript的方式很少。從本質上講，程序員必須通過實例化時間對象，從中獲得GMT時間並與兩者有所不同來提取UTC偏移。這並不能為更複雜的日光節省變化提供解決方案，例如北半球和南半球之間的DST方向不同。

ECMA-402是JavaScript國際化API標準，提供了格式化時區的方法。但是，由於尺寸約束，某些實現或分佈不包括它。

珀爾

PERL中的DateTime對象支持Olson DB中的所有時區，並包括在時區之間獲得，設置和轉換的能力。

php

自5.2以來，DateTime對象和相關功能已被編譯到PHP核心中。這包括獲取和設置默認腳本時區域的功能，DateTime在內部意識到自己的時區。 PHP.NET提供了有關此的廣泛文​​檔。如前所述，最新的時區數據庫可以通過PECL TimeZonedB實現。

Python

Python商店中包含的標準模塊DateTime，並在時區信息類Tzinfo上運行。第三方PYTZ模塊提供了對完整IANA時區數據庫的訪問權限。否定的時區以秒為單位的偏移是存儲的時間。TimeZone和Time.Altzone屬性。從Python 3.9開始，ZoneInfo模塊無需第三方模塊引入時區管理。

短暫聊天

每個SmallTalk方言都帶有其自己的內置類，用於日期，時間和時間戳，其中只有少數按照ANSI SmallTalk標準指定的DateAndtime和持續時間類。 VisualWorks提供了一個時區類，該類別最多支持兩個每年反復出現的偏移過渡，這些過渡被認為適用於所有年份（與Windows時區相同的行為）。 Squeak提供了不支持任何偏移過渡的時區類。 Dolphin Smalltalk根本不支持時區。

為了在SmallTalk應用程序中全面支持TZ數據庫（ZeareInfo）（包括支持任何數量的每年反復出現的偏移過渡，並支持不同年內不同年內偏移過渡規則）第三方開放式，ANSI ANSI -smalltalk符合計時的日期/時間庫可與以下任何SmallTalk方言一起使用：VisualWorks，吱吱聲，寶石或海豚。

外太空的時間

在24小時內，繞航天器可能會經歷許多日出和日落。因此，不可能校準有關太陽的時間，並且仍然尊重24小時的睡眠/喚醒週期。太空探索的一種常見做法是使用發射場或任務控制的基於地球的時間，同步機組人員和控制器的睡眠週期。國際空間站通常使用格林威治平均時間（GMT）。

火星上的計時可能會更加複雜，因為地球的太陽日約為24小時40分鐘，稱為溶膠。某些火星任務的地球控制器已將其睡眠/喚醒週期與火星日同步，因為地表上的太陽能驅動的漫遊者活動與光和黑暗的時期聯繫在一起。

也可以看看

• 夏令時節省時間
• ISO 8601
• 時差
• 時區列表
• 公制時間
• 沿著國家的時間
• 在歐洲的時間
• 時區廢除
• 世界時鐘
• 國際日期變更線