[time-nuts] GPS leap second pending (Fury/Z38XX)
Tom Van Baak
tvb at LeapSecond.com
Sun Jan 25 14:56:53 EST 2015
Actually, it is quite common to name the leap second by the July / January date instead of the June / December date. As you read papers on the web, use automated leap second services, or interact with instruments be prepared for both styles.
As an example, note that the most official of all leap second web pages is IERS announcement itself:
Here they use both "UTC TIME STEP on the 1st of July 2015" and "A positive leap second will be introduced at the end of June 2015".
Here are several more highly reputable examples, all of which use "July 1" instead of "June 30".
NIST, on the other hand, uses the more familiar June/December format here:
And of course there are many more examples everywhere. Just accept either format; they mean the same thing. Here are some personal thoughts on the use of 1 July instead of 30 June:
1) For most of the world's population the leap second happens in July, local time.
2) Using the words "adding a second" incorrectly favors positive leap seconds over negative leap seconds. Labeling a leap second as 23:59:60 (at the end of June) does not translate for negative leap seconds (are you going to call them 23:59:58? or 23:59:59?). In fact, there is no convenient label for a negative leap second. Note HP cleverly uses 59, 60, 61 to distinguish the three types of minutes at the end of a month.
3) Ideally any leap second table should make it clear if the leap is positive or negative, and treat both equally fair. There is no need to use the words positive/negative, or insert/delete, or +1/-1 if the table includes the TAI-UTC offset. Because of this, the most succinct tables are those that use the July/January style instead of June/December.
4) You don't even have to remember how many days June has if you use the July 1 style. ;-)
5) In computer code using a July 1 (or MJD equivalent) comparison date means you don't have to worry if the leap second was positive or negative and having special cases for 23:59:58/00:00:00 and 23:59:60/00:00:00.
And while I'm at it, here's a few reminders:
1) As currently defined, leap seconds are only ever applied at the end of a month.
2) In general, it can be *any* of the 12 months. That is, never hard-code June or December, or March or September into any document or program or data table. As the rotation rate continues to drift over decades and centuries there will be a need to activate the 4 slots a year or 12 slots a year rather than just the current 2 slots.
3) That's why use of the word "pending" can be confusing. Some use "pending" to describe only the month in which the leap second occurs avoids this ambiguity. Maybe use "announcement" when you know which month the leap second is pending. Maybe best to specify the leap date and not use words at all.
4) Lastly, although everyone talks about the "earth slowing down" this is not really why we have leap seconds. Since 1972 leap seconds have been needed because the earth is slow (vs. atomic clocks). Note "slow" (frequency) and "slowing" (frequency drift) are very different.
5) In fact, if you look at plots of earth rotation rates, the general trend over hundreds or thousands of years is a slow down of rate, but the general trend for the past 40 years is clearly a speed up of rate. As a result I predict the earth second will be back on track by 2020 to 2025, and if that continues, we will have our first negative leap second before 2030. See http://leapsecond.com/pages/lod/earth-lod-10.gif which I need to update from last year, but you get the idea.
----- Original Message -----
From: "Hans Holzach" <hans.holzach at gmail.com>
To: <time-nuts at febo.com>
Sent: Sunday, January 25, 2015 8:03 AM
Subject: Re: [time-nuts] GPS leap second pending (Fury/Z38XX)
> true, this depends on the definition of "pending". however, i found it a
> bit odd that the software reports a scheduled (but not pending this
> month) leap second on july 1st. it's june 30 that is 86401 seconds long,
> not the day after. in my opinion there is nothing between june 30 and
> july 1 that lasts 1 second.
> but in the meantime it dawned on me that maybe the leap second date
> respects my time zone (CET; UTC + 1). and indeed, as soon as i change
> ptim:tzone from 1 to 0, the reported leap second date is june 30!
More information about the time-nuts