# How do physicists and astronomers handle leap seconds?

I'm confused by the many contradictory descriptions I see about how UTC leap seconds are accounted for. I understand that there are various ways to handle them in common practice, and I've seen a variety of formal definitions. But it seems that in scientific practice, they are simply omitted: there is no UTC Julian Day (that is no JD(UTC) value) corresponding to any times during a leap second, and things like ephemeris are generally not reported for leap seconds. There are, of course, events that take place during leap seconds, but if one wants to refer to the time at which they occur, one uses a different timekeeping system (e.g. UT1 or TT).

Is that right? It makes perfect sense as a way to accommodate the ambiguities that leap seconds introduce, and it in fact corresponds to the way some systems (e.g. POSIX) implement them; but it doesn't quite match the definitions I've seen.

• This would correspond to the way Kim Stanley Robinson handles the Martian "time slip": clocks are stopped at 24 Earth hours and started again 39 minutes and 40 seconds later. – orome Dec 2 '12 at 22:25
• I've been thinking about this and I've concluded that the leap second jumps aren't accounted for in the ephemerides. They're there only to keep our UTC clocks in sync with Earth's rotation, i.e. UT1. – user11266 Dec 3 '12 at 1:55
• @JoeH: But for example, the azimuth JPL reports for Pluto at Greenwich changes between 2012-Jun-30 23:59:59.333 UTC and 2012-Jul-01 00:00:00.000 UTC by a factor of 2.5 times what it changes in any other nearby "1" second interval: 0.0069° vs. 0.0028° which is exactly what would be expected ((1 + 2/3)/(2/3)) if there were an extra second there. – orome Dec 3 '12 at 4:20
• I'm stumped then. Sorry. – user11266 Dec 3 '12 at 14:56

As you know, astronomers don't use UT for calculations but Julian Days (JDs). After the calculation is done, resulting JD is converted back to UT, UTC or wanted time zone for public outreach.

Leap seconds can be taken from historical data (e.g. NASA http://eclipse.gsfc.nasa.gov/SEhelp/deltat2004.html or US Navy ftp://maia.usno.navy.mil/ser7/deltat.data) or if those are not available they can be calculated http://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html. They are signified as ΔT.

ΔT is then added to JD and that time is called JDE (Julian Ephemeris Day). Or to put it in another way JD is calculated from UT, but JDE is calculated from Dynamical Time (TD = UT + ΔT).

Since early 1990's, some publications like Minor Planet Circulars (http://www.minorplanetcenter.net/iau/services/MPCServices.html) renamed JDE to JDT, where T signifies relation to Terrestrial Dynamical Time.

• The question is about the convention used in "converting back" to UTC in that last step. It looks like (a) JD(UTC) does not extend to leap seconds and that -- possibly as a consequence of (a) -- data are not conventionally reported for leap seconds. What inspired the question is a look at the JPL ephemeris data around a leap second, reported in UTC: they omit the leap second, and skip the leap second in counting JD(UTC). – orome Dec 7 '12 at 15:13
• @Hidden For each defined time scale, there is a corresponding Julian day number, so there is indeed a UTC Julian day number. The quantity $\Delta T$ isn't directly related to leap seconds. Leap seconds are introduced to bring the discrepancy between UTC and UT1 to less than one second.@raxa I've not forgotten about this issue. My semester is winding down and I'll come back to it after exams. – user11266 Dec 7 '12 at 15:50
• @raxacoricofallapatorius Hmm, leap seconds are added when it accumulates, and then only on two dates in a year June 30 and December 31. It is programaticaly trivial to add this to the algorithm of JD to UT. If you're interested how JPL data is done, why don't you send them an email? – Hidden Scholar Dec 8 '12 at 4:50
• @JoeH What do you mean ΔT isn't directly related to leap seconds? Anyway... looking forward to your reply... I believe physics.stackexchange.com is great resource for learning and any constructive response is more then welcome! – Hidden Scholar Dec 8 '12 at 4:54
• I understand the various relationships among timescales (TT, TAI, UTC, UT1, etc.) and the role of $\Delta T$ and leap seconds in those relationships. And I've asked JPL. But it's pretty clear what they're doing: (a) for data presented at UTC times, they don't report data for a leap second and (b) they count JD(UTC) as if there was no leap second. The question here is: is that -- in particular the omission of leap seconds entirely from JD(UTC) accounting -- a convention (which makes sense) or perhaps even a formal definition, or just something quirky that they do. – orome Dec 8 '12 at 5:08

You are entirely correct: when assigning JD real numbers to UTC calendar dates, it is simply impossible to name any moment during the leap second — while an analog rendering of a UTC time can say “23:59:60.25”, the JD will provide no name for any moment of that entire second.

This can be seen if you visit the standard JPL HORIZONS system:

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

If you type a start time of 2012-6-30 23:59:58 and an end time of 2012-7-1 0:00:02 and ask for a step size of 5 “equal intervals”, you might in fairness have expected to get the 5 seconds between those two times as your five equal intervals. But, selecting “Delta-T” and “date-time format: Both” in your table settings, you will instead see that HORIZONS forgets about the leap second when dividing the period you asked for into 5 pieces:

$$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


Clearly a leap second occurs here ­— you can see the Delta-T value jump by 1 second! But the JD fraction clearly has no “room” to name the leap second, and neither does HORIZONS: it is included in the downstream calculations, but cannot be named as an input to the system.