Как получить Международное атомное время в Java 7
Я работаю над проектом Java7, и нам нужна временная метка в Международном атомном времени. Я нашел несколько других вопросов, касающихся этого, которые указывают на JSR-310 и проект ThreeTen (который реализует JSR-310):
Как узнать время GPS и время TAI на Java?
http://www.coderanch.com/t/549178/java/java/TAI-Atomic-Time-International
Тем не менее, я изо всех сил пытаюсь выяснить, что именно использовать для Java 7 и где его взять. Похоже, есть старые страницы SourceForge и GitHub для ThreeTen, а также страница OpenJDK.
Я нашел бэкпорт Java 7, но после загрузки этого из Maven он не включает класс TAIInstant, который мне действительно нужен (класс TIAInstant указан в ThreeTen SourceForge JavaDoc, в javax.time.TAIInstant).
Для полноты, это отрывок из моего pom.xml:
<dependency>
<groupId>org.threeten</groupId>
<artifactId>threetenbp</artifactId>
<version>0.8.1</version>
</dependency>
Должен ли я использовать что-то еще, и где я должен получить это?
Примечание: извините, я не могу предоставить ссылки на все страницы, на которые я ссылаюсь, Stackru не позволит мне иметь> 2 ссылки на пост без более высокой репутации.
[РЕДАКТИРОВАТЬ] Причиной желания TAI является то, что мне нужна временная метка, которая монотонно увеличивается, и я считаю, что TAI выполняет (даже в течение положительных и отрицательных високосных секунд, так как он не заботится о високосных секундах, которые равны всем секундам, включая прыжок секунд).
Прочитав о времени POSIX / Unix из разных источников, мне все еще не ясно, что именно происходит в Unix Time за одну секунду. Я знаю, что время Unix неоднозначно в отношении времени UTC, но мне не ясно, что происходит в Unix Time в тот момент, когда происходит скачок секунды? Unix Time "останавливается" или идет назад, например? И, возможно, что еще более важно, даже если это не должно соответствовать спецификации Unix Time, действительно ли реализации Unix подчиняются спецификации в отношении високосных секунд...?
Наконец, правильно ли я сказал, что System.currentTimeMillis() получит эквивалент POSIX Time (хотя и в миллисекундах, а не в секундах)?
Обратите внимание, мне нужен объект, который переносим между JVM и машинами (исключая System.nanoTime() или аналогичный).
[ЗАКЛЮЧЕНИЕ]
TAI
TAI - это система измерения времени, где каждая секунда отсчитывается и "все секунды равны", т.е. каждая секунда состоит из одного и того же периода времени, и все секунды (включая високосные секунды) учитываются в общем количестве. Это означает, что количество секунд в TAI (отсчитываемое от некоторой произвольной начальной точки, например, эпохи Unix) является монотонно возрастающим целым числом.
Время POSIX
POSIX Time - это стандарт (НЕ реализация) для измерения времени. Каждый день определяется как 86400 секунд. Следовательно, время POSIX не учитывает високосных секунд (поскольку иногда у минуты может быть 61 секунда, что приводит к дням с>86400 секундами, а теоретически минута может иметь 59 секунд, что приводит к дням с <86400 секундами). Это означает, что "секунды" в POSIX имеют переменную длину, и незадолго до / во время / после високосных секунд часы POSIX могут пропускать секунды или повторять их. В частности, спецификация POSIX, на которую ссылается Мено Хохшильд в своем ответе, гласит: "Связь между фактическим временем дня и текущим значением в секундах с начала эпохи не указана".
универсальное глобальное время
UTC - это стандарт времени, который связан с тем, как Земля движется вокруг Солнца, с целью поддержания взаимосвязи между положением Солнца и временем суток (в пределах порога). Т.е. в области UTC+0 Земли Солнце всегда находится на самом высоком уровне в полдень по UTC. Дополнительные секунды (положительные или отрицательные) необходимы, потому что скорость вращения Земли не фиксирована и не изменяется предсказуемым образом (то есть мы не можем предсказать, когда будут необходимы дополнительные секунды - или будут ли они положительными дополнительными секундами или отрицательные високосные секунды)
Представляющие времена
Мне кажется, что и TAI, и POSIX представляют собой "количество секунд" (то есть что-то, что компьютер легко может сохранить), тогда как UTC - это "человеческая интерпретация" времени (т. Е. Год / месяц / час): Минута:Second.millisecond), которая обычно не хранится внутри компьютера.
Перевод времени
Учитывая вышесказанное, существует ряд проблем, связанных с переводом из POSIX (без учета количества високосных секунд) в TAI (со счетом високосных секунд):
- Требуется ведение таблицы / количества високосных секунд для перевода любого времени POSIX во время TAI.
- Даже если точка 1 адресована, спецификация POSIX, как указано выше, не дает никаких гарантий относительно того, что произойдет в течение високосной секунды, поэтому в такие моменты у нас нет возможности точно представить однозначное время.
- Если несколько систем должны обмениваться данными, передавая временные метки между ними, мы должны гарантировать, что таблица / количество високосных секунд поддерживается постоянным
С другой стороны, из POSIX в UTC легко перевести "человеческую интерпретацию". Он не требует знания високосных секунд, поскольку предполагает, что каждый день имеет одинаковое количество секунд (хотя некоторые из этих "секунд" в действительности имеют разную продолжительность). На практике вы просто использовали бы обратную формулу в спецификации POSIX, чтобы получить различные компоненты времени UTC (опять же, смотрите спецификацию POSIX, на которую ссылается Мено Хохшильд).
2 ответа
JSR-310-backport поддерживает только функции, которые будут включены в Java 8. TAI (и истинный UTC) не будет поддерживаемой функцией, поэтому он не может быть в бэкпорте. Единственной альтернативой может быть попытка добавить три проекта extra-project, которые содержат класс TAIInstant, но весь дополнительный проект может быть устаревшим (очень старый код).
Я сам работаю над своей библиотекой Time4J, которая имеет поддержку TAI, GPS и UTC в дополнение к POSIX.
[ОБНОВЛЕНИЕ с июля 2014 года: Time4J теперь доступен как стабильный выпуск time4j-v1.0. Эта дискуссия была принята во внимание - см., Например, Moment.toString (TimeScale).]
Исправление и подробные замечания к вновь опубликованным вопросам ОП:
а) Да, TAI монотонно увеличивается в единицах СИ-секунд даже в течение високосных секунд. Если это только то, что вы хотите, вы можете выбрать TAI, но есть ловушка. Если вы хотите описать гражданские временные метки, то TAI даст вам неправильные временные метки (просто сравните первый и второй столбец диаграммы Википедии). Причина в том, что гражданская жизнь управляется UTC, а не TAI.
б) Что касается моих комментариев о том, что диаграмма Википедии неверна, я снова внимательно посмотрел на нее и передумал. Связь между POSIX и TAI не является фиксированной (смещение 10 с только в 1972 году), поэтому, пожалуйста, извините мою ошибку. До сих пор я не столько думал о TAI, сколько о POSIX и UTC. Но спасибо за вопрос и эту полезную дискуссию, так что вы заслуживаете моего одобрения. Все это сложно. Когда мы говорим о временных метках, представленных в разных временных масштабах, нам необходимо различать форму ymdhms и форму epochsecs. Рассмотрим это подробно для времени 1999-01-01T00:00:00Z (в масштабе UTC):
i) TAI = (29 * 365 + 7) days * 86400 + 22 leap seconds + 10s (offset at 1972) = 915148832
ii) UTC = TAI - 10 = 915148822 (fixed relation between UTC and TAI on epoch-second-level)
iii) POSIX = UTC - 22 leap seconds = 915148800
=> (ymdhms-form);
i) TAI (915148800 + 32) = 1999-01-01T00:00:32 (based on TAI-"day" = 86400 SI-secs)
ii) UTC = 1999-01-01T00:00:00 (stripped off former 22 leap secs in conversion to ymdhms)
iii) POSIX = 1999-01-01T00:00:00 (fixed relation between UTC and POSIX with exception of leapsecs)
Так почему утверждение, что TAI не считает високосные секунды? Он не учитывает скачки в ymdhms-форме, но, конечно, считает их на втором уровне эпохи (требование монотонности!). А POSIX? Он вообще не учитывает високосных секунд, ни в форме ymdhms, ни на уровне epoch-secs. Итак, наконец, у нас нет фиксированной связи между TAI и POSIX. Для конвертации требуется таблица с високосной секундой.
c) Что спецификация POSIX говорит о поведении в високосном направлении? Смотрите здесь. Особо обратите внимание на утверждение: "Соотношение между фактическим временем дня и текущим значением в секундах с начала эпохи не определено". Так что это касается и високосной секунды. Это зависит от реализации часов, если они прыгают до високосной секунды или прыгают после или останавливаются на одну секунду.
г) да, System.currentTimeMillis() получит эквивалент времени POSIX (хотя и в миллисекундах, а не в секундах).
e) Следует отметить, что метка TAI не определена до 1971 года, а Международное атомное время - не раньше 1958 года, поэтому пролетептическая шкала трехступенчатого экстра-класса TAIInstant как-то бессмысленна. Так что я бы не стал применять TAI до 1972 года. Здесь я иду со Стивом Алленом, экспертом по шкале времени.
f) Если вам нужен объект времени, который "переносим между JVM и машинами", тогда сам UTC требует повсеместного распространения / существования одной и той же таблицы високосных секунд. Если вы выбираете TAI, вам все еще нужна эта таблица високосных секунд, чтобы позволить приложениям преобразовывать метки времени TAI в метки времени UTC или POSIX. Поэтому я сомневаюсь, что вы можете иметь монотонно увеличивающуюся временную метку и игнорировать високосные секунды одновременно. TAI не предлагает решения для этой дилеммы.
Ответы на вопрос / резюме ОП от 2013-12-31:
Ваши резюме о TAI и POSIX верны.
Что касается UTC, вы должны прежде всего понимать, что UTC - это компромисс. С одной стороны, он предназначен для следования за солнцем, с другой стороны, вторая по шкале UTC точно такая же, как по шкале TAI, а именно, SI-секунда (атомное определение). Вы правы, когда заявили, что скорость вращения Земли непредсказуемо замедляется, поэтому несколько секунд добавляются дополнительные секунды. Разница между UT1 (средним солнечным временем) и UTC всегда должна быть меньше 0,9 СИ-секунд. Так что это и факт равных секунд СИ являются основными идеями UTC. Кроме того, адаптация экзотической шкалы UTC-SLS в JSR-310 не совместима с этими основными идеями UTC. Что касается предсказуемости високосных секунд, то BIPM в Париже объявляет каждые полгода, если через 6 месяцев будет необходима високосная секунда или нет, так что у вас есть этот прогнозируемый период на шесть месяцев вперед.
Одна из, возможно, педантичных поправок в разделе UTC, вы написали: "Солнце всегда в самом разгаре в полдень по UTC". Аналогичное утверждение также дано в javadoc класса java.time.Instant относительно так называемой шкалы времени Java. Если оставить в стороне тот факт, что вы наверняка не хотели говорить, что положение солнца не зависит от вашего местного положения, оно даже не правильно на правильной долготе в полдень. Зачем? С астрономической / научной точки зрения вы должны сначала не забывать, что среднее солнечное солнечное время не совпадает с истинным местным солнечным временем, которое вы наблюдаете (просто давая ключевое слово "уравнение времени"). Кроме того, поскольку UTC по-прежнему основывается на атомном времени и использует атомное время для синхронизации, существует так называемая дельта-T-связь между UT1 и UTC. Эта дельта находится в пределах 0,9 с и регулярно публикуется IERS/BIPM в бюллетене B. Вам необходимо знать эту дельту, когда вы хотите получить реальное положение солнца и когда солнце самое высокое.
Раздел "Представление времени", на мой взгляд, слишком прост. Хорошо, мы можем сказать, что TAI и POSIX отсчитывают секунды, тогда как UTC скорее представлены в форме год / месяц / день /...-. Но мы действительно можем применить оба представления ко всем масштабам. Но нам нужно тщательно различать эти представления и тщательно продумывать, как конвертировать. Обратите внимание, что Википедия даже выбрала форму ymdhms для TAI на диаграммах. Что ж, компьютеры могут лучше всего хранить простые целые числа. И POSIX или TAI могут быть легко сохранены в этом формате. Но, как я уже говорил, интерпретация этих целых не всегда проста. В случае TAI вам даже нужна таблица с високосной секундой для преобразования в читаемую гражданскую форму ymdhms (либо UTC, либо POSIX).
Насчет следующего раздела "Перевод времени" я согласен с пунктами 1-3.
Ваше последнее утверждение: "С другой стороны, из POSIX в UTC" человеческую интерпретацию "легко перевести". прав, за исключением високосных секунд. Ну, я включил подходящий перевод между различными шкалами с моей приходящей библиотекой. Он имеет встроенную, но настраиваемую таблицу високосных секунд, и в будущем я также планирую использовать данные IANA-TZDB в качестве источника для такой таблицы.
В целом следует учитывать тот факт, что большинству разработчиков бизнеса не нужна такая большая точность. Большинство людей просто уравняют POSIX и UTC и, вероятно, будут удовлетворены любыми аппаратными решениями сглаживания в ОС Linux или на серверах Google NTP. Истинные UTC и TAI (то есть с учетом високосных секунд) требуют больше усилий. Таким образом, вы должны решить, нуждается ли ваша программная архитектура в научной точности.
И просто отметим, что JSR-310 официально не рассматривает очень широко распространенную шкалу POSIX, вместо этого они говорят, что их класс Instant по определению будет UTC-SLS (см. Также эту интересную дискуссию).
Наконец я изящен для этого обсуждения. Это также помогло мне прояснить мои мысли о TAI в моей библиотеке. Благодарю.
Класс TAIInstantи другие, как UTCInstant были удалены во время процесса JSR-310. Группа пришла к выводу, что это были предметы специалиста и не обязательно быть в центре JDK. Я все еще верю, что это правильное решение.
Результатом этого является то, что в JSR-310 очень мало поддержки шкал времени. Однако существует формально определенный способ подключения JSR-310 к шкалам времени, позволяющий создавать точные часы при точном источнике. Хотя не всем нравится это решение, оно практично для мейнстрима.
Таким образом, оригинальный дизайн отдельных классов для UTC и TAI является надежным (и необходимым для обработки событий в прошлом и будущем). Тем не менее, это был слишком специалист для JDK.
Проект threeten-extra теперь доступен в виде jar для JDK 8 с этими классами в.