Định dạng ngày của JSON bên phải của JSON

Tôi đã thấy rất nhiều tiêu chuẩn khác nhau cho định dạng ngày 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

Cái nào là đúng? Hay nhất? Có bất kỳ loại tiêu chuẩn về điều này?

Bản thân JSON không chỉ định cách biểu diễn ngày, nhưng JavaScript thì có.

Bạn nên sử dụng định dạng phát ra bởi Date's toJSONphương pháp:

2012-04-23T18:25:43.511Z

Đây là lý do tại sao:

1. Đó là con người có thể đọc được nhưng cũng cô đọng

2. Nó sắp xếp chính xác

3. Nó bao gồm các giây phân số, có thể giúp thiết lập lại niên đại

4. Nó phù hợp với ISO 8601

5. ISO 8601 đã được thiết lập tốt trên phạm vi quốc tế trong hơn một thập kỷ

6. ISO 8601 được xác nhận bởi W3C , RFC3339 và XKCD

Điều đó đang được nói , mỗi thư viện ngày từng được viết có thể hiểu "mili giây kể từ năm 1970". Vì vậy, để dễ dàng di chuyển, ThiefMaster là đúng.

JSON không biết gì về ngày tháng. Những gì .NET làm là một hack / phần mở rộng không chuẩn.

Tôi sẽ sử dụng một định dạng có thể dễ dàng chuyển đổi thành một Dateđối tượng trong JavaScript, tức là một định dạng có thể được chuyển qua new Date(...). Định dạng dễ nhất và có thể di động nhất là dấu thời gian chứa mili giây kể từ năm 1970.

Không có định dạng đúng ; Đặc tả JSON không chỉ định định dạng để trao đổi ngày, đó là lý do tại sao có rất nhiều cách khác nhau để thực hiện.

Định dạng tốt nhất được cho là một ngày được thể hiện ở định dạng ISO 8601 ( xem Wikipedia ); nó là một định dạng nổi tiếng và được sử dụng rộng rãi và có thể được xử lý trên nhiều ngôn ngữ khác nhau, làm cho nó rất phù hợp với khả năng tương tác. Ví dụ: nếu bạn có quyền kiểm soát json được tạo, bạn cung cấp dữ liệu cho các hệ thống khác ở định dạng json, chọn 8601 làm định dạng trao đổi ngày là một lựa chọn tốt.

Ví dụ: nếu bạn không có quyền kiểm soát json được tạo, bạn là người tiêu dùng của json từ một số hệ thống hiện có khác nhau, cách tốt nhất để xử lý việc này là có chức năng phân tích cú pháp ngày để xử lý các định dạng khác nhau dự kiến.

Từ RFC 7493 (Định dạng thông báo I-JSON) :

I-JSON là viết tắt của Internet JSON hoặc JSON có thể tương tác, tùy thuộc vào người bạn hỏi.

Các giao thức thường chứa các mục dữ liệu được thiết kế để chứa dấu thời gian hoặc thời lượng. Điều được khuyến nghị là tất cả các mục dữ liệu đó được biểu thị dưới dạng các giá trị chuỗi theo định dạng ISO 8601, như được chỉ định trong RFC 3339 , với các hạn chế bổ sung mà chữ hoa thường được sử dụng, bao gồm múi giờ không được mặc định và các giây theo dõi tùy chọn được bao gồm ngay cả khi giá trị của chúng là "00". Nó cũng được KHUYẾN NGHỊ rằng tất cả các mục dữ liệu có thời lượng phù hợp với sản xuất "thời lượng" trong Phụ lục A của RFC 3339, với cùng các hạn chế bổ sung.

Chỉ để tham khảo Tôi đã thấy định dạng này được sử dụng:

Date.UTC(2017,2,22)

Nó hoạt động với JSONP được hỗ trợ bởi $.getJSON()hàm. Không chắc chắn tôi sẽ đi xa đến mức đề xuất phương pháp này ... chỉ cần ném nó ra ngoài như một khả năng bởi vì mọi người đang làm theo cách này.

FWIW: Không bao giờ sử dụng giây kể từ kỷ nguyên trong một giao thức truyền thông, cũng không mili giây kể từ kỷ nguyên, bởi vì đây là đầy nguy hiểm nhờ vào việc thực hiện ngẫu nhiên của bước nhảy vọt giây (bạn không có ý tưởng cho dù người gửi và người nhận đều thực hiện đúng UTC giây nhuận).

Loại thú cưng ghét, nhưng nhiều người tin rằng UTC chỉ là tên mới của GMT - sai! Nếu hệ thống của bạn không thực hiện bước nhảy vọt thì bạn đang sử dụng GMT (thường được gọi là UTC mặc dù không chính xác). Nếu bạn thực hiện đầy đủ các giây nhuận, bạn thực sự đang sử dụng UTC. Bước nhảy vọt trong tương lai không thể được biết; chúng được IERS xuất bản khi cần thiết và yêu cầu cập nhật liên tục. Nếu bạn đang chạy một hệ thống cố gắng thực hiện các bước nhảy vọt nhưng có chứa và bảng tham chiếu lỗi thời (phổ biến hơn bạn nghĩ) thì bạn không có GMT, cũng không phải UTC, bạn có một hệ thống mạnh mẽ giả vờ là UTC.

Các bộ đếm ngày này chỉ tương thích khi được thể hiện dưới dạng chia nhỏ (y, m, d, v.v.). Chúng KHÔNG BAO GIỜ tương thích trong một định dạng kỷ nguyên. Ghi nhớ nó trong tâm trí.

Khi nghi ngờ, chỉ cần truy cập bảng điều khiển web javascript của trình duyệt hiện đại bằng cách nhấn F12 (Ctrl + K trong Firefox) và viết như sau:

new Date().toISOString()

Sẽ xuất:

"2019-07-04T13: 33: 03.969Z"

Ta-da !!

Tôi tin rằng định dạng tốt nhất cho khả năng tương tác phổ quát không phải là chuỗi ISO-8601, mà là định dạng được sử dụng bởi EJSON:

{ "myDateField": { "$date" : <ms-since-epoch> } }

Như được mô tả ở đây: https://docs.meteor.com/api/ejson.html

Những lợi ích

1. Hiệu suất phân tích cú pháp: Nếu bạn lưu trữ ngày dưới dạng chuỗi ISO-8601, điều này thật tuyệt nếu bạn đang mong đợi một giá trị ngày trong trường cụ thể đó, nhưng nếu bạn có một hệ thống phải xác định các loại giá trị mà không có ngữ cảnh, bạn sẽ phân tích từng chuỗi cho một chuỗi Định dạng ngày tháng.
2. Không cần xác thực ngày: Bạn không cần lo lắng về xác nhận và xác minh ngày. Ngay cả khi một chuỗi khớp với định dạng ISO-8601, nó có thể không phải là một ngày thực sự; điều này không bao giờ có thể xảy ra với một ngày EJSON.
3. Khai báo kiểu không rõ ràng: theo như các hệ thống dữ liệu chung, nếu bạn muốn lưu trữ một chuỗi ISO dưới dạng một chuỗi trong một trường hợp và một ngày hệ thống thực trong một hệ thống khác, các hệ thống chung áp dụng định dạng chuỗi ISO-8601 sẽ không cho phép điều này, về mặt cơ học (không có thủ thuật thoát hoặc giải pháp khủng khiếp tương tự).

Phần kết luận

Tôi hiểu rằng định dạng có thể đọc được của con người (chuỗi ISO-8601) hữu ích và thuận tiện hơn cho 80% trường hợp sử dụng và thực sự không ai được khuyên không nên lưu trữ ngày của họ dưới dạng chuỗi ISO-8601 nếu đó là ứng dụng của họ hiểu, nhưng đối với một định dạng vận chuyển được chấp nhận phổ biến để đảm bảo các giá trị nhất định để chắc chắn là ngày, làm thế nào chúng ta có thể cho phép sự mơ hồ và cần xác thực nhiều như vậy?

Bản thân JSON không có định dạng ngày, nó không quan tâm đến việc bất cứ ai lưu trữ ngày. Tuy nhiên, vì câu hỏi này được gắn thẻ bằng javascript, tôi giả sử bạn muốn biết cách lưu trữ ngày javascript trong JSON. Bạn chỉ có thể truyền một ngày vào JSON.stringifyphương thức và nó sẽ sử dụng Date.prototype.toJSONtheo mặc định, lần lượt sử dụng Date.prototype.toISOString( MDN trên Date.toJSON ):

const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object

Tôi cũng thấy hữu ích khi sử dụng revivertham số của JSON.parse( MDN trên JSON.parse ) để tự động chuyển đổi chuỗi ISO trở lại ngày javascript bất cứ khi nào tôi đọc chuỗi JSON.

const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

Cách ưa thích là sử dụng 2018-04-23T18:25:43.511Z...

Hình dưới đây cho thấy lý do tại sao đây là cách ưa thích:

Vì vậy, như bạn thấy Date có một Phương thức gốc toJSON, returnở định dạng này và có thể dễ dàng chuyển đổi thành Date...

Trong Sharepoint 2013, nhận dữ liệu trong JSON không có định dạng để chuyển đổi ngày thành định dạng chỉ ngày, vì trong ngày đó phải ở định dạng ISO

yourDate.substring(0,10)

Điều này có thể hữu ích cho bạn

"2014-01-01T23: 28: 56.782Z"

Ngày được biểu thị theo định dạng chuẩn và có thể sắp xếp đại diện cho thời gian UTC (được biểu thị bằng Z). ISO 8601 cũng hỗ trợ các múi giờ bằng cách thay thế Z bằng + hoặc - giá trị cho phần bù múi giờ:

"2014 / 02-01T09: 28: 56.321-10: 00"

Có các biến thể khác của mã hóa múi giờ trong thông số ISO 8601, nhưng định dạng mật độ10: 00 là định dạng TZ duy nhất mà trình phân tích cú pháp JSON hiện tại hỗ trợ. Nói chung, tốt nhất là sử dụng định dạng dựa trên UTC (Z) trừ khi bạn có nhu cầu cụ thể để tìm ra múi giờ nơi ngày được tạo ra (chỉ có thể trong thế hệ phía máy chủ).

NB: var ngày = Ngày mới (); console.log (ngày); // Thứ tư ngày 01 tháng 1 năm 2014 13:28:56 GMT- 1000 (Giờ chuẩn Hawaii)

var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

để nói với bạn rằng đó là cách ưa thích mặc dù JavaScript không có định dạng chuẩn cho nó

// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";

var dateStr = JSON.parse(json);  
console.log(dateStr); // 2014-01-01T23:28:56.782Z

Nếu bạn đang sử dụng Kotlin thì điều này sẽ giải quyết vấn đề của bạn. (Định dạng MS Json)

val dataString = "/Date(1586583441106)/"
val date = Date(Long.parseLong(dataString.substring(6, dataString.length - 2)))

nó hoạt động với tôi với parse Server

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

Chỉ có một câu trả lời đúng cho điều này và hầu hết các hệ thống đều hiểu sai. Số mili giây kể từ epoch, còn gọi là số nguyên 64 bit. Múi giờ là mối quan tâm của UI và không có doanh nghiệp trong lớp ứng dụng hoặc lớp db. Tại sao db của bạn quan tâm múi giờ là gì, khi bạn biết nó sẽ lưu trữ dưới dạng số nguyên 64 bit, sau đó thực hiện các phép tính chuyển đổi.

Loại bỏ các bit không liên quan và chỉ coi ngày là số lên đến UI. Bạn có thể sử dụng các toán tử số học đơn giản để thực hiện các truy vấn và logic.

Các mã sau đây đã làm việc cho tôi. Mã này sẽ in ngày ở định dạng DD-MM-YYYY .

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

khác, bạn cũng có thể sử dụng:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

Tôi nghĩ rằng điều đó thực sự phụ thuộc vào trường hợp sử dụng. Trong nhiều trường hợp, có thể có lợi hơn khi sử dụng một mô hình đối tượng phù hợp (thay vì hiển thị ngày thành một chuỗi), như vậy:

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

Phải thừa nhận rằng điều này dài dòng hơn RFC 3339 nhưng:

• nó cũng có thể đọc được
• nó triển khai một mô hình đối tượng phù hợp (như trong OOP, theo như JSON cho phép)
• nó hỗ trợ các múi giờ (không chỉ bù UTC vào ngày và giờ nhất định)
• nó có thể hỗ trợ các đơn vị nhỏ hơn như mili giây, nano giây, ... hoặc đơn giản là giây phân đoạn
• nó không yêu cầu một bước phân tích cú pháp riêng biệt (để phân tích chuỗi thời gian ngày), trình phân tích cú pháp JSON sẽ làm mọi thứ cho bạn
• dễ dàng tạo với bất kỳ khung thời gian ngày hoặc thực hiện bằng bất kỳ ngôn ngữ nào
• có thể dễ dàng được mở rộng để hỗ trợ các thang lịch khác (tiếng Do Thái, tiếng Trung Quốc, Hồi giáo ...) và thời đại (AD, BC, ...)
• đó là năm 10000 an toàn ;-) (RFC 3339 không)
• hỗ trợ ngày và thời gian trôi nổi cả ngày (Javascript Date.toJSON()không)

Tôi không nghĩ rằng việc sắp xếp chính xác (như được lưu ý bởi funroll cho RFC 3339) là một tính năng thực sự cần thiết khi tuần tự hóa một ngày thành JSON. Ngoài ra, điều đó chỉ đúng với thời gian có cùng múi giờ.