您似乎处于时区
Europe/Berlin
或类似时区,并且目前与 UTC 有 2 小时的正偏移。
ISO 格式的时间戳应指定时区作为后缀。
Z
将是 UTC。然而,您的 measurementTimestamp
缺少后缀,并且 new Date
将其解释为“当前本地时区”(在您的情况下为 +02:00),这就是您在这里得到差异的原因。
您可以将缺失的Z
添加到
measurementTimestamp
来解决这个问题:
(new Date('2021-09-24T15:38:18.569Z') - new Date('2021-09-24T15:37:46.612Z')) / 1000
// ^
// Result: 31.957
重要提示:这与从另一个时间戳中删除Z
不同,因为这样你实际上会比较本地时区中的两个时间(事实上,这些时间与你真正关心的任何事情无关,因为它们是将 UTC 时间解释为本地时间的结果,然后指向不同的时间点)。 您可能认为这并不重要,因为如果现在
两者都是本地的,那么偏移量应该抵消,对吧? ...但如果您比较的时间戳之间存在夏令时边界,则情况并非如此!如果两者都是 UTC,则它们是绝对的(UTC 中没有夏令时 - 它会在 Europe/London
中,但这是不一样的),但在您当地的时区,您可以让时钟来回移动每年两次小时(
Europe/Berlin
半年为 +02:00,其余时间为 +01:00)。查看我得到的这些结果(我在
Europe/Berlin
):
(new Date('2021-03-28T03:00:00Z') - new Date('2021-03-28T01:00:00Z')) / 1000
// Result: 7200
(new Date('2021-03-28T03:00:00') - new Date('2021-03-28T01:00:00')) / 1000
// Result: 3600 (!!!)
这里的时钟从 2021 年 3 月 28 日的 02:00 向前调至 03:00。因此,将 03:00 和 01:00 这两个时间与本地时区进行比较,只得出一个小时的差异,而不是两个小时!如果我现在真的打算将 03:00 UTC 与 01:00 UTC 进行比较,我会得到完全错误的结果,这可能会毁了我的一天。
让我再添加一个更糟糕的例子:
(new Date('2021-03-28T03:30:00Z') - new Date('2021-03-28T02:45:00Z')) / 1000
// Result: 2700
(new Date('2021-03-28T03:30:00') - new Date('2021-03-28T02:45:00')) / 1000
// Result: -900 (???)
03:30 应该是 45 分钟(2700 秒)在02:45 之后,对吧?那么为什么我们现在得到的是 -15 分钟的负数呢?嗯,在我当地时间,02:45 根本不存在,因为 01:59 之后就是当天的 03:00...并且它的处理方式与您尝试设置 11 月 31 日这样的日期相同在 JavaScript 中(将像 12 月 1 日一样处理) - 它会翻转并被视为与 03:45 相同。
const isSameNotConsideringUtc = (firstDate: string, secondDate: string) => {
const dayJsFirstDate = dayjs(firstDate?.replace('Z','')), dayJsSecondDate = dayjs(secondDate?.replace('Z',''));
return dayJsFirstDate.isSame(dayJsSecondDate)
}
Day.js 在这里不是强制性的,这只是一个使用 Day.js 进行日期处理的示例。关键部分是从文字字符串中删除 Z
(new Date(new Date().toISOString().slice(0,-1)) - new Date(measurement.measurementTimestamp))/1000