我正在尝试阅读代码片段，但这对我没有任何意义。请帮助我
/**
* 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和其他编程语言中，时间点有时表示为自1970年1月1日00:00:00 UTC的所谓纪元以来的数毫秒，不包括闰秒。正如评论所说，您的方法需要这样一个数字并将其转换为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.time的类，现代Java日期和时间API。该API还具有用于各种日期和时间操作的方法，包括转换到一天的开始。
链接：Oracle tutorial: Date Time解释如何使用java.time。
我想DAY_IN_MILLIS是86400000
因为date是一个长整数，当你除以DAY_IN_MILLIS时，你得到一个没有小数部分的长整数。
因此，当您乘以DAY_IN_MILLIS后，您将获得一个不同的数字，即四舍五入为86400000的倍数。
属于同一UTC DAY的2个日期将具有相同的值。
数学的例子
( 1 / 10 ) * 10 => 0
( 9 / 10 ) * 10 => 0
( 11 / 10 ) * 10 => 10
( 19 / 10 ) * 10 => 10