对于以下从时间戳中删除纳秒和秒组件的快速方法，是否存在任何可能失败的边缘情况？

Question

目前，我们正在使用以下方式从时间戳中删除纳秒和秒分量。

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;
}

但是，我们不确定函数的正确性。

是否存在任何行为不正确的极端情况？

Answer 1

TL;DR

Is there any edge case where it will behave incorrect?

是的，一对。

两者仅对1970年及以后的时间戳是等价的；对于 1969 年及更早的版本，他们给出了不同的结果。
前者的结果取决于时区，后者的结果不取决于时区，这在某些情况下会有所不同。

1970 年的极限

您当前的版本将秒和纳秒设置为 0，正在向下舍入（朝向时间的开头）。带除法和乘法的优化版本向零舍入。在这种情况下，“零”是 1970 年 1 月 1 日第一个时刻的纪元（UTC）。

    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 秒（25000 毫秒）。我所做的唯一区别是两个操作的顺序：截断为整分钟和转换为 UTC。结果怎么不一样？直到 1905 年 6 月 1 日，马来西亚与 GMT 的偏移量为 +06:55:25。所以当马来西亚的第二分钟是 56 点左右时，格林威治标准时间是 31 点左右。所以我们在这两种情况下都没有删除相同的秒数。

同样，我认为这对于 1973 年之后的时间戳来说不是问题。现在时区倾向于使用与 UTC 相差整数分钟的偏移量。

编辑：

(Does this ever happen after 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));
}

Link

Time Changes in Monrovia Over the Years

对于以下从时间戳中删除纳秒和秒组件的快速方法，是否存在任何可能失败的边缘情况？

Is there any possible failed edge case, for the following fast way to remove nanoseconds and seconds components from timestamp?

java

time

timestamp

java.time.instant