Moment: 匹配iso格式时寻找meridiem指示符

哎哟! 那个看起来肯定会咬人。 也没有弃用警告。

似乎只是确保 ISO 检查器一直到字符串的末尾就足够了，例如通过在extendedIsoRegex和basicIsoRegex的末尾添加$ 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 项目很长时间了。 但当然，让 automagic one-arg 签名严格是朝着这个目标迈出的一小步。

实际上，我今天通过添加一个名为 globalStrict 的可切换全局状态变量（我默认为 true）开始编写默认的严格模式。 然后可以通过调用将严格模式设置切换回 false：

moment.globalStrict(false)

这使得一切都像往常一样运行，而不必更改对 moment 解析器的每次调用。
进行此更改大约需要四行代码 - 然后必须修复数百个单元测试:-)
不过，对我来说，这可能是一种无需等待 v3 就可以推出严格默认的方法。
我觉得既然用户可以轻松地将其改回来，他们可能会接受更改而没有太多抱怨。

或者， globalStrict 设置可以默认为 false，我们强烈鼓励开发人员在文档中将其设置为 true。 这是侵入性较小的，也许有帮助？
从可测试性的角度来看，我将是第一个说全局状态变量很糟糕的人，仅出于这个原因，这个想法可能很糟糕。

我也可以按照建议，将单参数调用默认为严格模​​式。 不过，这可能会让成千上万仍在使用 JS 日期构建的人感到不安。

我喜欢所有这些，除了一件事：

不过，这可能会让成千上万仍在使用 JS 日期构建的人感到不安。

需要明确的是，我的建议不是完成 can't-fall-back-to-JS-constructor 的弃用。 事实上，恰恰相反：在这种情况下，我们只想这样做，但 ISO 检查正在抢占我们。

那么，你是说你会尝试全局状态的事情，还是你会避免它？ 也许我会完成单元测试并制作 PR，然后我们可以在那里讨论它。

抱歉，我不清楚：我根本不反对全局状态。 我只是不认为它阻止我们始终严格执行moment(string)的 ISO 检查，即使没有设置状态。

@maggiepint感谢您将我指向正确的线程。
并且您在上面正确地说明了我是“那里的人之一”：P 正在做类似的事情
moment("2016-04-06Tnull").isValid()
完全有信心时刻将拒绝无效字符串。

那么默认情况下打开严格解析的最简单方法是什么？ （不好意思，懒）

@Aukhan我们从未实施过全局严格，因为需要首先修复严格模式解析的问题。 （但确实如此，所以我们可能还没有到达那里）。

为了完成你正在做的事情，我认为你只需要在你的代码中指定 ISO_8601 常量和严格模式：

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

@maggiepint再次感谢您的回复...

这是一个很好的建议，但我不想替换数百个这样的表达式，其中不仅使用 ISO_8601，而且使用不同的自定义格式，所以我想全局严格选项会很好。
我开始研究代码库，但显然不能一夜之间理解如此庞大而伟大的工作。

我可能不具备所需的技能，但如果我能以任何方式提供帮助，请告诉我。
谢谢 ！

@Aukhan我会看看我是否不能再次选择该工作项目。 问题是要使其工作，需要合并 PR #3078。 这就是为什么这东西首先被丢弃的原因。

关闭支持#3502