Как правильно обрабатывать формат даты "/Date(...-0700)/" из Bing с помощью Moment? - PullRequest
Новая
       23

Как правильно обрабатывать формат даты "/Date(...-0700)/" из Bing с помощью Moment?

0 голосов
/ 13 сентября 2018

Я использую Bing Routes API , и он возвращает даты в таком формате: 

/Date(1538245980000-0700)/

Это выглядит как метка времени Unix в миллисекундах, за которой следует часовой пояс. Документы Moment утверждают, что способны правильно их обрабатывать , но они также говорят, что

Отметки времени Unix и объекты Date ссылаются на определенные моменты времени, поэтому при построении не имеет смысла использовать смещение часового пояса.

Исходя из другого контекста (это время, когда автобус отправляется из Стауэлла, в несколько часов от Мельбурна, в субботу утром), я почти уверен, что вышеуказанное время должно быть 11:33 в Австралии / Мельбурне AEST (+10: 00).

Но с помощью moment.timezone: 

console.log(moment.parseZone('/Date(1538245980000-0700)/').format('h:mma Z'));

"11:33am -07:00"

Это кажется действительно неправильным: это относится к моменту времени, который:

  • 11: 33 по тихоокеанскому времени,
  • 18:33 UTC
  • 4: 33 AM Мельбурнское время

Бинг не так? Почему этот часовой пояс включен?

Или я неправильно использую момент? В каком случае, как правильно преобразовать этот формат в правильное время с моим местным часовым поясом?

1 Ответ

0 голосов
/ 13 сентября 2018

Это устаревший формат ASP.NET JSON , созданный классом JavaScriptSerializer (и другими).Скотт Хансельман сделал пост в блоге в 2012 , как и другие.(Как правило, современные системы должны предпочитать формат ISO 8601 / RFC 3339.)

Формат даты ASP.NET JSON состоит из двух частей:

  • Первая частьвсегда метка времени Unix в миллисекундах.Другими словами, количество миллисекунд, прошедших с 1970-01-01 00: 00: 00.000 UTC, без учета високосных секунд.Он не корректируется для часового пояса - он всегда основан на UTC .

  • Вторая часть является необязательной и часто пропускается.Когда он присутствует, он отражает смещение часового пояса, которое должно быть значимым для получателя.Однако обычно он генерируется путем сериализации DateTime в .NET, свойство .Kind которого равно DateTimeKind.Local, и в этом случае оно будет отображать смещение часового пояса для этой даты на основе местного времени серверазона.Часто этот часовой пояс нерелевентен.Обратите внимание, что в отличие от ISO 8601, базовое значение составляет , а не , отрегулированное для отражения этого смещения. Другими словами, смещение является посторонним.

Таким образом, указанная вами временная метка действительно представляет значения, которые вы перечислили.(Хотя обратите внимание, что в настоящее время Мельбурн имеет UTC + 10, а не UTC + 11.)

Что касается момента, имейте в виду, что parseZone предназначен для установки смещения часового пояса объекта момента втот, который указан на входе (-0700 в данном случае).Если вас не волнует это смещение, вы можете использовать любую из других функций синтаксического анализа: 

moment.parseZone('/Date(1538245980000-0700)/').format()
//=> "2018-09-29T11:33:00-07:00"  (always)

moment('/Date(1538245980000-0700)/').format()
//=> "2018-09-29T14:33:00-04:00"  (example based on the local time zone being US Eastern time)

moment.utc('/Date(1538245980000-0700)/').format()
//-> "2018-09-29T18:33:00Z"       (always, since parsing as UTC)

moment.tz('/Date(1538245980000-0700)/', 'Australia/Melbourne').format()
//=> "2018-09-30T04:33:00+10:00"  (always - since time zone provided)

Во всех приведенных выше примерах только в первом использовался -0700.

Итак - если вы ожидали, что значение будет представлять время в Мельбурне, тогда да - Bing неверен.Возможно, есть какой-то другой параметр или аспект данных для рассмотрения.Или, возможно, это ошибка, и если это так, вы должны сообщить об этом как таковой.

Если так, и вам нужно компенсировать, то сделайте следующее: 

moment.parseZone('/Date(1538245980000-0700)/').tz('Australia/Melbourne', true).format()
//=> "2018-09-29T11:33:00+10:00"
...