"Правильный" формат даты 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

какой из них правильный? Или лучше? Есть ли какие-то стандарты на это?

10 ответов


JSONне укажите, как должны быть представлены даты, но JavaScript делает это.

вы должны используйте формат, испускаемый Date ' s toJSON способ:

2012-04-23T18:25:43.511Z

вот почему:

  1. это читаемый человеком, но и лаконичный

  2. все правильно

  3. Она включает в себя частичный секунды, которые могут помочь восстановить хронологию

  4. что соответствует ISO 8601

  5. ИСО 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 означает либо Internet JSON, либо Interoperable JSON, в зависимости от того, кого вы спрашиваете.

протоколы часто содержат элементы данных, которые должны содержать временные метки или длительность времени. Рекомендуется, чтобы все такие данные элементы должны быть выражены в виде строковых значений в формате ISO 8601, как указано в RFC 3339, С дополнительными ограничениями, которые скорее прописные чем строчные буквы будут использоваться, чтобы часовой пояс не включался defaulted, и что опционные отставая секунды были включены даже когда их значение "00". Также рекомендуется, чтобы все элементы данных содержащ продолжительности времени соответствуют к продукции "продолжительности" внутри Приложение а к RFC 3339 с теми же дополнительными ограничениями.


просто для справки я видел этот формат используется:

Date.UTC(2017,2,22)

Он работает с JSONP что подтверждается


в Sharepoint 2013 получение данных в JSON нет формата для преобразования даты в формат только даты, потому что в этой дате должно быть в формате ISO

yourDate.substring(0,10)

Это может быть полезно для вас


следующий код работал для меня. Этот код будет печатать дату в ДД-ММ-ГГГГ.

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

есть только один правильный ответ на этот и большинство систем ошибаются. Количество миллисекунд с эпохи, он же 64-битное целое число. Часовой пояс является проблемой пользовательского интерфейса и не имеет бизнеса в слое приложения или уровне БД. Почему ваша БД заботится о том, что такое часовой пояс, когда вы знаете, что он будет хранить его как 64-битное целое число, а затем выполнять вычисления преобразования.

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


это работа для меня с 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"
            }
}

Я думаю, что действительно зависит от варианта использования. Во многих случаях было бы более полезно использовать правильную объектную модель (вместо рендеринга даты в строку), например:

{
"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, но:

  • это также читается человеком
  • он реализует правильную объектную модель (как в ООП, насколько это позволяет JSON)
  • он поддерживает часовые пояса (не только смещение UTC на заданную дату и время)
  • он может поддерживать меньшие единицы, такие как миллисекунды, наносекунды, ... или просто доли секунды
  • это не требует отдельного шага разбора (для разбора строки даты и времени), парсер JSON сделает все за вас
  • простое создание с любой структурой даты и времени или реализацией на любом языке
  • можно легко расширить для поддержки других масштабов календаря (иврит, китайский, Исламский ...) и эпохи (AD, BC,...)
  • это год 10000 safe ; -) (RFC 3339 нет)
  • поддерживает даты в течение всего дня и плавающее время (Javascript Date.toJSON() нет)

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