始终使用 .toISOString()
它们提供几乎相同的信息,但格式不同。这是我在我的机器上得到的。
new Date().toISOString()
"2019-10-11T18:56:08.984Z"
new Date().toUTCString()
"Fri, 11 Oct 2019 18:56:08 GMT"
.toISOString() 比 .toUTCString() 更常见的原因有 4 个。
A.排序更方便
当您按字母顺序排序时,.toISOString() 的“2019-10-11T18:56:08.984Z”模式会为您提供正确的日期顺序。
B.毫秒精度
.toISOString() 提供毫秒值,而.toUTCString() 不提供。
C.任何用户都能正确解读
.toUTCString() 值对于人类最终用户来说可能更熟悉,但前提是语言设置适合他们。相比之下,无论语言设置如何,.toISOString() 都是相同的。
D.可通过软件重现再生
您可以轻松地将 ISO 日期字符串转换为 Javascript 日期对象,然后再转换回来,重新生成完全相同的字符串。这与谁给你 ISO 日期字符串、服务器在哪里以及你在哪里无关。
这对于 UTC 字符串不会自动成立。例如,如果您的应用系统的第二个实例在不同的时区或语言中运行,则它的 .toUTCstring() 可能会使用不同的数字或单词(分别)来表示同一时刻。它很难创建与应用程序的第一个实例生成的内容相匹配的 UTCString,因为通常它不知道生成第一个 UTC 字符串的语言或时区。
我认为没有人需要 .toUTCString()
我不知道为什么存在`.toUTCString()`。它的单词繁重的格式使得它无法在您的程序中
内部存储日期,因为它会根据您的语言和时区设置等而有所不同。
所以也许是为了让用户看到在外部显示一些不错的东西?嗯,不是真的。不在伦敦时区的任何人都不会觉得它很有帮助。
我住在伦敦。甚至我,即使我正在编写一个纯粹供我使用的应用程序,仅在我的系统上,并且只在我的家中,仍然不想使用@987654330 @。因为它显示的是 UTC(也称为 GMT)。伦敦并不总是格林威治标准时间。在夏天,我们移至 GMT+1,因此.toUTCString() 结果会误导任何没有注意到“GMT”并在脑海中进行时间调整的人。
如果我想要一个自然语言时间,为了让不懂计算机的用户感到舒适,我会使用像 moment.js 这样的库从部分手动构建它。如果我想要一个快速而简单的解决方案,我会使用.toString(),它至少会在适当的时候转移到夏季时间。