Dlaczego odejmowanie tych dwóch razy (w 1927 r.) Daje dziwny wynik?

Jeśli uruchomię następujący program, który analizuje dwa ciągi dat odnoszące się do odstępów co 1 sekundę i porównuje je:

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

Dane wyjściowe to:

353

Dlaczego ld4-ld3nie jest 1(jak bym się spodziewał po jednosekundowej różnicy czasów), ale 353?

Jeśli zmienię daty na czasy 1 sekundę później:

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

Wtedy ld4-ld3będzie 1.

Wersja Java:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

To zmiana strefy czasowej 31 grudnia w Szanghaju.

Zobacz tę stronę, aby poznać szczegóły 1927 roku w Szanghaju. Zasadniczo o północy pod koniec 1927 r. Zegary cofnęły się o 5 minut i 52 sekund. Tak więc „1927-12-31 23:54:08” faktycznie wydarzyło się dwa razy i wygląda na to, że Java analizuje go jako późniejszy możliwy moment dla tej lokalnej daty / godziny - stąd różnica.

Kolejny odcinek w często dziwnym i cudownym świecie stref czasowych.

EDYCJA: Przestań naciskać! Historia się zmienia ...

Pierwotne pytanie nie wykazywałoby już takiego samego zachowania, gdyby zostało przebudowane z wersją TZDB 2013a . W 2013a wynik wynosiłby 358 sekund, a czas przejścia to 23:54:03 zamiast 23:54:08.

Zauważyłem to tylko dlatego, że zbieram takie pytania w Czasie Nody, w formie testów jednostkowych ... Test został teraz zmieniony, ale po prostu pokazuje - nawet dane historyczne nie są bezpieczne.

EDYCJA: Historia znów się zmieniła ...

W TZDB 2014f czas zmiany przesunął się do 1900-12-31, a teraz jest to zaledwie 343 sekundowa zmiana (więc czas pomiędzy ti t+1wynosi 344 sekundy, jeśli rozumiesz, co mam na myśli).

EDYCJA: Aby odpowiedzieć na pytanie związane z przejściem o 1900 ... wygląda na to, że implementacja strefy czasowej Java traktuje wszystkie strefy czasowe po prostu w swoim standardowym czasie dla dowolnej chwili przed rozpoczęciem 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);
            }
        }
    }
}

Powyższy kod nie generuje danych wyjściowych na moim komputerze z systemem Windows. Tak więc każda strefa czasowa, która ma dowolne przesunięcie inne niż standardowe na początku 1900 r., Będzie to traktować jako przejście. Sam TZDB ma pewne wcześniejsze dane i nie opiera się na żadnej idei „ustalonego” standardowego czasu (który getRawOffsetzakłada, że ​​jest to poprawna koncepcja), więc inne biblioteki nie muszą wprowadzać tego sztucznego przejścia.

Wystąpiła nieciągłość czasu lokalnego :

Kiedy lokalny czas standardowy miał wkrótce nadejść w niedzielę, 1 stycznia 1928 r., 00:00:00 zegary zostały cofnięte o 0:05:52 godziny do soboty 31 grudnia. Zamiast tego 31 grudnia 1927 r., 23:54:08 czasu lokalnego

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

Morał tej dziwności jest następujący:

• W miarę możliwości używaj dat i godzin w UTC.
• Jeśli nie możesz wyświetlić daty lub godziny w UTC, zawsze wskaż strefę czasową.
• Jeśli nie można wymagać wprowadzenia daty / godziny w UTC, należy podać wyraźnie wskazaną strefę czasową.

Przy zwiększaniu czasu powróć do UTC, a następnie dodaj lub odejmij. Użyj czasu lokalnego tylko do wyświetlenia.

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

Jeśli dokonałeś konwersji na UTC, dodaj każdą sekundę i przekonwertuj na czas lokalny do wyświetlenia. Przechodziłbyś przez 11:54:08 pm LMT - 11:59:59 pm LMT, a następnie 23:54:08 CST - 23:59:59 CST.

Zamiast konwertować każdą datę, możesz użyć następującego kodu:

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

A potem przekonaj się, że wynikiem jest:

1

Przykro mi to mówić, ale nieciągłość czasu trochę się zmieniła

JDK 6 dwa lata temu, aw JDK 7 niedawno w aktualizacji 25 .

Lekcja do nauczenia się: za wszelką cenę unikaj czasów poza UTC, z wyjątkiem może wyświetlania.

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

Ta niewielka zmiana przesunięć, zamiast zwykłej jednogodzinnej oszczędności światła dziennego (czasu letniego), do której jesteśmy przyzwyczajeni, nieco zaciemnia problem.

Należy zauważyć, że aktualizacja bazy danych strefy czasowej 2013a przesunęła tę nieciągłość kilka sekund wcześniej, ale efekt byłby nadal widoczny.

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

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

Następnie durationAtEarlierOffsetbędzie jedną sekundę, natomiast durationAtLaterOffsetbędzie pięć minut i 53 sekund.

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żesz zobaczyć ten sam problem w porównaniu 1927-12-31 23:59:59z tym 1928-01-01 00:00:00, jednak w tym przypadku to wcześniejsze przesunięcie powoduje dłuższe rozbieżności i wcześniejsza data ma dwa możliwe przesunięcia.

Innym sposobem podejścia do tego jest sprawdzenie, czy zachodzi przejście. Możemy to zrobić w następujący sposób:

// 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 pokrywające się, gdy istnieje więcej niż jedno prawidłowe przesunięcie dla tej daty / godziny, czy przerwa, w której ta data / czas nie jest ważna dla tego identyfikatora strefy - przy użyciu metod isOverlap()i .isGap()zot4

Mam nadzieję, że pomoże to ludziom poradzić sobie z tego rodzaju problemami, gdy Java 8 stanie się powszechnie dostępna, lub osobom używającym Java 7, które przyjmą backport JSR 310.

IMHO wszechobecna, domyślna lokalizacja w Javie jest jej największą pojedynczą wadą projektową. Może być przeznaczony dla interfejsów użytkownika, ale szczerze mówiąc, kto tak naprawdę używa Java dla interfejsów użytkownika, z wyjątkiem niektórych IDE, w których można w zasadzie zignorować lokalizację, ponieważ programiści nie są dokładnie docelowymi odbiorcami. Możesz to naprawić (szczególnie na serwerach Linux):

• eksport LC_ALL = C TZ = UTC
• ustaw zegar systemowy na UTC
• nigdy nie używaj zlokalizowanych implementacji, chyba że jest to absolutnie konieczne (tj. tylko do wyświetlania)

Do Java Community Process członków Polecam:

• ustaw metody zlokalizowane na inne niż domyślne, ale wymagają, aby użytkownik wyraźnie zażądał lokalizacji.
• zamiast tego użyj UTF-8 / UTC jako domyślnego NAPRAWIONEGO, ponieważ dzisiaj jest to po prostu domyślny. Nie ma powodu, aby robić coś innego, chyba że chcesz produkować takie wątki.

Chodzi mi o to, czy globalne zmienne statyczne nie są wzorcem anty-OO? Nic więcej nie jest wszechobecnymi wartościami domyślnymi podanymi przez niektóre podstawowe zmienne środowiskowe .......

Jak powiedzieli inni, to zmiana czasu w 1927 r. W Szanghaju.

Kiedy był 23:54:07w Szanghaju, czas lokalny standardowy, ale po 5 minutach i 52 sekundach zmienił się na następny dzień o godzinie 00:00:00, a potem czas lokalny standardowy zmienił się z powrotem na 23:54:08. Dlatego różnica między tymi dwoma czasami wynosi 343 sekundy, a nie 1 sekundę, jak można się spodziewać.

Czas może również popsuć się w innych miejscach, takich jak USA. USA mają czas letni. Kiedy zaczyna się czas letni, czas przesuwa się o 1 godzinę do przodu. Ale po pewnym czasie kończy się czas letni i wraca o 1 godzinę wstecz do standardowej strefy czasowej. Czasami więc przy porównywaniu czasów w USA różnica wynosi około 3600sekund, a nie 1 sekundy.

Ale w tych dwóch zmianach czasu jest coś innego. Ten drugi zmienia się ciągle, a ten pierwszy był tylko zmianą. Nie zmieniło się ani nie zmieniło o tę samą kwotę.

Lepiej jest używać UTC, gdy czas się nie zmienia, chyba że jest to konieczne, aby użyć czasu innego niż UTC, jak na wyświetlaczu.