在URL

Question

在的OData/REST服務發送日期和時間與時區參數接受的方式我想允許標誌着數據的日期範圍的日期參數startDate和endDate返回。 例子：

GET /events?startDate=XXX&endDate=YYY 

問題：

1. 什麼是標準格式的日期和時間，網址是什麼？
2. 我應該考慮添加時區（或UTC偏移量）嗎？如果未添加時區，會有什麼預期？

Answer 1

見World Wide Web Consortium (W3C)日期格式，您可以在格式YYYY-MM-DDTHH派：MM：ss.sTZD

如1997-07-16T19：20：30.45 + 01：00

沒有秒：

YYYY-MM-DDTHH：mmTZD（例如1997-07-16T19：20 + 01：00）

默認時區是美國東部標準時間：

1994-11-05T08：15：30-05：00對應於1994年11月5日，8 ：美國東部標準時間上午15：30, 。

1994-11-05T13：15：30Z對應於同一時刻。

Answer 2

W3C date format鏈接在@user7294900's answer是一個不錯的選擇。您只需要注意:和+這些字符 - 建議您使用URL-encode這些字符：在這種情況下，像2017-08-07T12:09:23.555+01:00這樣的日期在URL中會變成2017-08-07T12%3A09%3A23.555%2B01%3A00。

您還可以使用ISO 8601 formats，它允許在不-和:分隔的格式，所以像2017-08-07T12:09:23.555+01:00的日期也可以寫爲：20170807T120923.555+0100（您仍然有字符進行URL編碼，但是這可以變得更可讀比第一種辦法：20170807T120923.555%2B0100）

實際上W3C日期格式是配置文件（或ISO 8601的子集），因此兩者都是不錯的選擇，因爲大多數現代語言和系統具有ISO格式的支持。

我該如何/應該考慮添加時區（或UTC偏移量）？

首先，時區和偏移是不一樣的東西（雖然他們彼此相關）。

偏移量與UTC的差值：+02:00表示「比UTC早2小時」，而-02:00表示「UTC後面2小時」。

時區是一個集所有不同的偏移，一個區域有，有其歷史的過程中都會有，包括當發生這些變化的確切日期和時間。

如果我只是有一個像2017-08-07T12:09:23.555+01:00這樣的日期，那麼偏移量+01:00只是表明它比UTC早1小時，但它沒有說明它在哪個時區。它可以是倫敦期間Daylight Saving Time（夏令時或夏令時），也可以是安道爾在冬季或其他許多地方。

Java使用IANA timezones names（總是格式爲Region/City，如America/New_York或Europe/Berlin）。 避免使用三字母縮寫（如EST或），因爲它們ambiguous and not standard。

如果您的應用程序將處理日期和時間，在不同的區域，我建議使用UTC內部工作（所以日期會像2017-08-07T12:09:23.555Z - 在Z意味着「零偏差」，這反過來又is the same as "UTC"）。因此，您的後端代碼始終與UTC協同工作，並在需要時將其更改爲另一個時區（例如向用戶顯示時）。

如果你不需要用不同的時區工作，或者並不需要知道事件的確切時刻，你可以用一個「本地日期」工作（無時區，也沒有偏移）。這取決於你的要求。

如果不添加時區有什麼預期？

如果您使用本地日期/時間（不帶時區/偏移量），則可能會出現「奇怪」或意外的結果，具體取決於代碼處理日期的方式。

假設我有日期/時間2017-08-07T22:00（8月7日^2017年，下午10點）。它不具有任何時區信息，因此你必須假定在世界的哪個區域這個日期是：你可以假設它在你的時區，或在任何時區系統使用，但如果你開始涉及其他這些計算將失敗時區。

例如：如果我認爲這個日期是在倫敦，這將是等同於晚上9點在UTC。但如果當地日期在洛杉磯，則相當於UTC的2017-08-08T05:00（洛杉磯的晚上10點等於UTC的第二天凌晨5點）。此日期/時間將根據所使用的時區表示不同的時間。

所以，如果不使用偏移，你可能有這些結果，當然這取決於你的代碼與日期做。如果你把它當作當地的日期和時間來處理，那應該沒有問題。如果您在考慮UTC和/或不同時區進行計算，可能會出現問題。