为什么Chrome V8 JavaScript引擎将“ TG-1”至“ TG-12”识别为有效日期/时间？

Question

我实现了一个CSV解析器，该解析器猜测每一列的类型格式，但是我发现JavaScript Date类认为“ TG-1”是有效的日期/时间。

Chrome支持之前，我没有见过这种晦涩的日期格式吗？我认为这不是一个有效日期，而从其他日期来看，ISO标准我没有看到对此的参考。

Chrome 74表示有效。

Firefox 64表示无效。

let validDate = true;
try{
   d = new Date("TG-1");
   d.toISOString()
}catch(e){
   validDate = false
}
console.log(validDate);

任何后跟-数字1-12的字符串均视为有效：

d = new Date("adsfadgag-12")//valid per V8

Answer 1

引用V8源代码：

旧日期：

第一个数字之前的任何无法识别的单词都将被忽略。

带括号的文本将被忽略。

后跟“:”的无符号数字是时间值，并将其添加到 TimeComposer 中。后面跟有“::”的数字还会添加第二个零。数字后跟“.” 也是一个时间，后面必须跟毫秒。

任何其他数字都是日期组件并添加到 DayComposer。月份名称（或者实际上：与月份名称具有相同前三个字母的任何单词）在“日”编辑器中记录为命名月份。可识别为时区的单词按原样记录(+|-)(hhmm|hh:)。

旧日期不允许在读取数字后出现额外的符号（“+”或“-”）或不匹配的“）”（在第一个数字之前，允许任何垃圾）。

两者的交集：匹配两种格式的字符串（例如 1970-01-01）将被解析为 ES5 日期时间字符串 - 这意味着它将默认为 UTC 时区。如果遵循 ES5 规范，这是不可避免的。

在扫描 ES5 日期时间字符串时读取有效的“T”后，输入将不再是有效的旧日期，因为读取数字后“T”是垃圾字符串。

换句话说：这种行为并不是真正计划好的，只是某些浏览器有时会表现出这样的行为，因此必须保留这种奇怪的行为。Date(...)会毫无怨言地尝试解析几乎所有东西。