比方說，你要建立你的第一個API，將它變成公共、私人、或一些混合的產品。不要感到驚訝，如果你的第一個缺陷是和日期/時間相關的，那么不要低估你可能當涉及到處理日期和時期的時候所帶來的麻煩。當涉及到處理的日期和時間問題時，你可以進來看看。這里有一些技巧可以讓你擺脫這種潛在的麻煩。

規則 #1 使用ISO-8601格式作為你的日期格式

這是沒有可討論的余地的。從W3C 到 IETF, 還有甚至 XKCD, 互聯網一直使用這個標準。不要自作聰明的使用其他。ISO-8601提供一系列的品種，來顯示日期/時間/時區。

通過*nux控制臺來快速看看ISO-8601格式，輸入如下命令：

ISO 8601 解決了很多問題，包括：

• 自然排序 - 簡單和優雅，免去多余的工作即可實現排序
• 時區偏移 - 代表用戶的地點和時區在日益增長的全球化和移動世界中越來越重要。
• 地區中立性 - 想象一下噩夢一般的日期 2/3/4。這個日期隨著你所處美國，歐洲或者其他地方而有不同的含義...這個日期在美國代表Feb 3, 2004，或者在其他地方代表Mar 2, 2004。在ISO 8601條款中，2004-02-03去掉了這些含糊的可能性。
• 在不同的編程語言中都得到廣泛的支持 - 即使不是所有的語言都使用這個標準作為默認值（例如Java），但是它們基本都有成熟的庫來轉化 ISO 8601格式。不要自作聰明來自己實現哦。

規則#2： 接受任何的時區

現在你有一個ISO-8601的工具了，但憑什么你能夠獲取到有關時區的偏移數據呢，用它吧！我們在一個全球化的時代。尤其是如果你的API是對外開放的，你將無可爭議地要解決全球消費者的問題。不要去假設你的API使用者是用那個時區。

規則#3：用UTC（Coordinated Universal Time 世界同一時間）格式存儲

這是大多數系統實際設計的一般規律。我已經記不清我看過多少次按照原公司總部時區建立的系統。不可避免的，除非你是紀律嚴明，用戶最終不會用你的公司的時區看他們的時間。這很讓人討厭，尤其是當他們處在地球的另一端的時候。

UTC，或者世界標準時間，是最常見最有共性存儲的時間，因為他不表示任何時區偏移量。這讓你可以根據你系統的需要，給出整個系統時區的建議日期，無論是哪個時區都是恰當的。

規則#4 使用UTC格式作為返回值格式

UTC可以允許你的API調用者免去計算偏移到他們所需要的日期的工作。而對于你，更重要的是，你的API組不需要為每一次調用都去煩惱如何計算它的偏移值。在你的API文檔和系統支持中，對于你如何處理日期，只需簡單的說“你獲取的是UTC格式”。

規則#5 如果你不需要時間的話，不要使用它

ISO 8601同樣允許我們靈活的提供一個日期而不帶時間。在時間不重要的場合中，只使用日期（例如“目標完成日期”）：不要保存或者返回時間。雖然對于只保存11:59pm沒什么壞處，或者其他隨機時間，但是，你可能在日期國際化的時候會碰到很大麻煩。

想象一下，你使用UTC格式保存2013-03-01T23:59:59，代表Mar 1，2013?，F在，對于中國標準時間（UTC+0800）作時差計算，你現在是表示Mar 2, 2013 早上8點。這會有麻煩，因為日期被誤讀了。在這個例子中，我們只需要使用2013-03-01，不帶任何時間/時區時差，來免除日期的解析誤讀的可能性?，F在流行的數據庫都支持只包含日期的格式。

總結

當所有這些關于日期的討論可能會讓你有點麻木，不過可以放心，幾乎所有的RESTful平臺都使用這些格式。當你需要擺弄數據序列化庫的時候，需要當心，留意當它離開你的API平臺的時候，它會對你的日期進行什么操作。

我們大部分人都在不同的時區或者國家工作，生活或者交流，我們知道連簡單的安排一個約會都會讓我們感到有多么的疑惑。還有，如果你不希望寫一大堆日期轉換和格式化的東西，你可能會希望有一個標準來代表時間。好好運用這些規則來處理你的日期和時間，你就可以減輕很多煩惱。

英文原文：The 5 laws of API dates and times