标准化 UTC 日期答案

【问题标题】：Normalize the UTC date标准化 UTC 日期
【发布时间】：2019-03-19 12:49:42
【问题描述】：

我正在尝试阅读代码 sn-p 但它对我没有任何意义。请帮助我

 /**
 * To make it easy to query for the exact date, we normalize all dates that go into
 * the database to the start of the day in UTC time.
 *
 * @param date The UTC date to normalize
 *
 * @return The UTC date at 12 midnight
 */
 public static long normalizeDate(long date) {
    // Normalize the start date to the beginning of the (UTC) day in local time
    long retValNew = date / DAY_IN_MILLIS * DAY_IN_MILLIS;
    return retValNew;
}

此函数接受以毫秒为单位的 UTC 转换的本地日期，现在我不知道函数实际上在做什么，注释为“将开始日期标准化为本地时间 (UTC) 日的开始日期”所有这一切都没有对我有任何意义。请任何人帮助我。

【问题讨论】：

Java？语法相似的编程语言太多了，很难说。
它们实际上似乎并不想存储真正的日期对象，但更像是日历日期，即物理日历上显示的内容。

标签： java date utc milliseconds

【解决方案1】：

在 Java 和其他编程语言中，时间点有时表示为自 1970 年 1 月 1 日 00:00:00 UTC 的所谓 epoch 以来的毫秒数，不包括闰秒。正如评论所说，您的方法采用这样的数字并将其转换为 UTC 中的 一天的开始（午夜）。例如，表示 2019 年 3 月 20 日 09:22:43 UTC 的 long 值将转换为表示 2019 年 3 月 20 日 00:00:00 UTC 的值。如果该值从一开始就只是代表一个日期，而不是一天中的某个时间，我会说将其描述为“规范化”是有道理的。

这是如何工作的？ date，保存毫秒的 long 变量，首先除以一天中的毫秒数（我假设；我正在阅读 DAY_IN_MILLIS 为“以毫秒为单位的 1 天”）。这给出了自纪元以来的天数。除法的余数被丢弃；你只得到一整天。然后当再次乘以DAY_IN_MILLIS 时，您将转换回毫秒。由于纪元在当天被定义为 00:00:00，因此您从一开始就在同一天获得 00:00:00 UTC。这是可行的，因为 UTC 没有夏令时 (DST) 和其他时间异常（在有夏令时的时区中不起作用）。

而且我承认“在当地时间”位对我来说也没有意义。我认为它从来没有任何意义。

请允许我补充一下，这是糟糕的代码，不过（即使你没有问），我也认为这是你需要问的原因。通常不鼓励使用自纪元以来的毫秒数，最好通过标准 API 转换为一天的开始。将时间点表示为毫秒计数是低级且对人类不友好的。在调试器或日志中查看像 1553074048964 这样的数字时，您通常不知道它是对还是错。相反，应该使用Instant，或者对于没有时间的日期而不是LocalDate。 Instant 打印为例如 2019-03-20T09:28:54.729Z。时间是 UTC，但即使你在不同的时区，也不难知道它是对还是错。 Instant 和 LocalDate 是现代 Java 日期和时间 API java.time 中的类。该 API 还具有用于各种日期和时间操作的方法，包括转换为一天的开始。

链接： Oracle tutorial: Date Time 解释如何使用 java.time。

【讨论】：

【解决方案2】：

我想 DAY_IN_MILLIS 是 86400000

因为日期是一个 long 整数，当你除以 DAY_IN_MILLIS 时，你会得到一个 long 整数没有小数部分。

因此，当您乘以 DAY_IN_MILLIS 后，您会得到一个不同的数字，即四舍五入为 86400000 的倍数。

属于同一 UTC DAY 的 2 个日期将具有相同的值。

数学示例

( 1 / 10 ) * 10   => 0 

( 9 / 10 ) * 10   => 0 

( 11 / 10 ) * 10   => 10

( 19 / 10 ) * 10   => 10

【讨论】：