Почему java.time.Instant не показывает дополнительных секунд?

Изменить ниже с резюме ответа:

Я пытаюсь немного больше понять о java.time.Instant и дополнительных секундах. Если я запускаю это:

System.out.println(Instant.ofEpochSecond(60*60*24*365*50));

Я рассчитывал создать дату/время, близкие к началу 2020 года, то есть 50 лотов по 365 дней после 1 января 1970 года, так что с учетом нескольких високосных лет на несколько дней меньше. Я действительно получаю такую ​​дату. Все идет нормально.

Дата/время, которые я получаю, отображаются как 2019-12-20T00:00:00Z. Что меня удивило, так это то, что я думал, что результат также будет на несколько секунд меньше полуночи из-за високосных секунд. Но сейчас ровно полночь по Гринвичу.

Я неправильно понимаю високосные секунды или java.time.Instant (или, возможно, что-то совсем другое!)?

РЕДАКТИРОВАТЬ: как отметили комментаторы, время Java не требуется для каких-либо действий с дополнительными секундами, вероятно, потому, что время Unix их игнорирует, и причина этого указана в статье Википедии и косвенно через другой вопрос. Суть в том, что будущие високосные секунды непредсказуемы, но добавляются, когда астрономы соглашаются, что Земля замедлилась достаточно, чтобы это оправдать. И кажется, что это замедление непредсказуемо.

Обратите внимание: я не удалил свой вопрос, поскольку связь между временем Unix и временем java не упоминается в вопросе, на который ссылались другие, поэтому я считаю, что это добавляет некоторые небольшие достоинства.

Спасибо за отзыв!


person Toby Eggitt    schedule 26.10.2020    source источник
comment
Отвечает ли это на ваш вопрос? время Unix и дополнительные секунды - Википедия также объясняет это: en.wikipedia.org/wiki/Unix_time — в основном время Unix игнорирует дополнительные секунды.   -  person CryptoFool    schedule 26.10.2020
comment
Как говорится в документации: Таким образом, реализациям не требуется фактически выполнять поворот UTC-SLS или иным образом знать о високосных секундах.   -  person Andy Turner    schedule 26.10.2020
comment
О, вау, да, это имеет смысл. Кажется удивительным, что такой сложный и, казалось бы, мощный API не смог реализовать это в своей эталонной форме. Но я думаю, что то, что мы не знаем о будущих дополнительных секундах, является хорошим объяснением.   -  person Toby Eggitt    schedule 26.10.2020
comment
Кроме того, обычные компьютерные часы не знают високосных секунд, поэтому (1) у вас все равно не будет точности (2) вам потребуется специальная логика для преобразования между компьютерными часами и текущим моментом вокруг високосных секунд. Мне кажется, что они сделали правильный выбор.   -  person Ole V.V.    schedule 26.10.2020
comment
Интересное наблюдение. Я рассматривал NTP как особую логику, поскольку она подталкивает часы, чтобы они отображали правильное дневное время, даже после того, как произошла дополнительная секунда. Но я понимаю, что мне нужно больше читать о вещах, лежащих в основе этого, поскольку мне ясно, что если мы просто добавим 86 400 секунд, умноженных на несколько тысяч дней, и добавим это время к полуночи UTC 1 января 1970 года, мы выиграем. т прийти в нужное время. Но я удовлетворен тем, что ни один алгоритм не может компенсировать непредсказуемые вещи в будущем, так что здесь не так уж много выбора.   -  person Toby Eggitt    schedule 29.10.2020
comment
Если вы действительно хотите измерять/вычислять секунды, включая високосные секунды, вы можете использовать мою библиотеку Time4J. О java.time Oracle не хочет его реализовывать и удалил данные из дистрибутива tzdb .   -  person Meno Hochschild    schedule 18.02.2021