«Правильный» формат даты JSON

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, с дополнительными ограничениями, чем буквы нижнего регистра, чтобы включить часовой пояс не по умолчанию, и что дополнительные секундные секунды будут включены, даже если их значение равно "00". Также РЕКОМЕНДУЕТ, что все элементы данных содержащие продолжительности времени, соответствуют "длительности" производства в Приложение A RFC 3339 с теми же дополнительными ограничениями.

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

Date.UTC(2017,2,22)

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

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

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

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

Предпочтительным способом является использование 2018-04-23T18:25:43.511Z...

На рисунке ниже показано, почему это предпочтительный способ:

Итак, как вы видите, у Date есть собственный метод toJSON, который return в этом формате и может быть легко преобразован в Date снова...

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

yourDate.substring(0,10)

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

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

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

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

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

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

{
    "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 безопасно ;-) (RFC 3339 не)
• поддерживает даты за весь день и плавающее время (Javascript Date.toJSON() нет)

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