Funkcja java System. currentTimeMillis() najwyraźniej zwraca liczbę sekund od 1 stycznia 1970. Jednak zgodnie z wikipedia.org/wiki/Leap_second, od 1972 roku było 25 sekund przestępnych. Oznacza to, że faktyczna liczba sekund od 1 stycznia 1970 r. Była o 25 większa niż sugerowałyby naiwne obliczenia. Czy System. currentTimeMillis() wykonaj obliczenia naiwne i zignoruj sekundy przestępne?Czy w systemie Java milisekundy uwzględniają sekundy przestępne?
Oficjalnie zależy od systemu operacyjnego i implementacji - przynajmniej dla wersji Date. Od docs java.util.Date:
Chociaż klasa Date ma odzwierciedlać skoordynowanego czasu uniwersalnego (UTC), to nie może to zrobić dokładnie, w zależności od środowiska przyjmującym Java Virtual Machine. Prawie wszystkie współczesne systemy operacyjne zakładają, że 1 dzień = 24 × 60 × 60 = 86400 sekund we wszystkich przypadkach. W UTC jednak raz na rok lub dwa jest dodatkowa sekunda, nazywana "sekundą przestępną". Sekundowa sekunda jest zawsze dodawana jako ostatnia sekunda dnia i zawsze 31 grudnia lub 30 czerwca. Na przykład ostatnia minuta roku 1995 miała 61 sekund, dzięki dodatkowemu sekundowemu skokowi. Większość zegarów komputerowych nie jest wystarczająco dokładna, aby odzwierciedlać rozróżnienie sekund przestępnych.
Podejrzewam, przekonasz się, że chociaż zegar komputera jest z grubsza wyrównany do UTC, które jest zrobione poprzez NTP lub podobnego korygowania zegara okresowo, a nie systemu operacyjnego naprawdę wykonawczego przestępnych sekund.
Uważam, że biblioteki JRE zazwyczaj do przyjąć 86400 drugi dzień. To sprawia, że życie jest o wiele prostsze, a jeśli masz zamiar poprawić niedokładny zegar systemowy, równie dobrze możesz poprawić sekundy przestępne w ten sposób.
Naprawdę chcesz dowiedzieć się, co cię interesuje. Jeśli potrzebujesz sposobu reprezentowania dat i czasów, które wykorzystują sekundy przestępne, standardowe biblioteki Java mogą nie działać dobrze. Nawet JSR-310 nie obsługuje już sekund przestępnych, o ile wiem (co jest bardzo rozsądną decyzją dla większości programistów).
Zrobiłem kilka testów na systemach Android 4.2 i Windows 7, a System.currentTimeMillis() był rzeczywiście liczbą milisekund od 1 stycznia do 1970 r. Przy założeniu, że każdy dzień ma dokładnie 86400 sekund. Rzeczywiście, sekundy przestępne są ignorowane, ale jak mówisz komputery pokazują właściwy czas (włączając sekundy przestępne), ponieważ ich zegary są okresowo poprawiane :-). – Stochastically
@Stochastycznie: test jest zbyt słaby. Nie pokazuje, w jaki sposób system obsługuje sekundy przestępne (POSIX, Mills, smear, ntp, TAI (jeśli dane wejściowe to 1970TAI w tym ostatnim przypadku)). – jfs
Patrząc na Javadoc dla currentTimeMillis(), to referes do documentation of the Date class, co ma do powiedzenia:
Chociaż klasa Date ma odzwierciedlać uniwersalnym czasem koordynowanym (UTC), nie może zrobić więc dokładnie, w zależności od środowiska hosta wirtualnej maszyny Java. Prawie wszystkie współczesne systemy operacyjne zakładają, że 1 dzień = 24 × 60 × 60 = 86400 sekund we wszystkich przypadkach. W UTC jednak raz na rok lub dwa jest dodatkowa sekunda, nazywana "sekundą przestępną". Sekundowa sekunda jest zawsze dodawana jako ostatnia sekunda dnia i zawsze 31 grudnia lub 30 czerwca. Na przykład ostatnia minuta roku 1995 miała 61 sekund, dzięki dodatkowemu sekundowemu skokowi. Większość zegarów komputerowych nie jest wystarczająco dokładna, aby odzwierciedlać rozróżnienie sekund przestępnych.
Aby odpowiedzieć na pytanie: Tak, uwzględniane są sekundy przestępne.
Ale myślę, że oznacza to, że należy wyciągnąć wniosek, że "sekundy przestępne NIE są uwzględniane", tj. Ignorowane, ponieważ systemy operacyjne przyjmują 86400 sekund dziennie. – Stochastically
Sposób, w jaki to rozumiem: konta UTC dla sekund przestępnych. Łączenie strefy czasowej w nowoczesnym systemie operacyjnym uwzględnia różnicę czasu między czasem UTC a czasem lokalnym (i być może DST, w zależności od zastosowania). Alternatywą byłoby, że każdy odstąpił 35 sekund (Źródło: Wikipedia) od UTC od początku czasu Unix. – 0xCAFEBABE
Myślę, że masz rację, UTC odpowiada za sekundy przestępne. Jednak moim wnioskiem jest, że te sekundy przestępne NIE są zawarte w System.currentTimeMillis(), jak opisałem w swoim komentarzu do odpowiedzi, którą zaznaczyłem jako "odpowiedź". – Stochastically
POSIX wymaga, aby zegar systemowy nie dopuszczał istnienia sekund przestępnych. MS Windows nie może zagwarantować jakości (ani istnienia) zegara systemowego, a także ma zagwarantowaną 1-sekundową dokładność. Java nie może z łatwością zrobić niczego, czego system bazowy odmawia.Systemy operacyjne są hamowane przez historię international regulations, co skutkuje jednym standardem IEEE (PTP), który wymaga sekund przestępnych i innego (POSIX), który je odrzuca.
Jednym z łatwych sposobów sprawdzenia, czy sekundy przestępne są uwzględniane, jest obliczenie liczby sekund, które upłynęły od Epoki do 00:00 w danym dniu w bieżącym roku.
Jeśli ta liczba sekund jest zgodna z 00 modulo 60, to sekundy przestępne nie są uwzględniane, ponieważ w 2013 roku powinieneś mieć moduł 25 (dla ostatnich 25 sekund przestępnych).
Zrobiłem mały eksperyment na javarepl:
java> new Date(1000L * 86400 * (365 * 4 + 1) * 12)
java.util.Date res0 = Mon Jan 01 00:00:00 UTC 2018
Jak widać, proste „naiwne” arytmetyki, że właśnie chodzi roku przestępnym, ale nie skoczyć sekund, jest używana. Żadne dodatkowe sekundy nie są dodawane ani odejmowane.
Aktualizacja:
samo dla nowej Instant klasy:
java> Instant.ofEpochMilli(1000L * 86400 * (365 * 4 + 1) * 12)
java.time.Instant res0 = 2018-01-01T00:00:00Z
FYI, klasa 'Date' jest teraz starsza, wyparta przez klasy java.time wbudowane w Javę 8 i nowsze. W szczególności klasa 'Instant' zastępuje' Date'. –
@BasilBourque, dziękuję! Czy jest to w jakiś sposób związane z kwestią sekund przestępnych? – Alexey
To byłoby dość łatwe do sprawdzenia. –
@RobertHarvey: To prawda, ale to tylko powiedzieć coś o _ tej wersji JVM na _to_ OS. Dobrze jest zapytać, czy normy gwarantują cokolwiek. – sleske