Moment: Ищите индикатор меридием при сопоставлении с форматом iso

Созданный на 23 февр. 2016  ·  15Комментарии  ·  Источник: moment/moment

Как показано в # 2983, использование формата даты «2016-02-23 11:31:23 PM» будет соответствовать формату ISO, даже если это не так. Это приводит к синтаксическому анализу неправильной даты:

moment('2016-02-23 11:31:23 PM').format() = "2016-02-23T11:31:23-06:00"

Это потому, что 2016-02-23 11:31:23 технически является форматом ISO.
Нам нужно изменить файл из строки, чтобы проверить индикатор меридиема и сделать что-то, кроме соответствия формату ISO, если он там есть.

Bug Forgiving parsing

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

Ой! Этот выглядит так, будто наверняка кого-нибудь укусит. Предупреждения об устаревании тоже нет.

Похоже, может быть достаточно просто убедиться, что средство проверки ISO доходит до конца строки, например, добавляя $ в конец extendedIsoRegex и basicIsoRegex .

@icambron Я не думаю, что мы сможем это сделать. В настоящее время проходят следующие испытания:

    assert.ok(moment('2016-01-01 is my date').isValid(), 'test extra chars after iso date')

Почти наверняка кто-то в мире так поступает. Измените регулярное выражение, и этот тест не пройден (вместе с парой других, которые я еще не выследил).

Хмм хорошо. Я бы предпочел отказаться от этого и исправить эту вещь AM / PM, когда мы откажемся от ее поддержки. Я не вижу веской причины, по которой мы _должны_ поддерживать moment('2016-01-01 is my date')

Я немного подумал об этом, и мне как бы интересно, будет ли наименее инвазивным ответом на некоторые проблемы парсера, которые мы наблюдаем - например, этот - было бы фактически использовать парсер по умолчанию в строгом режиме. Похоже, что в большинстве случаев простые проблемы с синтаксическим анализом (подобные этой) решаются переключением в строгий режим (потому что пользователь изначально должен был использовать строгий режим). Может быть, это одна из тех вещей, которые «помогают людям попасть в яму успеха»? Это оставит возможность существующей функциональности, но подтолкнет разработчика к правильному пути.

Согласитесь, мы давно этого хотели. Я думаю, что это уже давно фигурирует в списке возможных вариантов 3.0. Но, безусловно, строгая автоматическая сигнатура с одним аргументом - небольшой шаг к этому.

Я фактически начал кодировать строгий режим по умолчанию сегодня, добавив переключаемую глобальную переменную состояния под названием globalStrict, для которой я по умолчанию установил значение true. Затем настройку строгого режима можно снова переключить на false, вызвав:

moment.globalStrict(false)

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

В качестве альтернативы для параметра globalStrict по умолчанию может быть установлено значение false, и мы могли бы настоятельно рекомендовать разработчикам установить для него значение true в документации. Это менее инвазивно и, может быть, полезно?
Я буду первым, кто скажет, что глобальные переменные состояния ОТСТУПАЮТ с точки зрения тестируемости, и уже по этой причине эта идея может быть ужасной.

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

Мне все это нравится, кроме одного:

Однако это расстроит, вероятно, тысячи людей, которые все еще возвращаются к построению даты JS.

Чтобы быть ясным, я не предлагал закончить устаревание JavaScript-конструктора. На самом деле, наоборот: в данном случае мы хотим сделать именно это, но проверка ISO вытесняет нас.

Итак, вы говорите, что попробуете глобальное состояние, или что вы бы избегали этого? Может, я просто закончу юнит-тесты и сделаю PR, и мы сможем там об этом поговорить.

Извините, мне непонятно: я вообще не против глобального состояния. Я просто не думаю, что это мешает нам постоянно выполнять строгую проверку ISO для moment(string) , даже без установленного состояния.

@maggiepint, спасибо, что указал мне на правильную тему.
и вы правильно сказали выше, что я был «одним из тех людей»: P занимался такими вещами, как
moment("2016-04-06Tnull").isValid()
с полной уверенностью, что этот момент отвергнет недопустимую строку.

Так как же проще всего включить строгий синтаксический анализ по умолчанию? (извините, ленивый)

@Aukhan, мы никогда не реализовывали global strict из-за проблемы с синтаксическим

Я думаю, что для выполнения того, что вы делаете, вам просто нужно указать в коде константу ISO_8601 и строгий режим:

moment("2016-04-06Tnull", moment.ISO_8601, true).isValid()
false

@maggiepint еще раз спасибо за ответ ...

Это отличное предложение, но я бы не хотел заменять сотни таких выражений, в которых используются не только ISO_8601, но и различные пользовательские форматы, поэтому я думаю, что было бы неплохо иметь параметр global strict.
Я начал изучать кодовую базу, но очевидно, что такая огромная и великая работа не может быть понята в одночасье.

Возможно, у меня нет необходимых навыков, но если я могу чем-то помочь, пожалуйста, дайте мне знать.
Спасибо !

@Aukhan Я посмотрю, не смогу ли я снова взять это

Закрытие в пользу №3502

Была ли эта страница полезной?
0 / 5 - 0 рейтинги