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

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?

是的，一对。

1. 仅对于 1970 年及以后的时间戳，两者是等效的；对于 1969 年及更早的时间，他们给出了不同的结果。
2. 前者的结果取决于时区，后者的结果则不取决于时区，这在某些情况下会产生差异。

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 日，马来西亚与 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));
}

链接

Time Changes in Monrovia Over the Years