Какой "правильный" формат даты в JSON?

Когда возникают сомнения, просто откройте консоль JavaScript в современном браузере, нажав (Ctrl + Shift + K в Firefox), и введите следующее:

new Date().toISOString()

В результате вы получите:

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

Та-дам!

Для справки, я видел, что используется следующий формат:

Date.UTC(2017, 2, 22)

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

Для справки: Никогда не используйте секунды с начала эпохи в протоколах связи, а также миллисекунды с начала эпохи, потому что это чревато проблемами из-за рандомизированной реализации висекунд (вы не можете быть уверены, что и отправитель, и получатель правильно воспринимают висекунды UTC).

Это моя небольшая проблема, но многие люди считают, что UTC — это просто новое название GMT — это неверно! Если ваша система не реализует висекунды, то вы используете GMT (часто его называют UTC, несмотря на то, что это неправильно). Если вы полностью реализуете висекунды, то вы действительно используете UTC. Будущие висекунды заранее неизвестны; они публикуются IERS по мере необходимости и требуют постоянных обновлений. Если вы работаете в системе, которая пытается реализовать висекунды, но содержит устаревшую таблицу справочных данных (это случается чаще, чем вы можете подумать), то у вас нет ни GMT, ни UTC — у вас есть неработающая система, притворяющаяся UTC.

Эти счетчики дат совместимы только в разложенном формате (г, м, д и т.д.). Они НИКОГДА не совместимы в формате эпохи. Держите это в виду.

Дата представлена в стандартном и сортируемом формате, который указывает на время в UTC (обозначается буквой Z). ISO 8601 также поддерживает часовые пояса, заменяя Z на значение смещения часового пояса:

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

Существуют и другие варианты кодирования часового пояса в спецификации ISO 8601, но формат –10:00 является единственным форматом TZ, поддерживаемым текущими парсерами JSON. В общем, лучше использовать формат на основе UTC (Z), если нет конкретной необходимости выяснять часовой пояс, в котором была создана дата (что возможно только при генерации на серверной стороне).

Примечание:

var date = new Date();
console.log(date); // Wed Jan 01 2014 13:28:56 GMT-1000 (Гавайское стандартное время)

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

Это говорит о том, что данный способ является предпочтительным, даже если в JavaScript нет стандартизированного формата для этого.

// Дата в формате JSON
var json = "\"2014-01-01T23:28:56.782Z\"";

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

Я считаю, что лучшим форматом для универсальной совместимости является не строка 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, если именно это понимают их приложения. Но для универсально принятого транспортного формата, который должен гарантировать, что определенные значения определенно являются датами, как мы можем допускать неоднозначность и необходимость такой обширной валидации?

В SharePoint 2013, при получении данных в формате JSON, нет встроенного способа для преобразования даты в формат только с датой, так как дата должна быть в формате ISO. Однако, вы можете использовать следующий код для извлечения только даты из строки:

yourDate.substring(0, 10)

Этот код поможет вам получить первые 10 символов строки даты, что соответствует формату "YYYY-MM-DD". Надеюсь, это будет полезно для вас!