本文翻譯自：The “right” JSON date format
I've seen so many different standards for the JSON date format: 我已經看到JSON日期格式的許多不同標準：
"\"\\/Date(1335205592410)\\/\"" .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\"" .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z" JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00" ISO 8601
Which one is the right one? 哪一個是正確的？ Or best? 還是最好的？ Is there any sort of standard on this? 有什麼標準嗎？
#1樓
參考：https://stackoom.com/question/h9uW/正確的-JSON日期格式
#2樓
JSON does not know anything about dates. JSON對日期一無所知。 What .NET does is a non-standard hack/extension. .NET所做的是非標準的hack /擴展。
I would use a format that can be easily converted to a Date object in JavaScript, ie one that can be passed to new Date(...) . 我將使用一種可以輕鬆轉換爲JavaScript中的Date對象的格式，即可以傳遞給new Date(...)的格式。 The easiest and probably most portable format is the timestamp containing milliseconds since 1970. 最簡單且可能最可移植的格式是自1970年以來包含毫秒的時間戳。
#3樓
There is no right format ; 沒有正確的格式 ; The JSON specification does not specify a format for exchanging dates which is why there are so many different ways to do it. JSON規範沒有指定交換日期的格式，這就是爲什麼有這麼多種不同的方式來實現的原因。
The best format is arguably a date represented in ISO 8601 format ( see Wikipedia ); 最好的格式可以說是以ISO 8601格式表示的日期 （ 請參閱Wikipedia ）。 it is a well known and widely used format and can be handled across many different languages, making it very well suited for interoperability. 它是一種衆所周知的且被廣泛使用的格式，並且可以在許多不同的語言中進行處理，因此非常適合互操作性。 If you have control over the generated json, for example, you provide data to other systems in json format, choosing 8601 as the date interchange format is a good choice. 例如，如果您可以控制生成的json，則可以json格式將數據提供給其他系統，那麼選擇8601作爲日期交換格式是一個不錯的選擇。
If you do not have control over the generated json, for example, you are the consumer of json from several different existing systems, the best way of handling this is to have a date parsing utility function to handle the different formats expected. 例如，如果您無法控制生成的json，則您是幾個現有系統中json的使用者，那麼處理此問題的最佳方法是使用日期解析實用程序功能來處理所需的不同格式。
#4樓
JSON itself does not specify how dates should be represented, but JavaScript does. JSON本身並未指定日期應如何表示，但JavaScript卻指定了。
You should use the format emitted by Date 's toJSON method: 您應該使用Date的toJSON方法發出的格式：
2012-04-23T18:25:43.511Z
Here's why: 原因如下：
It's human readable but also succinct 它是人類可讀的但也很簡潔
It sorts correctly 排序正確
It includes fractional seconds, which can help re-establish chronology 它包括小數秒，可以幫助重新建立時間順序
ISO 8601 has been well-established internationally for more than a decade ISO 8601已經在國際上建立了十多年的歷史
ISO 8601 is endorsed by W3C , RFC3339 , and XKCD W3C ， RFC3339和XKCD認可了ISO 8601
That being said , every date library ever written can understand "milliseconds since 1970". 話雖這麼說 ，每個日期庫都可以理解“自1970年以來的毫秒數”。 So for easy portability, ThiefMaster is right. 因此，爲了方便攜帶， ThiefMaster是正確的。
#5樓
From RFC 7493 (The I-JSON Message Format ) : 從RFC 7493（I-JSON消息格式）開始 ：
I-JSON stands for either Internet JSON or Interoperable JSON, depending on who you ask. I-JSON代表Internet JSON或可互操作JSON，具體取決於您問誰。
Protocols often contain data items that are designed to contain timestamps or time durations. 協議通常包含旨在包含時間戳或持續時間的數據項。 It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format, as specified in RFC 3339 , with the additional restrictions that uppercase rather than lowercase letters be used, that the timezone be included not defaulted, and that optional trailing seconds be included even when their value is "00". 建議所有此類數據項均按照RFC 3339中的規定以ISO 8601格式的字符串值表示，並具有其他限制，即使用大寫而不是小寫字母，時區不默認，並且可選的尾隨秒數即使它們的值爲“ 00”也要包括在內。 It is also RECOMMENDED that all data items containing time durations conform to the "duration" production in Appendix A of RFC 3339, with the same additional restrictions. 還建議所有包含持續時間的數據項均符合RFC 3339附錄A中的“持續時間”，並具有相同的附加限制。
#6樓
There is only one correct answer to this and most systems get it wrong. 只有一個正確的答案，大多數系統都會弄錯。 Number of milliseconds since epoch, aka a 64 bit integer. 自紀元以來的毫秒數，又稱64位整數。 Time Zone is a UI concern and has no business in the app layer or db layer. 時區是與UI有關的問題，在應用程序層或數據庫層中沒有事務。 Why does your db care what time zone something is, when you know it's going to store it as a 64 bit integer then do the transformation calculations. 爲什麼您的數據庫爲什麼要關心什麼時區，當您知道它將以64位整數形式存儲時，然後進行轉換計算。
Strip out the extraneous bits and just treat dates as numbers up to the UI. 去除多餘的位，僅將日期視爲直到UI的數字。 You can use simple arithmetic operators to do queries and logic. 您可以使用簡單的算術運算符進行查詢和邏輯。