Dlaczego odjęcie tych dwóch razy (w 1927 roku) daje dziwny wynik?

Napotkałeś nieciągłość czasu lokalnego :

Kiedy lokalny czas standardowy zbliżał się do niedzieli, 1. Styczeń 1928, 00: 00: 00 Zegary zostały odwrócone do tyłu 0: 05: 52 godzin do soboty, 31. Grudzień 1927, 23: 54: 08 czasu lokalnego standardowego

Nie jest to szczególnie dziwne i działo się prawie wszędzie w tym czy innym czasie, ponieważ strefy czasowe zostały zamienione lub zmienione z powodu działań politycznych lub administracyjnych.

Morał tej dziwności to:

• Użyj dat i godzin w UTC, o ile to możliwe.
• Jeśli nie możesz wyświetlić daty lub godziny w UTC, zawsze wskaż strefę czasową.
• Jeśli nie możesz wymagać wprowadzenia daty / czasu w UTC, wymagaj wyraźnie wskazanej strefy czasowej.

Podczas zwiększania czasu należy konwertować z powrotem na UTC, a następnie dodać lub odjąć. Czas lokalny służy tylko do wyświetlania.

W ten sposób będziesz mógł przejść przez wszystkie okresy, w których godziny lub minuty zdarzają się dwa razy.

Jeśli przekonwertowałeś NA UTC, dodaj każdą sekundę i przekonwertuj na czas lokalny do wyświetlenia. Przeszedłbyś 23: 54: 08 LMT - 11:59:59 11: 54: 08 - 11:59:59 p. m. CST.

Zamiast konwertować każdą datę, używasz następującego kodu

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

I zobacz wynik to:

1

Przykro mi to mówić, ale nieciągłość czasowa przesunęła się trochę w

JDK 6 dwa lata temu, a w JDK 7 niedawno w update 25 .

Lekcja do nauczenia się: unikaj za wszelką cenę czasów innych niż UTC, może poza wyświetlaniem.

Jak wyjaśniają inni, istnieje nieciągłość czasowa. Istnieją dwa możliwe przesunięcia strefy czasowej dla 1927-12-31 23:54:08 w Asia/Shanghai, ale tylko jedno przesunięcie dla 1927-12-31 23:54:07. Tak więc, w zależności od tego, który przesunięcie jest używane, jest albo jedna sekunda różnica lub 5 minut i 53 sekund różnica.

To niewielkie przesunięcie przesunięć, zamiast zwykłej jednogodzinnej oszczędności czasu letniego, do której jesteśmy przyzwyczajeni, trochę zasłania problem.

Należy zauważyć, że aktualizacja 2013a bazy danych strefy czasowej została przeniesiona ta nieciągłość kilka sekund wcześniej, ale efekt będzie nadal obserwowalny.

Nowy pakiet java.time w Javie 8 pozwala lepiej to zobaczyć i zapewnia narzędzia do obsługi.

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

Wtedy durationAtEarlierOffset będzie jedna sekunda, podczas durationAtLaterOffset będzie pięć minut i 53 sekundy.

Również te dwa przesunięcia są takie same:

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

Ale te dwa są różne:

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

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

Można zobaczyć ten sam problem porównując 1927-12-31 23:59:59 z 1928-01-01 00:00:00, jednak w tym przypadek, to wcześniejsze przesunięcie powoduje dłuższą rozbieżność, a wcześniejsza Data ma dwa możliwe przesunięcia.

Innym sposobem podejścia do tego jest sprawdzenie, czy nastąpi przejście. Możemy to zrobić tak:

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

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

Możesz sprawdzić, czy przejście jest nakładaniem się-w tym przypadku istnieje więcej niż jedno ważne przesunięcie dla danej daty / czasu-lub luka-w tym przypadku data / czas nie jest ważny dla identyfikatora strefy - za pomocą metod isOverlap() i isGap() na zot4.

Mam nadzieję, że pomoże to ludziom uporać się z tego typu problemami, gdy Java 8 stanie się powszechnie dostępna, lub tym, którzy używają Java 7, którzy przyjmują backport JSR 310.

IMHO wszechobecna, implicit lokalizacja w Javie jest jej największą wadą projektową. Może być przeznaczony dla interfejsów użytkownika, ale szczerze mówiąc, kto tak naprawdę używa Javy do interfejsów użytkownika dzisiaj z wyjątkiem Niektórych IDE, gdzie można w zasadzie ignorować lokalizację, ponieważ programiści nie są dokładnie grupą docelową dla niego. Możesz to naprawić (szczególnie na serwerach Linuksowych) przez:

• export LC_ALL=C TZ=UTC
• ustaw zegar systemowy NA UTC
• nigdy nie używaj zlokalizowanych implementacje, chyba że jest to absolutnie konieczne (ie for display only)

Do Java Community Process członków polecam:

• Aby metody zlokalizowane nie były domyślne, ale wymagały od użytkownika jawnego żądania lokalizacji.
• użyj UTF-8 / UTC jako naprawiono domyślne, ponieważ jest to po prostu domyślne dzisiaj. Nie ma powodu, aby robić coś innego, chyba że chcesz produkować takie wątki.

I mean, come on, are ' T globalne zmienne statyczne wzorzec anty-OO? Nic innego nie jest te wszechobecne wartości domyślne podane przez niektóre podstawowe zmienne środowiskowe.......