Hi Hans,
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:
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
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".
http://maia.usno.navy.mil/ser7/tai-utc.dat
https://www.eecis.udel.edu/~mills/leap.html
http://hpiers.obspm.fr/eop-pc/index.php?index=UTC-offsets_tab
http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab
NIST, on the other hand, uses the more familiar June/December format here:
http://www.nist.gov/pml/div688/grp50/leapsecond.cfm
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.
/tvb
----- Original Message -----
From: "Hans Holzach" <[email protected]>
To: <[email protected]>
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!
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
