我正在研究一个项目的功能，该功能会根据记录的创建日期更改元素的颜色。我正在使用Rails后端和React前端。我正在尝试确保颜色与适当的日期匹配，而不是与前一天或之后匹配。
在Rails中，我有一条记录，其中created_at属性为"2020-07-29 17:38:00.437423"（PST）
在React中，同一条记录显示其created_at属性为"2020-07-29T17:38:00.437Z"
1。
new Date("2020-07-29 17:38:00.437423")
//=> Wed Jul 29 2020 17:38:00 GMT-0700 (Pacific Daylight Time)
new Date("2020-07-29T17:38:00.437Z")
//=> Wed Jul 29 2020 10:38:00 GMT-0700 (Pacific Daylight Time)
我注意到在第二个版本中删除“ Z”时，时间符合我的预期，但是为什么这些字符串返回的日期对象显示7个小时的差异？
在浏览器中，当您创建一个没有任何时区信息的日期时，它实际上会假定其位于系统时区中：
new Date("2020-07-29 17:38:00.437423")
> Date Wed Jul 29 2020 17:38:00 GMT+0200 (Central European Summer Time)
就我而言，这GMT+0200是因为我在丹麦。哎呀
2020-07-29T17:38:00.437Z 实际上是带有时区名称的ISO8601时间戳，该名称的含糊不清。
如果时间以UTC为单位，请在时间后直接添加Z，且不带空格。Z是零UTC偏移量的区域标记。因此，“ 09:30 UTC”表示为“ 09：30Z”或“ 0930Z”。“ 14:45:15 UTC”将是“ 14：45：15Z”或“ 144515Z”。
ISO8601-维基百科
JavaScript的日期和时间处理非常糟糕。当Brendan Eich在浏览器大战中在10天内急于创建该语言时，他只是从Java中彻底删除了日期/时间对象，而浏览器供应商则创建了不同的（糟糕的）实现。结果是一团糟，仍然困扰着我们25年。
像moment.js这样的多个库可以解决该语言的问题和不一致之处，以及缺少从一种TZ转换为另一种TZ或操纵日期的方法。
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.27.0/moment.min.js"></script>
我真的会推荐Thoughtbot的出色文章“关于时间（Zones） ”作为后端的内容。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句