为什么2个时间戳之间的差异与预期值＆＃xff1f相比有一个小时的偏差;
以日期为“ 2022-04-01'，另一个日期”'2022-05-15'。当我计算它们在Chrome DevTools中的偏差时，我得到的是：
但是当我的朋友在另一个设备上做同样的事情时，他得到的是：
结果是 3798000000 。 3801600000 和 3798000000 之间的差异完全是一个小时。什么可能导致此结果？如何消除这种差异？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您缺少区域数据：
utc dateTime：
new Date（“ 2021-01-01-01T12：00：00 Z”）;utc-4 dateTime：
new Date（“ 2021-01-01-01T12：” 00：00-04：00“）;You lack the zone data:
UTC datetime:
new Date("2021-01-01T12:00:00Z");UTC-4 datetime:
new Date("2021-01-01T12:00:00-04:00");您正在遇到的主要问题是因为将输入字符串解释为分配给本地时区，并且您一直在测试的两台计算机上有不同的时区。其中一个在两个日期之间有DST过渡，而另一个日期则没有 - 这解释了您的一个小时差异。
您显示的示例还揭示了您可能的时区：
您的机器在两个时间戳都提前8小时（UTC+8）显示。世界上有几个地区使用没有DST的UTC+8，包括中国，西澳大利亚州，Irkutsk俄罗斯等等。地球上没有使用UTC+8与DST一起使用的地方。
您的朋友的机器是另一个故事。时间戳在2022-04-01提前2小时（UTC+2）提前2小时，在2022-05-15提前3小时（UTC+3）提前3小时。尽管许多国家使用这些偏移（例如在东欧使用EET/EET的偏移量），但这些地区都没有在这两个日期之间过渡。请参阅 3月份过渡。我只能得出结论，您朋友的计算机具有一些非标准的时区设置，或者它们在时区数据更新或两者兼而有之。 （如果我对此不正确，请在评论中回复！）
另外，您的输入字符串格式，
2022-04-01 00:00:00不在由Ecmascript规范定义的标准日期时间字符串格式。因此，不能保证所有浏览器始终如一地解析。 Chrome，Edge和Firefox的当前版本将其解释为本地日期和时间，但是当前版本的Safari将以“无效的日期”失败。如果您希望在所有浏览器中正确解释为当地时间，则需要将其指定为
2044-04-04-01T00：00：00：00。如果您希望将其解释为UTC，则指定为
2044-04-01T00：00：00：00z。如果要用特定的时区偏移来解释它，则将其附加为：
2044-04-04-01T00：00：00：00+08：00。。
如果您必须以原始格式解析字符串，则不要使用
date对象进行操作。要么使用库（例如 luxon 或 date-fns ），或用Regex和/或字符串操纵技术自己解析。The main issue you are experiencing is because your input string is being interpreted as assigned to the local time zone, and you have different time zones on the two machines you've been testing with. One of them has a DST transition between the two dates, and the other does not - which explains your one hour difference.
The examples you show also reveal your possible time zones:
Your machine is showing 8 hours ahead of UTC (UTC+8) for both timestamps. There are several parts of the world that use UTC+8 without DST, including China, Western Australia, Irkutsk Russia, and many others. There are no places on earth that use UTC+8 in conjunction with DST.
Your friend's machine is a different story. The timestamps are showing 2 hours ahead of UTC (UTC+2) on 2022-04-01, and 3 hours ahead of UTC (UTC+3) on 2022-05-15. While many countries use those offsets (such as those that are in Eastern Europe that use EET/EEST), none of those areas have a DST transition between those two dates. See the bottom of this table of DST transitions. All of the +2/+3 areas of the world transitioned in March. I can only conclude that your friend's machine has some non-standard time zone setting, or they are significantly behind on time zone data updates, or both. (Please reply in comments if I am incorrect on this!)
Also, your input string format,
2022-04-01 00:00:00is not in the standard date time string format defined by the ECMAScript specification. Thus, it is not guaranteed to be parsed consistently by all browsers. Current versions of Chrome, Edge, and Firefox will interpret it as a local date and time, but the current version of Safari will fail with "Invalid Date".If you want it interpreted as local time correctly in all browsers, you would need to specify it as
2044-04-01T00:00:00.If you want it interpreted as UTC then specify as
2044-04-01T00:00:00Z.If you want it interpreted with a specific time zone offset, then append that instead, as in:
2044-04-01T00:00:00+08:00.If you must parse the string in the original format, then don't do it using the
Dateobject. Either use a library (such as Luxon or date-fns), or parse it yourself with regex and/or string manipulation techniques.