Есть ли возможный случай сбоя края для следующего быстрого способа удалить компоненты наносекунд и секунд из метки времени? - PullRequest
Новая
       48

Есть ли возможный случай сбоя края для следующего быстрого способа удалить компоненты наносекунд и секунд из метки времени?

0 голосов
/ 28 января 2020

В настоящее время мы используем следующий способ удаления наносекунд и секунд компонентов из отметки времени. 

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 Ответ

1 голос
/ 28 января 2020

TL; DR

Есть ли крайний случай, когда он будет вести себя некорректно?

Да, пара.

  1. The два эквивалентны только для отметок времени в 1970 году и позже; для 1969 года и ранее они дают разные результаты.
  2. Результат первого зависит от часового пояса, а второго - нет, что в некоторых случаях дает различия.

Предел 1970 года

Ваша текущая версия с настройкой секунд и наносекунд на 0 округляется в сторону уменьшения (к началу времени). Оптимизированная версия с делением и умножением округляется до нуля. В этом случае «ноль» это эпоха первого момента 1 января 1970 года в UT C. 

    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 миллисекунд). Единственное отличие, которое я сделал, - порядок двух операций: усечение до целых минут и преобразование в UT C. Почему результат отличается? До 1 июня 1905 года Малайзия находилась в зачете +06: 55: 25 от GMT. Поэтому, когда вторая секунда в Малайзии составляла 56 баллов, в GMT это было 31 балл. Таким образом, мы не удаляем одинаковое количество секунд в обоих случаях.

Опять же, я не думаю, что это будет проблемой для отметок времени после 1973 года. В настоящее время часовые пояса имеют тенденцию использовать смещения, которые представляют собой целое число минуты от UT C.

Редактировать:

(это когда-нибудь случалось после 1970 года?)

Немного. Например, Либерия находилась в зачете -0: 44: 30 до 6 января 1972 года. И никто не может догадаться, что политики в какой-то стране решат в следующем году или через год после этого.

Проверка на крайние случаи

Один из способов проверить, что вы попали в один из случаев, упомянутых выше, - это использовать 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));
}

Поскольку вы хотели оптимизировать, я ожидаю, что эти проверки будут слишком дороги для вашего производства окружающая обстановка. Вы знаете лучше, чем я, даст ли вам некоторую уверенность в том, что включение их в ваших тестовых средах.

Дальнейшие предложения

Как сказал в комментариях Андреас, метод truncatedTo делает неоптимизированную версию немного проще и понятнее: 

public static long toMinuteResolution(long timestamp) {
    return Instant.ofEpochMilli(timestamp)
            .atZone(ZoneId.systemDefault())
            .truncatedTo(ChronoUnit.MINUTES)
            .toInstant()
            .toEpochMilli();
}

Вы можете использовать truncatedTo непосредственно на Instant, если хотите, как в комментарии Андреаса.

Если вы хотите go в любом случае, с вашей оптимизацией, для лучшей читаемости моя оптимизированная версия будет выглядеть так: 

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

Ссылка

Изменения во времени в Монровии с годами

...