是否有任何可能的失败边缘情况，以下快速方式删除纳秒和秒组件的时间戳？
目前，我们正在使用以下方法从时间戳中删除纳秒和秒组件。
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;
}然而，我们并不确定该函数的正确性。
是否有边缘情况下，它的行为将不正确？
回答 1
Stack Overflow用户
发布于 2020-01-28 03:27:10
TL;DR
是否有边缘情况下，它的行为将不正确？
是的，一对。
- 这两种方法仅适用于1970年及以后的时间戳；对于1969年及更早的时间，两者给出了不同的结果。
- 前者的结果取决于时区，后者的结果不依赖于时区，这在某些情况下产生了差异。
1970年的极限
您的当前版本，将秒和纳秒设置为0，正在向下舍入(朝向时间的开始)。带有除法和乘法的优化版本正在接近于零。在这种情况下，“零”是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);这个片段的输出是(在我的时区和大多数时区)：
将秒设置为0：-1391160000除以并乘以：-1391100000
这两个输出之间相差60000毫秒，整整一分钟。
依赖时区
您可能对删除秒的定义有问题。在所有时区，秒数并不总是相同的。例如：
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);亚洲截断后/吉隆坡：-2039631685000在世界协调时截断后：-2039631660000
这两个时间戳之间的差异是25秒(25000毫秒)。我唯一的区别是两个操作的顺序:截断到整分钟和转换到UTC。结果怎么会不同呢？直到1905年6月1日，马来西亚从格林尼治标准时间开始一直处于+06:55:25。所以当第二分钟在马来西亚是56分时，在格林尼治标准时间是31分。因此，在这两种情况下，我们都不会删除相同的秒数。
再说一次，我不认为这会成为1973年后的时间戳的问题。如今，时区倾向于使用从世界协调时起的一整分钟的偏移量。
编辑：
(这种情况是否发生在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上使用Instant，如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));
}链接
https://stackoverflow.com/questions/59941261
复制相似问题
腾讯云开发者
