使用自纪元以来的毫秒时间比较 javascript 中的日期和时间答案

【问题标题】：Compare date and time in javascript using time in milliseconds since epoch使用自纪元以来的毫秒时间比较 javascript 中的日期和时间
【发布时间】：2016-04-17 18:54:54
【问题描述】：

使用 epoch(UTC) 时间比较日期和时间是一个好习惯吗？我在互联网上检查过，但没有得到这样的例子。这种做法有什么负面影响吗？

if(date_utc1>dateutc2){
  //do something
 }

这里 date_utc1 和 date_utc2 是纪元时间

【问题讨论】：

纪元时间？纪元是 1970 年 1 月 1 日。我认为您的意思是自纪元以来的毫秒数。你拿他们比什么？您对某个特定问题有什么疑问？
是的，对不起，我的意思是自纪元以来的毫秒数。
我需要将我的系统时间与从服务器接收到的数据进行比较，该数据提供每小时的天气详细信息，然后获取系统日期和时间之后的数据
这对我来说似乎是一个有效的解决方案，特别是如果从服务器返回的数据已经采用毫秒自纪元格式。是吗？
是的，数据的单位是毫秒-since-epoch

标签： javascript date time comparison epoch

【解决方案1】：

我从 cmets 收集到其中一个日期是服务器端生成的日期，而另一个是客户端生成的日期。在不完全理解这里涉及的逻辑的情况下，我只想做一个简短的说明（对不起，没有 cmets 的代表）这两个时钟可能在时间上不完全一致（以纪元表示或不表示）。

如果可能，更好的解决方案是仅依赖一个（服务器的）时钟。当客户端最初从服务器接收数据时，客户端会保留服务器端时间戳（需要成为响应的一部分）。下线，如果客户端想检查服务器是否有更多数据，则应该将持久值发回。这样我们就可以确保服务器只返回自上次获取以来已更改的内容。

【讨论】：

【解决方案2】：

您可以使用Date.now() 获取所有最近浏览器的当前时间。如果需要，您还可以使用+new Date() 在旧版浏览器中获取相同的号码。

由于从服务器返回的数据已经是毫秒以来的纪元格式的数字，因此使用此信息进行比较是有意义的，因为来自服务器的数据不需要进行其他计算或解析完成。

我不相信这里有任何负面影响。

【讨论】：