Как получить международное атомное время в Java 7

Я работаю над проектом Java7, и нам нужна метка времени в международном атомном времени. Я нашел несколько других вопросов, касающихся JSR-310 и ThreeTen Project (который реализует 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 указан в JavaDoc ThreeTen SourceForge в разделе javax.time.TAIInstant).

Для полноты, это отрывок из моего pom.xml:

<dependency>
  <groupId>org.threeten</groupId>
  <artifactId>threetenbp</artifactId>
  <version>0.8.1</version>
</dependency>

Следует ли мне использовать что-то еще и где мне это взять?

Примечание: извините, я не могу предоставить ссылки на все страницы, о которых я говорю, StackOverflow не позволит мне иметь> 2 ссылки на сообщение без более высокой репутации.

[EDIT] Причина, по которой я хочу использовать TAI, заключается в том, что мне нужна временная метка, которая монотонно увеличивается, что, как я считаю, выполняет TAI (даже в течение как положительных, так и отрицательных дополнительных секунд, поскольку все равно about високосных секунд считает все секунды одинаково, включая високосные секунды).

Прочитав о времени POSIX / Unix из различных источников, мне все еще не ясно, что именно происходит в Unix Time за дополнительную секунду. Я знаю, что Unix Time неоднозначно относится к UTC, но я не понимаю, что происходит в Unix Time в тот момент, когда возникает дополнительная секунда? Например, Unix Time "приостанавливает" или уходит назад? И, что, возможно, более важно, даже если это не должно соответствовать спецификации Unix Time, действительно ли реализации Unix подчиняются спецификации в отношении дополнительных секунд ...?

Наконец, правильно ли я говорю, что System.currentTimeMillis () получит эквивалент времени POSIX (хотя и в миллисекундах, а не в секундах)?

Обратите внимание: мне нужен объект, который можно переносить между JVM и машинами (исключая System.nanoTime () или аналогичный).

[ЗАКЛЮЧЕНИЕ]

TAI
TAI - это система измерения времени, в которой считается каждая секунда и «все секунды равны», т. е. каждая секунда состоит из одного и того же периода времени, и все секунды (включая дополнительные секунды) считаются в сумме. Это означает, что количество секунд в TAI (отсчитываемое от произвольной начальной точки, например, Unix Epoch) является монотонно увеличивающимся целым числом.

POSIX Time
POSIX Time - это стандарт (НЕ реализация) для измерения времени. Он определяет каждый день как имеющий ровно 86400 секунд. Следовательно, время POSIX не учитывает дополнительные секунды (поскольку иногда в минуте может быть 61 секунда, что приводит к дням с> 86400 секунд, а теоретически в минуте может быть 59 секунд, что приводит к дням с ‹86400 секунд). Это означает, что «секунды» в POSIX имеют переменную длину, и незадолго до / во время / после дополнительных секунд часы POSIX могут пропускать секунды или повторять их. В частности, спецификация POSIX, на которую ссылается Мено Хохшильд в своем ответе, гласит: «Связь между фактическим временем дня и текущим значением в секундах с начала эпохи не указана».

UTC
UTC - это стандарт времени, который связан с тем, как Земля движется вокруг Солнца, с целью поддержания взаимосвязи между положением Солнца и временем дня (в пределах порогового значения). ). То есть в регионе Земли по Гринвичу + 0 Солнце всегда находится на максимуме в полдень по всемирному координированному времени. Дополнительные секунды (положительные или отрицательные) необходимы, потому что скорость вращения Земли не фиксирована и не изменяется предсказуемым образом (это означает, что мы не можем предсказать, когда потребуются дополнительные секунды - или будут ли они положительными секундами прыжка или отрицательные високосные секунды)

Представление времени
Мне кажется, что и TAI, и POSIX представляют собой «количество секунд» (то есть что-то, что на самом деле легко для компьютера), тогда как UTC - это «человеческая интерпретация. времени (например, год / месяц / день, час: минута: секунда, миллисекунда), которое обычно не сохраняется внутри компьютера.

Перевод времени
Учитывая вышеизложенное, существует ряд проблем с переводом из POSIX (без подсчета дополнительных секунд) в TAI (с подсчетом дополнительных секунд):

  1. Требуется ведение таблицы / количества дополнительных секунд для перевода любого времени POSIX во время TAI.
  2. Даже если рассматривается пункт 1, спецификация POSIX, как указано выше, не дает никаких гарантий относительно того, что произойдет в течение секунды координации, поэтому в такие моменты у нас нет способа точно представить однозначное время.
  3. Если несколько систем должны обмениваться данными, передавая между ними временные метки, мы должны гарантировать, что таблица / количество дополнительных секунд поддерживаются согласованными.

С другой стороны, легко преобразовать POSIX в «человеческую интерпретацию» UTC. Для этого не требуется знание дополнительных секунд, поскольку предполагается, что каждый день имеет одинаковое количество секунд (хотя в действительности некоторые из этих «секунд» имеют разную продолжительность времени). На практике вы просто использовали бы формулу, обратную формуле в спецификации POSIX, чтобы получить различные компоненты времени в формате UTC (опять же, см. Спецификацию POSIX, на которую ссылается Мено Хохшильд).


person asibs    schedule 23.12.2013    source источник
comment
Поправили и объяснили подробнее. Надеюсь, поможет.   -  person Meno Hochschild    schedule 30.12.2013


Ответы (2)


JSR-310-backport поддерживает только функции, которые будут включены в Java 8. TAI (и истинное UTC) не будет поддерживаемой функцией, поэтому он не может быть в backport. Единственной альтернативой было бы попробовать threeten-extra-project, который содержит класс TAIInstant, но весь дополнительный проект может быть устаревшим (очень старый код).

Я сам работаю над своей библиотекой Time4J, которая имеет поддержку TAI, GPS и UTC в дополнение к POSIX.

[ОБНОВЛЕНИЕ от июля 2014 г.: Time4J теперь доступен как стабильный выпуск time4j-v1.0. Это обсуждение было принято во внимание - см., Например, Moment.toString (TimeScale).]


Исправление и подробные замечания к недавно опубликованным вопросам OP:

a) Да, 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-form, ни на уровне epoch-secs-level. Итак, наконец, у нас нет фиксированной связи между TAI и POSIX. Для преобразования требуется таблица секунды координации.

c) Что говорит спецификация POSIX о поведении секунды координации? См. здесь. Особо обратите внимание на утверждение: «Связь между фактическим временем дня и текущим значением в секундах, так как Эпоха не указана». Так что это касается и дополнительной секунды. Реализация часов зависит от того, прыгают ли они до секунды координации или после нее, или замирают на одну секунду.

г) Да, System.currentTimeMillis() получит эквивалент времени POSIX (хотя и в миллисекундах, а не в секундах).

д) Отметим, что метка TAI не была определена до 1971 года, а Международное атомное время - не ранее 1958 года, поэтому пролептическая шкала TAInstant с тремя десятками классов в некотором роде бессмысленна. Так что я не стал бы применять TAI до 1972 года. Здесь я иду со Стивом Алленом, экспертом по временным шкалам.

f) Если вам нужен объект времени, который «переносится между JVM и машинами», то сам UTC требует распространения / существования одной и той же таблицы секунды координации повсюду. Если вы выберете TAI, вам все равно понадобится эта таблица дополнительных секунд, чтобы позволить приложениям преобразовывать метки времени TAI в метки времени UTC или POSIX. Поэтому я сомневаюсь, что вы можете иметь монотонно увеличивающуюся метку времени и одновременно игнорировать дополнительные секунды. TAI не предлагает решения этой дилеммы.

Ответы на вопрос / сводка ОП от 31 декабря 2013 г .:

Ваши выводы о TAI и POSIX верны.

Что касается UTC, вы, прежде всего, должны понимать, что UTC - это компромисс. С одной стороны, он разработан так, чтобы следовать за солнцем, с другой стороны, вторая по шкале UTC точно такая же, как по шкале TAI, а именно SI-секунда (атомарное определение). Вы правы, когда заявили, что скорость вращения Земли непредсказуемо замедляется, поэтому несколько раз добавляются дополнительные секунды. Разница между UT1 (средним солнечным временем) и UTC всегда должна быть меньше 0,9 секунды СИ. Таким образом, это и факт равных секунд SI являются ключевыми идеями UTC. Кроме того, адаптация экзотической шкалы UTC-SLS в JSR-310 несовместима с этими основными идеями UTC. Что касается предсказуемости дополнительных секунд, то BIPM в Париже каждые полгода объявляет, будет ли через 6 месяцев дополнительная дополнительная секунда или нет, поэтому у вас есть эта структура предсказуемости на шесть месяцев вперед.

Одно, возможно, педантичное исправление относительно секции 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 в моей библиотеке. Спасибо.

person Meno Hochschild    schedule 23.12.2013
comment
Спасибо за информацию. Мне нужно монотонно увеличивающееся время, чтобы несколько событий, разделенных на несколько миллисекунд, всегда имели уникальные временные метки (даже если задействованы дополнительные секунды). Кажется, что страница Википедии для времени POSIX не будет монотонно увеличиваться при наличии високосные секунды (в примере с 1 января 99 г. повторяются временные метки). Таким образом, это может указывать на то, что я не могу просто добавить x секунд в POSIX для получения TAI (по крайней мере, во время событий дополнительной секунды)? Или я что-то недопонимаю? - person asibs; 30.12.2013
comment
Если вам действительно нужно учитывать високосные секунды, то TAI вам не подходит. Затем вам понадобится UTC и таблица дополнительных секунд в фоновом режиме, чтобы получить монотонно увеличивающееся время с учетом дополнительных секунд. TAI предназначен только для научных лабораторных целей, а не для гражданской жизни, которая требует UTC. - person Meno Hochschild; 30.12.2013
comment
Еще раз спасибо, я отредактировал исходный вопрос, который, надеюсь, проясняет ситуацию, главное, в чем я сейчас не уверен, касается POSIX / Unix Time - если мы сможем (и всегда сможем) сгенерировать TAI из Unix Time с помощью вычитая 10, время Unix также должно монотонно увеличиваться. Если это правда, то если я постоянно вызываю date +% s из командной строки или System.currentTimeMillis () из Java и т. Д. В течение секунды координации (положительной или отрицательной), тогда я никогда не увижу, что эта временная метка переместится назад ... Прав ли я в этом предположении или я неправильно понял? - person asibs; 30.12.2013
comment
Еще раз спасибо, я добавил заключение к вопросу, резюмировав основные моменты и мое текущее понимание ... Не могли бы вы прочитать и сообщить мне, согласны / не согласны с этим выводом? Затем я отмечу ваш ответ как принятый (просто хочу сначала убедиться, что я правильно его истолковал!) - person asibs; 31.12.2013
comment
@ user2710331 ответил на ваши последние вопросы, с Новым годом! - person Meno Hochschild; 31.12.2013

Класс TAIInstant и другие подобные UTCInstant были удалены во время процесса JSR-310. Группа пришла к выводу, что это специальные предметы, и они не обязательно должны быть в основном JDK. Я до сих пор считаю, что это правильное решение.

Результатом этого является то, что в JSR-310 очень мало поддержки шкал времени. Однако существует формально определенный способ подключения JSR-310 к шкалам времени, позволяющий создавать точные часы при наличии точного источника. Хотя не всем нравится это решение, оно практично для массового потребителя.

Таким образом, первоначальный дизайн отдельных классов для UTC и TAI является правильным (и необходим для обработки событий в прошлом и будущем). Однако для JDK он был слишком специализирован.

Проект threeten-extra теперь доступен как jar для JDK 8 с эти классы в.

person JodaStephen    schedule 25.12.2013