目前，我们使用以下方法从时间戳中删除纳秒和秒分量。
public static long toMinuteResolution(long timestamp) {
return Instant.ofEpochMilli(timestamp).atZone(ZoneId.systemDefault()).withNano(0).withSecond(0).toInstant().toEpochMilli();
}
上述功能应在所有情况下正常工作。
但是，我们正在寻找一种更快的功能。
我们计划使用以下功能，它更快。
public static long toMinuteResolution(long timestamp) {
return timestamp / 1000 / 60 * 1000 * 60;
}
但是，我们不确定函数的正确性。
是否有任何边缘情况会表现不正确？
TL;博士
是否有任何边缘情况会表现不正确？
是的，一对。
- 这两者只等效于1970年及以后的时间戳;对于1969年及更早的时间戳，它们给出不同的结果。
- 前者的结果取决于时区，后者的结果则不取决于时区，这在某些情况下会产生差异。
1970年的限制
当前版本将秒和纳秒设置为 0，将向下舍入(接近时间的开始(。带有除法和乘法的优化版本四舍五入为零。在本例中为"零"，即 UTC 中 1970 年 1 月 1 日的第一个时刻的纪元。
long exampleTimestamp = Instant.parse("1969-12-15T21:34:56.789Z").toEpochMilli();
long with0Seconds = Instant.ofEpochMilli(exampleTimestamp)
.atZone(ZoneId.systemDefault())
.withNano(0)
.withSecond(0)
.toInstant()
.toEpochMilli();
System.out.println("Set seconds to 0: " + with0Seconds);
long dividedAndMultiplied = exampleTimestamp / 1000 / 60 * 1000 * 60;
System.out.println("Divided and multiplied: " + dividedAndMultiplied);
此代码段的输出是(在我的时区和大多数时区(：
Set seconds to 0: -1391160000 Divided and multiplied: -1391100000
两个输出之间相差 60 000 毫秒，即整整一分钟。
对时区的依赖性
您可能对删除秒的定义有疑问。秒数并非在所有时区都相同。例如：
ZoneId zone = ZoneId.of("Asia/Kuala_Lumpur");
ZonedDateTime exampleTime = ZonedDateTime.of(1905, 5, 15, 10, 34, 56, 789_000_000, zone);
// Truncation in time zone
long longTzTimestamp = exampleTime.truncatedTo(ChronoUnit.MINUTES)
.toInstant()
.toEpochMilli();
System.out.println("After truncation in " + zone + ": " + longTzTimestamp);
// Truncation in UTC
long longUtcTimestamp = exampleTime.toInstant()
.truncatedTo(ChronoUnit.MINUTES)
.toEpochMilli();
System.out.println("After truncation in UTC: " + longUtcTimestamp);
After truncation in Asia/Kuala_Lumpur: -2039631685000 After truncation in UTC: -2039631660000
两个时间戳之间存在 25 秒(25 000 毫秒(的差异。我所做的唯一区别是两个操作的顺序：截断到整分钟和转换为 UTC。结果怎么不一样？直到1905年6月1日，马来西亚与格林威治标准时间的偏移量为+06：55：25。因此，当马来西亚的第二分钟是56分时，格林威治标准时间是31分。因此，在这两种情况下，我们都不会删除相同的秒数。
同样，我认为这对于 1973 年之后的时间戳来说不会成为问题。如今，时区倾向于使用与 UTC 相差整分钟的偏移量。
编辑：
(这种情况在1970年之后发生过吗？
一点。例如，利比里亚在 1972 年 1 月 6 日之前处于偏移 -0：44：30 状态。任何人都会猜测某个国家的政客明年或后年会做出什么决定。
检查边缘情况
检查您是否遇到上述情况之一的一种方法是使用assert：
public static long toMinuteResolution(long timestamp) {
assert timestamp >= 0 : "This optimized method doesn’t work for negative timestamps.";
assert Duration.ofSeconds(Instant.ofEpochMilli(timestamp).atZone(ZoneId.systemDefault()).getOffset().getTotalSeconds())
.toSecondsPart() == 0
: "This optimized method doesn’t work for an offset of "
+ Instant.ofEpochMilli(timestamp).atZone(ZoneId.systemDefault()).getOffset();
return TimeUnit.MINUTES.toMillis(TimeUnit.MILLISECONDS.toMinutes(timestamp));
}
由于您想要优化，因此我希望这些检查对于您的生产环境来说过于昂贵。您比我更清楚在您的测试环境中启用它们是否会给您一些保证。
进一步的建议
正如Andreas在评论中所说，truncatedTo方法使非优化版本更简单，更清晰：
public static long toMinuteResolution(long timestamp) {
return Instant.ofEpochMilli(timestamp)
.atZone(ZoneId.systemDefault())
.truncatedTo(ChronoUnit.MINUTES)
.toInstant()
.toEpochMilli();
}
如果需要，您也可以直接在Instant上使用truncatedTo，就像Andreas的评论一样。
无论如何，如果您想进行优化，为了提高可读性，我的优化版本将是：
private static final long MILLIS_PER_MINUTE = TimeUnit.MINUTES.toMillis(1);
public static long toMinuteResolution(long timestamp) {
return timestamp / MILLIS_PER_MINUTE * MILLIS_PER_MINUTE;
}
我什至可以尝试以下内容，看看它是否足够有效。我预计没有明显的差异。
public static long toMinuteResolution(long timestamp) {
return TimeUnit.MINUTES.toMillis(TimeUnit.MILLISECONDS.toMinutes(timestamp));
}
链接
蒙罗维亚历年时间变化