Почему вычитание этих двух раз (в 1927 году) дает странный результат?

Ответ 1

Это изменение часового пояса 31 декабря в Шанхае.

Смотрите эту страницу для деталей 1927 года в Шанхае. В основном в полночь в конце 1927 года часы вернулись на 5 минут и 52 секунды. Таким образом, "1927-12-31 23:54:08" фактически происходило дважды, и похоже, что Java анализирует его как более поздний возможный момент для этой локальной даты/времени - отсюда и разница.

Просто еще один эпизод в часто странном и чудесном мире часовых поясов.

РЕДАКТИРОВАТЬ: Стоп пресс! История меняется...

Исходный вопрос больше не будет демонстрировать совершенно такое же поведение, если его перестроить с версией TZDB 2013a. В 2013a результат будет 358 секунд с временем перехода 23:54:03 вместо 23:54:08.

Я заметил это только потому, что собираю подобные вопросы в Noda Time в форме модульных тестов... Тест теперь изменен, но он просто показывает, что даже исторические данные не являются безопасными.

РЕДАКТИРОВАТЬ: История снова изменилась...

В TZDB 2014f время изменения сместилось на 1900-12-31, и теперь оно составляет всего 343 секунды (так что время между t и t+1 составляет 344 секунды, если вы понимаете, что я имею в виду).

РЕДАКТИРОВАТЬ: Чтобы ответить на вопрос о переходе в 1900 году... похоже, что реализация часового пояса Java обрабатывает все часовые пояса как просто в их стандартное время в любой момент до начала 1900 UTC:

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

Приведенный выше код не производит вывод на мой компьютер с Windows. Таким образом, любой часовой пояс с любым смещением, отличным от стандартного в начале 1900 года, будет считаться переходным. Сам TZDB имеет некоторые данные, возвращающиеся раньше, и не полагается на идею "фиксированного" стандартного времени (что getRawOffset предполагает допустимым понятием), поэтому другим библиотекам не нужно вводить этот искусственный переход.

Ответ 2

Вы столкнулись с локальным временным разрывом:

Когда местное стандартное время достигло воскресенья, 1. января 1928 года, 00:00:00 часы были повернуты назад 0:05:52 часов до субботы, 31. Декабрь 1927, 23:54:08 вместо обычного локального времени

Это не особенно странно и произошло повсюду в тот или иной момент, когда временные интервалы были изменены или изменены из-за политических или административных действий.

Ответ 3

Мораль этой странности такова:

• Использовать даты и время в формате UTC по мере возможности.
• Если вы не можете отображать дату или время в UTC, всегда указывайте часовой пояс.
• Если вы не можете вводить дату/время ввода в UTC, вам требуется явно указанная зона времени.

Ответ 4

При увеличении времени вы должны вернуться в UTC, а затем добавить или вычесть. Используйте локальное время только для отображения.

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

Если вы конвертировали в UTC, добавьте каждую секунду и конвертируйте в локальное время для отображения. Вы пройдете через 11:54:08 вечера. LMT - 11:59:59 пм. LMT, а затем 11:54:08. CST - 11:59:59 с. CST.

Ответ 5

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

long difference = (sDt4.getTime() - sDt3.getTime()) / 1000;
System.out.println(difference);

И посмотрите результат:

1

Ответ 6

Прошу прощения, но разрыв времени немного сдвинулся

JDK 6 два года назад, а в JDK 7 совсем недавно в обновлении 25.

Урок, который нужно выучить: избегайте времени, отличного от UTC, любой ценой, за исключением, возможно, демонстрации

Ответ 7

Как объясняют другие, там есть разрыв времени. Для 1927-12-31 23:54:08 в Asia/Shanghai есть два возможных смещения временной шкалы, но только одно смещение для 1927-12-31 23:54:07. Таким образом, в зависимости от того, какое смещение используется, существует либо разница в одну секунду, либо разница в 5 минут и 53 секунды.

Это небольшое смещение смещений вместо обычной одночасовой дневной сбережения (летнее время), с которой мы привыкли, немного затушевывает проблему.

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

Новый пакет java.time на Java 8 позволяет использовать это более четко и предоставлять инструменты для его обработки. Дано:

DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder();
dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE);
dtfb.appendLiteral(' ');
dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME);
DateTimeFormatter dtf = dtfb.toFormatter();
ZoneId shanghai = ZoneId.of("Asia/Shanghai");

String str3 = "1927-12-31 23:54:07";  
String str4 = "1927-12-31 23:54:08";  

ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai);
ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai);

Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap());

Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap());

Тогда durationAtEarlierOffset будет на одну секунду, а durationAtLaterOffset будет пять минут и 53 секунды.

Кроме того, эти два смещения одинаковы:

// Both have offsets +08:05:52
ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset();
ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset();

Но эти две разные:

// +08:05:52
ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset();

// +08:00
ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset();

Вы можете увидеть ту же проблему, сравнивая 1927-12-31 23:59:59 с 1928-01-01 00:00:00, хотя в этом случае это более раннее смещение, которое приводит к более длинной дивергенции, и это более ранняя дата, которая имеет два возможных смещения.

Другой способ приблизиться к этому - проверить, происходит ли переход. Мы можем сделать это следующим образом:

// Null
ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

// An overlap transition
ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

Вы можете проверить, является ли переход перекрытием - в этом случае имеется более одного допустимого смещения для этой даты/времени или пробела - в этом случае эта дата/время недействительна для этого идентификатора зоны - с помощью isOverlap() и isGap() на zot4.

Я надеюсь, что это поможет людям справиться с такой проблемой, как только Java 8 станет широко доступным, или тем, кто использует Java 7, которые используют backport JSR 310.

Ответ 8

ИМХО распространенная, неявная локализация в Java - это один из самых больших недостатков дизайна. Он может быть предназначен для пользовательских интерфейсов, но, честно говоря, кто действительно использует Java для пользовательских интерфейсов сегодня, за исключением некоторых IDE, где вы можете в основном игнорировать локализацию, потому что программисты не являются целевой аудиторией. Вы можете исправить это (особенно на серверах Linux):

• экспорт LC_ALL = C TZ = UTC
• установите системные часы на UTC
• никогда не используйте локализованные реализации, если это абсолютно необходимо (т.е. только для отображения)

Являясь членами сообщества Java, я рекомендую:

• сделать локализованные методы не стандартными, но требуют, чтобы пользователь явно запрашивал локализацию.
• используйте UTF-8/UTC как значение FIXED по умолчанию, потому что это просто по умолчанию сегодня. Нет причин делать что-то еще, за исключением случаев, когда вы хотите создавать такие потоки.

Я имею в виду, давайте, не являются глобальными статическими переменными анти-OO-образцом? Ничто другое не является распространенным дефолтом, данным некоторыми элементарными переменными среды.......

Ответ 9

Как говорили другие, это было изменение времени в 1927 году в Шанхае, как говорили другие.

В основном, это 23:54:07 в Шанхае по местному стандартному времени, через некоторое время оно перешло на следующий день в 00:00:00. Но затем он переключился на 23:54:08 по местному стандартному времени. Так вот почему разница составляет 343 секунды, а не 1 секунду.

Это также может испортить другие места, такие как США. В США у них есть летнее время. Когда начинается летнее время, время идет вперед на 1 час. Но через некоторое время летнее время заканчивается, оно возвращается назад на 1 час назад к стандартному часовому поясу. Так что иногда при сравнении времени в США разница составляет около 3600 секунд, а не 1 секунда.

Лучше использовать UTC, где время не меняется, если только не нужно использовать время не UTC, как на дисплее.

Ответ 10

import java.util.TimeZone;

public class Demo {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}