รูปแบบวันที่“ ถูกต้อง” ของ JSON

ฉันเห็นมาตรฐานที่แตกต่างกันมากมายสำหรับรูปแบบวันที่ของ 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

อันไหนที่ถูกต้อง? หรือดีที่สุด มีมาตรฐานประเภทใดบ้างในเรื่องนี้?

JSONเองไม่ได้ระบุวิธีการแสดงวันที่ แต่ JavaScript ทำ

คุณควรจะใช้รูปแบบที่ปล่อยออกมาโดยDate's toJSONวิธีการ:

2012-04-23T18:25:43.511Z

นี่คือเหตุผล:

1. มันเป็นคนอ่านได้ แต่ยังรวบรัด

2. มันจัดเรียงอย่างถูกต้อง

3. มันมีเศษเสี้ยววินาทีซึ่งสามารถช่วยสร้างเหตุการณ์ขึ้นใหม่

4. มันสอดคล้องกับISO 8601

5. ISO 8601 ได้รับการยอมรับอย่างดีในระดับสากลมานานกว่าทศวรรษ

6. ISO 8601 รับรองโดยW3C , RFC3339และXKCD

ที่ถูกกล่าวว่าห้องสมุดทุกวันที่เคยเขียนสามารถเข้าใจ "มิลลิวินาทีตั้งแต่ปี 1970" ดังนั้นเพื่อความสะดวกในการพกพาThiefMasterจึงถูกต้อง

JSON ไม่ทราบอะไรเกี่ยวกับวันที่ สิ่งที่. NET ทำคือแฮ็ค / ส่วนขยายที่ไม่ได้มาตรฐาน

ฉันจะใช้รูปแบบที่สามารถแปลงเป็นDateวัตถุใน JavaScript ได้อย่างง่ายดายเช่นรูปแบบที่สามารถส่งผ่านไปnew Date(...)ได้ รูปแบบที่ง่ายและพกพาได้มากที่สุดคือเวลาประทับที่มีมิลลิวินาทีตั้งแต่ปี 1970

ไม่มีรูปแบบที่เหมาะสมคือ ; ข้อกำหนด JSONไม่ได้ระบุรูปแบบสำหรับการแลกเปลี่ยนวันซึ่งเป็นเหตุผลที่มีวิธีการที่แตกต่างกันมากมายที่จะทำมัน

รูปแบบที่ดีที่สุดคือวันที่ที่แสดงในรูปแบบ ISO 8601 ( ดู Wikipedia ) มันเป็นรูปแบบที่รู้จักกันดีและใช้กันอย่างแพร่หลายและสามารถจัดการได้ในหลายภาษาที่แตกต่างกันทำให้เหมาะมากสำหรับการทำงานร่วมกัน หากคุณมีการควบคุม json ที่สร้างขึ้นคุณให้ข้อมูลกับระบบอื่นในรูปแบบ json โดยเลือก 8601 เนื่องจากรูปแบบการแลกเปลี่ยนวันที่เป็นตัวเลือกที่ดี

หากคุณไม่สามารถควบคุม json ที่สร้างขึ้นได้ตัวอย่างเช่นคุณเป็นผู้บริโภคของ json จากระบบที่มีอยู่หลายระบบวิธีที่ดีที่สุดในการจัดการนี้คือให้มียูทิลิตี้การแยกวิเคราะห์วันที่เพื่อจัดการกับรูปแบบที่แตกต่างกัน

จากRFC 7493 (รูปแบบข้อความ I-JSON) :

I-JSON ย่อมาจาก Internet JSON หรือ Interoperable JSON ขึ้นอยู่กับว่าคุณถามใคร

โปรโตคอลมักจะมีรายการข้อมูลที่ออกแบบมาให้มีการประทับเวลาหรือระยะเวลา ขอแนะนำว่ารายการข้อมูลดังกล่าวทั้งหมดจะแสดงเป็นค่าสตริงในรูปแบบ ISO 8601 ตามที่ระบุในRFC 3339พร้อมกับข้อ จำกัด เพิ่มเติมที่ใช้ตัวพิมพ์ใหญ่แทนตัวอักษรตัวพิมพ์เล็กซึ่งไม่รวมค่าเริ่มต้นและไม่กี่วินาทีในการติดตาม ถูกรวมแม้ว่าค่าของพวกเขาคือ "00" นอกจากนี้ขอแนะนำว่ารายการข้อมูลทั้งหมดที่มีช่วงเวลาเป็นไปตามการผลิต "ระยะเวลา" ในภาคผนวก A ของ RFC 3339 ที่มีข้อ จำกัด เพิ่มเติมเช่นเดียวกัน

เพียงเพื่อการอ้างอิงฉันเคยเห็นรูปแบบนี้ใช้:

Date.UTC(2017,2,22)

มันทำงานร่วมกับJSONPซึ่งได้รับการสนับสนุนจาก$.getJSON()ฟังก์ชั่น ไม่แน่ใจว่าฉันจะไปไกลแค่ไหนเพื่อแนะนำวิธีนี้ ... แค่ทิ้งมันไปเพราะความเป็นไปได้เพราะคนทำแบบนี้

FWIW:ไม่เคยใช้วินาทีเนื่องจากยุคในโปรโตคอลการสื่อสารหรือมิลลิวินาทีนับตั้งแต่ยุคเนื่องจากสิ่งเหล่านี้เต็มไปด้วยอันตรายเนื่องจากการใช้งานแบบสุ่มของวินาทีกระโดดแบบสุ่ม

เป็นสัตว์เลี้ยงที่เกลียดชัง แต่หลายคนเชื่อว่า UTC เป็นเพียงชื่อใหม่สำหรับ GMT - ผิด! หากระบบของคุณไม่ได้ใช้วินาทีกระโดดคุณก็ใช้ GMT (มักเรียกว่า UTC แม้จะไม่ถูกต้อง) หากคุณใช้วินาทีกระโดดอย่างเต็มที่คุณกำลังใช้ UTC จริง ๆ วินาทีกระโดดในอนาคตไม่สามารถรู้ได้ พวกเขาได้รับการเผยแพร่โดย IERS ตามความจำเป็นและต้องการการปรับปรุงอย่างต่อเนื่อง หากคุณกำลังใช้ระบบที่พยายามใช้วินาทีกระโดด แต่มีและตารางอ้างอิงที่ล้าสมัย (มากกว่าที่คุณคิด) จากนั้นคุณไม่มี GMT หรือ UTC คุณมีระบบ wonky ที่อ้างว่าเป็น UTC

ตัวนับวันที่เหล่านี้เข้ากันได้ก็ต่อเมื่อแสดงในรูปแบบที่แยกย่อย (y, m, d, ฯลฯ ) พวกเขาไม่เคยเข้ากันได้ในรูปแบบยุค เก็บไว้ในใจ

หากมีข้อสงสัยให้ไปที่คอนโซลเว็บ javascript ของเบราว์เซอร์สมัยใหม่โดยกด F12 (Ctrl + K ใน Firefox) และเขียนสิ่งต่อไปนี้:

new Date().toISOString()

จะส่งออก:

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

Ta-da !!

ฉันเชื่อว่ารูปแบบที่ดีที่สุดสำหรับการใช้งานร่วมกันสากลไม่ใช่สตริง ISO-8601 แต่เป็นรูปแบบที่ใช้โดย EJSON:

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

ตามที่อธิบายไว้ที่นี่: https://docs.meteor.com/api/ejson.html

ประโยชน์ที่ได้รับ

1. การแยกวิเคราะห์ประสิทธิภาพ:หากคุณเก็บวันที่เป็นสตริง ISO-8601 นี่เป็นสิ่งที่ดีถ้าคุณคาดหวังค่าวันที่ภายใต้ฟิลด์นั้น แต่ถ้าคุณมีระบบที่ต้องกำหนดประเภทค่าโดยไม่มีบริบทคุณจะวิเคราะห์ทุกสตริงสำหรับ รูปแบบวันที่.
2. ไม่ต้องการการตรวจสอบความถูกต้องวันที่:คุณไม่จำเป็นต้องกังวลเกี่ยวกับการตรวจสอบความถูกต้องและการตรวจสอบความถูกต้องของวันที่ แม้ว่าสตริงจะตรงกับรูปแบบ ISO-8601 ก็อาจไม่ใช่วันที่จริง สิ่งนี้ไม่สามารถเกิดขึ้นได้กับวันที่ EJSON
3. การประกาศประเภทที่ไม่คลุมเครือ:ตราบใดที่ระบบข้อมูลทั่วไปดำเนินไปหากคุณต้องการจัดเก็บสตริง ISO เป็นสตริงในกรณีหนึ่งและวันที่ระบบจริงในอีกกรณีหนึ่งระบบทั่วไปที่ใช้รูปแบบสตริง ISO-8601 จะไม่อนุญาตสิ่งนี้ (โดยไม่มีเทคนิคการหลบหนีหรือวิธีแก้ปัญหาที่น่ากลัวที่คล้ายกัน)

ข้อสรุป

ฉันเข้าใจว่ารูปแบบที่มนุษย์อ่านได้ (สตริง ISO-8601) มีประโยชน์และสะดวกมากขึ้นสำหรับกรณีการใช้ 80% และแน่นอนว่าไม่มีใครควรบอกให้ไม่เก็บวันที่ของพวกเขาเป็นสตริง ISO-8601 ถ้านั่นคือสิ่งที่แอปพลิเคชันของพวกเขา เข้าใจแต่สำหรับรูปแบบการขนส่งที่เป็นที่ยอมรับในระดับสากลซึ่งควรรับประกันค่าบางอย่างเพื่อให้แน่นอนว่าเป็นวันที่เราจะอนุญาตให้มีความคลุมเครือและจำเป็นต้องมีการตรวจสอบมาก?

JSON ตัวเองมีรูปแบบวันที่ไม่มีก็ไม่สนใจว่าจะมีใครวันที่ร้านค้า อย่างไรก็ตามเนื่องจากคำถามนี้ถูกติดแท็กด้วย javascript ฉันคิดว่าคุณต้องการทราบวิธีจัดเก็บวันที่ของ javascript ใน JSON คุณสามารถส่งผ่านวันที่ไปยังJSON.stringifyเมธอดและมันจะใช้Date.prototype.toJSONตามค่าเริ่มต้นซึ่งจะใช้ในทางกลับกันDate.prototype.toISOString( MDN ในวันที่ to.JSON ):

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

ฉันยังพบว่ามีประโยชน์ในการใช้reviverพารามิเตอร์ของJSON.parse( MDN บน JSON.parse ) เพื่อแปลงสตริง ISO กลับไปเป็นวันที่จาวาสคริปต์โดยอัตโนมัติเมื่อฉันอ่านสตริง 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...

วิธีที่ต้องการใช้2018-04-23T18:25:43.511Z...

ภาพด้านล่างแสดงสาเหตุที่เป็นวิธีที่ต้องการ:

ดังนั้นตามที่คุณเห็น Date มีวิธีเนทีtoJSONฟซึ่งreturnในรูปแบบนี้และสามารถแปลงเป็นDateอีกครั้งได้อย่างง่ายดาย...

ใน Sharepoint 2013 การรับข้อมูลใน JSON ไม่มีรูปแบบการแปลงวันที่เป็นรูปแบบวันที่เท่านั้นเนื่องจากในวันนั้นควรอยู่ในรูปแบบ ISO

yourDate.substring(0,10)

สิ่งนี้อาจเป็นประโยชน์สำหรับคุณ

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

วันที่จะแสดงในรูปแบบมาตรฐานและเรียงลำดับได้ซึ่งแสดงเวลา UTC (ระบุโดย Z) ISO 8601 ยังสนับสนุนเขตเวลาด้วยการแทนที่ Z ด้วย + หรือ - ค่าสำหรับการชดเชยเขตเวลา:

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

มีการเข้ารหัสเขตเวลาอื่น ๆ ในข้อมูลจำเพาะ ISO 8601 แต่รูปแบบ –10: 00 เป็นรูปแบบ TZ เพียงรูปแบบเดียวที่ตัวแยกวิเคราะห์ JSON ปัจจุบันสนับสนุน โดยทั่วไปควรใช้รูปแบบ UTC (Z) เว้นแต่ว่าคุณมีความต้องการเฉพาะในการหาเขตเวลาที่ผลิตวันที่ (เป็นไปได้เฉพาะในการสร้างฝั่งเซิร์ฟเวอร์)

NB: var date = new Date (); console.log วันที่ (); // พุธ ม.ค. 01 2014 13:28:56 GMT- 1,000 (เวลามาตรฐานฮาวาย)

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

เพื่อบอกคุณว่าเป็นวิธีที่ต้องการแม้ว่า JavaScript จะไม่มีรูปแบบมาตรฐาน

// 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

หากคุณใช้ Kotlin นี่จะช่วยแก้ปัญหาของคุณ (รูปแบบ MS Json)

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

มันใช้งานได้สำหรับฉันกับ 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"
            }
}

มีคำตอบที่ถูกต้องเพียงข้อเดียวเท่านั้นและระบบส่วนใหญ่ผิดพลาด จำนวนมิลลิวินาทีนับตั้งแต่ยุคหรือเลขจำนวนเต็ม 64 บิต เขตเวลาเป็นข้อกังวลใจของ UI และไม่มีธุรกิจในเลเยอร์แอพหรือเลเยอร์ db เหตุใด db ของคุณจึงสนใจเขตเวลาคือเมื่อคุณรู้ว่ามันจะเก็บเป็นจำนวนเต็ม 64 บิตจากนั้นทำการคำนวณการแปลง

ตัดส่วนที่ไม่เกี่ยวข้องออกไปและทำวันที่ให้เป็นตัวเลขจนถึง UI คุณสามารถใช้ตัวดำเนินการทางคณิตศาสตร์อย่างง่ายในการทำแบบสอบถามและตรรกะ

รหัสต่อไปนี้ได้ผลสำหรับฉัน รหัสนี้จะพิมพ์วันที่ในรูปแบบDD-MM-YYYY

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

มิฉะนั้นคุณสามารถใช้:

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

ฉันคิดว่ามันขึ้นอยู่กับกรณีการใช้งาน ในหลายกรณีการใช้โมเดลวัตถุที่เหมาะสมอาจเป็นประโยชน์มากกว่า (แทนที่จะแสดงวันที่เป็นสตริง) เช่น:

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

เป็นที่ยอมรับว่านี่เป็น verbose มากกว่า RFC 3339 แต่:

• มันเป็นมนุษย์อ่านได้เช่นกัน
• มันใช้โมเดลวัตถุที่เหมาะสม (ใน OOP เท่าที่ JSON อนุญาต)
• มันสนับสนุนโซนเวลา (ไม่ใช่แค่ UTC offset ในวันและเวลาที่กำหนด)
• มันสามารถรองรับหน่วยที่เล็กกว่าเช่นมิลลิวินาทีนาโนวินาที ... หรือเพียงเสี้ยววินาที
• ไม่ต้องใช้ขั้นตอนการแยกวิเคราะห์แยกต่างหาก (เพื่อแยกสตริงวันที่และเวลา) ตัวแยกวิเคราะห์ JSON จะทำทุกอย่างให้คุณ
• สร้างง่ายด้วยกรอบเวลาวันที่หรือการใช้งานในภาษาใด ๆ
• สามารถขยายได้อย่างง่ายดายเพื่อรองรับเครื่องชั่งปฏิทินอื่น ๆ (ฮิบรู, จีน, อิสลาม ... ) และยุค (AD, BC, ... )
• ปีนี้ปลอดภัย 10,000 ;-) (ไม่ใช่ RFC 3339)
• รองรับวันที่และเวลาลอยตัวทั้งวัน (Javascript Date.toJSON()ไม่รองรับ)

ฉันไม่คิดว่าการเรียงลำดับที่ถูกต้อง (ตามที่ระบุไว้โดย funroll สำหรับ RFC 3339) เป็นคุณลักษณะที่จำเป็นจริงๆเมื่อทำการเรียงลำดับวันที่เป็น JSON นอกจากนี้ยังเป็นเรื่องจริงสำหรับวันที่ที่มีการชดเชยเวลาในเขตเวลาเดียวกัน