java规范化UTC日期
我试图阅读一段代码片段，但对我来说毫无意义。请帮帮我
/**
* 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）天的开始”，所有这些对我来说都没有任何意义。请任何人帮帮我
# 1 楼答案
在Java和其他编程语言中，时间点有时表示为毫秒数，自1970年1月1日UTC 00:00:00（不包括闰秒）的所谓纪元。正如注释所述，您的方法会获取这样一个数字，并将其转换为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转换为一天的开始。将一个时间点表示为毫秒计数是低级和不友好的。在调试器或日志中查看类似155307408964的数字时，通常不知道该数字是对是错。相反，应该使用
Instant，或者对于没有时间的日期，而不是LocalDate。一个Instant打印，例如2019-03-20T09:28:54.729Z。时间以UTC为单位，但即使您处于不同的时区，也不难判断它是对是错Instant和LocalDate是来自java的类。时间，现代Java日期和时间API。该API还具有用于各种日期和时间操作的方法，包括转换到一天开始的方法链接：Oracle tutorial: Date Time解释如何使用java。时间
# 2 楼答案
我想那天的单位是86400000
因为date是一个long整数，当你除以DAY\u（单位：毫秒）时，你得到一个long整数，不带小数部分
因此，当你乘以日，单位为毫秒，你会得到一个不同的数字，即四舍五入到86400000的倍数
属于同一UTC日期的2个日期将具有相同的值
数学的例子