Moment: Путаница по поводу moment.utz с MySQL DateTime

Созданный на 18 апр. 2016 · 3Комментарии · Источник: moment/moment

Я написал здесь небольшой тест: https://jsfiddle.net/vrdhcuey/1/

Когда мы запрашиваем из базы данных, мы получаем DATETIME из базы данных MySQL обратно (изначально установлен часовой пояс UTC по умолчанию, но также тестировался с установленным как часовой пояс Европа / Дублин) 2016-04-22T16:00:00.000Z - то есть дата окончания нашего объекта - пятница, 22 апреля, в 16:00. На самом деле это без часовой пояс, поскольку все, что мы говорим, это то, что событие может закончиться в 16:00 в заданный день, но эта дата может выпасть на GMT или BST.

В предоставленном тесте мы хотим получить продолжительность между настоящим моментом и датой и временем. Однако это всегда час отдыха. Единственный способ обойти это - удалить .000Z из конца строки даты и времени. Я также пробовал использовать moment.tz, но получил тот же результат (т.е. в этом тесте leftTime4 является правильным поведением, которого мы ожидаем). Однако я ожидал, что leftTime2 будет работать как есть.

Может ли кто-нибудь прояснить эту путаницу, или я обнаружил здесь ошибку?

Источник

tanepiper

Самый полезный комментарий

Стандарт ISO8601 определяет, что даты, заканчивающиеся на Z, должны интерпретироваться как UTC. Таким образом, момент, когда прошло ваше время, преобразует время из UTC в местное. Вот как вы получите один час отдыха.

Если вы хотите, чтобы момент времени игнорировал Z (интерпретировать время как местное), вы можете указать формат, который не учитывает Z, выполнив следующие действия:

moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()

Если вам нужна дополнительная информация о различных режимах синтаксического анализа, может оказаться полезным этот раздел руководств: http://momentjs.com/guides/#/parsing/local -utc-zone /

maggiepint 19 апр. 2016

👍2

Все 3 Комментарий

moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()

maggiepint 19 апр. 2016

👍2

Правильно - так что настоящее исправление заключается в том, что не отправляйте Z из своего бэкенда, если вы на самом деле не имеете в виду UTC.

mj1856 19 апр. 2016

😄1

@ mj1856 Да, пытался, но мне интересно, связана ли проблема с Sequlize, а не с самим MySQL - когда мы запускаем запрос к БД напрямую, он выдает просто DATETIME с YYYY-MM-DD HH: MM: SS, поскольку он хранится . Изменение часового пояса БД, похоже, не имело никакого значения. В любом случае, похоже, что на данный момент это исправляет, посмотрим, сохранится ли оно, когда вернемся в GMT: bomb:

tanepiper 20 апр. 2016

Была ли эта страница полезной?

0 / 5 - 0 рейтинги