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

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

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

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

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

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

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

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

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

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

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

И видите, что результат:

1

Мне жаль говорить, но разрыв времени переместился немного в

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

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

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

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

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

новое 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 [1 111], тем не менее, в этом случае, это ранее смещение, которые производят более долгое расхождение, и это - более ранняя дата, которая имеет два возможных смещения.

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

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

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

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

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

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

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

К Процесс Сообщества Java участники я не рекомендую:

• делают локализованные методы не значением по умолчанию, но требуют, чтобы пользователь явно запросил локализацию.
• использование UTF-8/UTC в качестве ЗАФИКСИРОВАЛО значение по умолчанию вместо этого, потому что это - просто значение по умолчанию сегодня. Нет никакой причины сделать что-то еще, кроме того, если Вы хотите произвести потоки как это.

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

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

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

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

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

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