Как физики и астрономы справляются с дополнительными секундами?

Меня смущают многочисленные противоречивые описания того, как учитываются дополнительные секунды UTC. Я понимаю, что в обычной практике существуют различные способы их обработки, и я видел множество формальных определений. Но кажется, что в научной практике они просто опускаются : не существует юлианского дня UTC (то есть нет значения JD (UTC)), соответствующего любому времени в течение дополнительной секунды, и такие вещи, как эфемериды, обычно не сообщаются для дополнительных секунд . Есть, конечно, события, которые происходят во время високосных секунд, но если кто-то хочет сослаться на время, в которое они происходят, он использует другую систему хронометража (например, UT1 или TT).

Это правильно? Это имеет смысл как способ приспособиться к двусмысленности, которую вносят дополнительные секунды, и фактически соответствует тому, как некоторые системы (например, POSIX ) реализуют их; но это не совсем соответствует определениям, которые я видел.

Это соответствует тому, как Ким Стэнли Робинсон справляется с марсианским «сдвигом во времени» : часы останавливаются в 24 земных часа и снова запускаются через 39 минут и 40 секунд.
Я думал об этом и пришел к выводу, что скачки секунд координации не учитываются в эфемеридах. Они существуют только для того, чтобы синхронизировать наши часы UTC с вращением Земли, то есть UT1.
@JoeH: Но, например , азимут в отчетах JPL для Плутона в Гринвиче изменяется между 30 июня 2012 г. 23:59:59.333 UTC и 01 июля 2012 г. 00:00:00.000 UTC в 2,5 раза больше, чем он изменяется в любой другой ближайший интервал «1» секунды: 0,0069 ° против 0,0028 °, что именно то, что можно было бы ожидать ((1 + 2/3)/(2/3)), если бы там была дополнительная секунда.
Я в тупике тогда. Извини.

Ответы (2)

Как вы знаете, астрономы используют для расчетов не UT, а юлианские дни (JD). После того, как расчет выполнен, полученный JD преобразуется обратно в UT, UTC или желаемый часовой пояс для информирования общественности.

Високосные секунды можно взять из исторических данных (например, NASA http://eclipse.gsfc.nasa.gov/SEhelp/deltat2004.html или US Navy ftp://maia.usno.navy.mil/ser7/deltat.data ) или если они недоступны, их можно рассчитать http://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html . Они обозначаются как ΔT.

Затем к JD добавляется ΔT, и это время называется JDE (Юлианский день эфемерид). Или, другими словами, JD рассчитывается из UT, а JDE рассчитывается из динамического времени (TD = UT + ΔT).

С начала 1990-х некоторые публикации, такие как Minor Planet Circulars (http://www.minorplanetcenter.net/iau/services/MPCServices.html), переименовали JDE в JDT, где T означает отношение к земному динамическому времени.

Вопрос касается соглашения, используемого при «обратном преобразовании» в UTC на этом последнем шаге. Похоже, что (а) JD(UTC) не распространяется на високосные секунды и что — возможно, как следствие (а) — данные обычно не сообщаются для високосных секунд. Что вдохновило на вопрос, так это взгляд на данные об эфемеридах JPL вокруг дополнительной секунды, представленные в UTC: они опускают дополнительную секунду и пропускают дополнительную секунду при подсчете JD (UTC).
@Hidden Для каждой определенной шкалы времени существует соответствующий номер дня по юлианскому календарю, поэтому действительно существует номер дня по юлианскому календарю UTC. Количество Δ Т не имеет прямого отношения к дополнительным секундам. Високосные секунды введены, чтобы уменьшить расхождение между UTC и UT1 до менее чем одной секунды. @raxa Я не забыл об этой проблеме. Мой семестр подходит к концу, и я вернусь к нему после экзаменов.
@raxacoricofallapatorius Хм, високосные секунды добавляются при их накоплении, и то только в два числа в году 30 июня и 31 декабря. Программно тривиально добавить это в алгоритм JD to UT. Если вам интересно, как создаются данные JPL, почему бы вам не отправить им электронное письмо?
@JoeH Что вы имеете в виду, что ΔT не имеет прямого отношения к дополнительным секундам? В любом случае... с нетерпением жду вашего ответа... Я считаю, что physics.stackexchange.com - отличный ресурс для обучения, и любой конструктивный ответ более чем приветствуется!
Я понимаю различные отношения между шкалами времени (TT, TAI, UTC, UT1 и т. д.) и роль Δ Т и дополнительные секунды в этих отношениях. И я спросил JPL. Но довольно ясно, что они делают: (а) для данных, представленных во времени UTC, они не сообщают данные для дополнительной секунды и (б) они считают JD (UTC), как если бы дополнительной секунды не было. Вопрос здесь в следующем: является ли это -- в частности, полное исключение високосных секунд из учета JD(UTC) -- соглашением (что имеет смысл) или, возможно, даже формальным определением, или просто чем-то причудливым, что они делают.
Я имею в виду, что ΔT связывает UT1 с приблизительно равномерно текущей шкалой времени, Динамическим временем, тогда как UTC и UT1 связаны дополнительными секундами. Високосные секунды нужны только для того, чтобы удерживать UT1 и UTC в пределах 0,9 с друг от друга.

Вы совершенно правы: при присвоении календарным датам UTC действительных чисел JD просто невозможно назвать какой-либо момент в течение дополнительной секунды — в то время как аналоговый рендеринг времени UTC может сказать «23:59:60,25», JD предоставит нет имени ни для одного момента всей этой секунды.

В этом можно убедиться, если посетить стандартную систему JPL HORIZONS:

http://ssd.jpl.nasa.gov/horizons.cgi

Если вы введете время начала 2012-6-30 23:59:58и время окончания 2012-7-1 0:00:02и запросите размер шага в 5 «равных интервалов», вы могли бы, честно говоря, ожидать, что 5 секунд между этими двумя интервалами будут вашими пятью равными интервалами. Но, выбрав «Delta-T» и «формат даты-времени: Оба» в настройках таблицы, вместо этого вы увидите, что HORIZONS забывает о дополнительной секунде при делении запрошенного вами периода на 5 частей:

$$SOE
     2012-Jun-30 23:59:58.000 2456109.499976852 *m     66.184122
     2012-Jun-30 23:59:58.800 2456109.499986111 *m     66.184122
     2012-Jun-30 23:59:59.600 2456109.499995370 *m     66.184122
     2012-Jul-01 00:00:00.400 2456109.500004630 *m     67.184122
     2012-Jul-01 00:00:01.200 2456109.500013889 *m     67.184122
     2012-Jul-01 00:00:02.000 2456109.500023148 *m     67.184122
    $$EOE

Здесь явно присутствует дополнительная секунда — вы можете увидеть скачок значения Delta-T на 1 секунду! Но дробь JD явно не имеет «места» для обозначения дополнительной секунды, как и ГОРИЗОНЫ: она включена в последующие вычисления, но не может быть названа входом в систему.