Правильний формат дати 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' 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 ( див. Вікіпедія ); це добре відомий і широко використовуваний формат і може працювати з різними мовами, що робить його дуже придатним для взаємодії. Якщо у вас є контроль над згенерованим json, наприклад, ви надаєте дані іншим системам у форматі json, вибравши 8601 як формат обміну датами - хороший вибір.

Якщо у вас немає контролю над згенерованим json, наприклад, ви є споживачем json з декількох різних існуючих систем, найкращим способом керування цим є використання функції утиліти для розбору дат для обробки різних очікуваних форматів.

Від RFC 7493 (Формат повідомлення I-JSON) :

I-JSON означає або Інтернет JSON, або сумісний JSON, залежно від того, кого ви запитуєте.

Протоколи часто містять елементи даних, розроблені таким чином, щоб містити часові позначки або тривалість часу. РЕКОМЕНДУЄТЬСЯ, щоб усі такі елементи даних були виражені у вигляді рядкових значень у форматі ISO 8601, визначеному в RFC 3339 , з додатковими обмеженнями щодо використання великих, а не малих літер, щоб часовий пояс не включався за замовчуванням, а також, що необов'язкові кінцеві секунди включати навіть тоді, коли їх значення "00". Також РЕКОМЕНДУЄТЬСЯ, що всі елементи даних, що містять тривалість часу, відповідають виробництву "тривалості" в Додатку А до RFC 3339, з однаковими додатковими обмеженнями.

Для ознайомлення я бачив цей формат:

Date.UTC(2017,2,22)

Він працює з JSONP, який підтримується $.getJSON()функцією. Не впевнений, що я б пішов так далеко, щоб рекомендувати такий підхід ... просто викинувши його там як можливість, тому що люди роблять це таким чином.

FWIW: Ніколи не використовуйте секунди з епохи в протоколі зв’язку, ні мілісекунди з епохи, тому що це загрожує небезпекою завдяки рандомізованому впровадженню високосних секунд (ви не маєте уявлення, чи правильно, і відправник та отримувач реалізують UTC високосні секунди).

Вид ненависті до домашніх тварин, але багато людей вважають, що UTC - це лише нове ім'я для GMT - неправильно! Якщо ваша система не реалізує високосні секунди, то ви використовуєте GMT ​​(часто його називають UTC, незважаючи на неправильність). Якщо ви повністю реалізуєте високосні секунди, ви дійсно використовуєте UTC. Майбутні високосні секунди не можуть бути відомі; вони публікуються IERS за необхідності та потребують постійного оновлення. Якщо ви працюєте з системою, яка намагається реалізовувати високосні секунди, але містить і застарілу довідкову таблицю (більш поширену, ніж ви могли б подумати), то у вас немає ні GMT, ні UTC, у вас непростима система, яка претендує на UTC.

Ці лічильники дат сумісні лише тоді, коли вони виражені у розбитому форматі (y, m, d тощо). Вони НІКОЛИ не сумісні у форматі епохи. Майте це на увазі.

Якщо ви сумніваєтесь, просто перейдіть до веб-консолі javascript сучасного браузера, натиснувши F12 (Ctrl + K у Firefox) та напишіть наступне:

new Date().toISOString()

Виведе:

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

Та-да !!

Я вважаю, що найкращим форматом для універсальної сумісності є не рядок 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 на 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

Також мені було корисно використовувати reviverпараметр JSON.parse( MDN на JSON.parse ) для автоматичного перетворення рядків ISO назад у дати JavaScript, коли я читав рядки 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...

На малюнку нижче показано, чому це найкращий спосіб:

Отже, як ви бачите, Дата має власний метод 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 = нова дата (); console.log (дата); // Ср 01 січня 2014 13:28:56 GMT- 1000 (Гавайський стандартний час)

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

це робота для мене з сервером розбору

{
    "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-бітове ціле число. "Часова зона" - це проблема інтерфейсу користувача і не має жодної справи на рівні додатків або рівня "db". Чому ваш db небайдужий, що таке часовий пояс, коли ви знаєте, що він буде зберігати його як 64-бітове ціле число, тоді робіть розрахунки перетворення.

Скрепіть сторонні шматочки і просто розглядайте дати як числа до інтерфейсу користувача. Ви можете використовувати прості арифметичні оператори для запитів і логіки.

Наступний код працював для мене. Цей код буде друкувати дату в 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"
    }   
   }
}

Справді, це більш багатослівно, ніж RFC 3339, але:

• це також читається людиною
• вона реалізує належну об'єктну модель (як в OOP, наскільки це дозволяє JSON)
• він підтримує часові пояси (не тільки зміщення UTC за вказаною датою та часом)
• він може підтримувати менші одиниці, такі як мілісекунди, наносекунди, ... або просто дробові секунди
• для нього не потрібен окремий крок розбору (для розбору рядка дата-час), аналізатор JSON зробить усе за вас
• просте створення з будь-якою рамкою дати та часу на будь-якій мові
• може бути легко розширений для підтримки інших календарних масштабів (іврит, китайська, ісламська ...) та епохи (AD, BC, ...)
• це рік 10000 безпечно ;-) (RFC 3339 не)
• підтримує дати на весь день та плаваючий час (JavaScript Date.toJSON()не)

Я не думаю, що правильне сортування (як це зазначалося в лінійці для RFC 3339) - це особливість, яка дійсно необхідна при серіалізації дати в JSON. Також це справедливо лише для дат, які мають однаковий зміщення часового поясу.