Content deleted Content added
Tag: Reverted |
- |
||
| (7 intermediate revisions by 7 users not shown) | |||
Line 24:
==Rationale==
{{See also|ΔT (timekeeping)}}
[[File:Deviation of day length from SI day.svg|thumb|left|Deviation of day length from SI
Leap seconds are irregularly spaced because the Earth's rotation speed changes irregularly. Indeed, the Earth's rotation is quite unpredictable in the long term, which explains why leap seconds are announced only six months in advance.
Line 217:
The scheduling of leap seconds was initially delegated to the [[Bureau International de l'Heure]] (BIH), but passed to the International Earth Rotation and Reference Systems Service (IERS) on 1 January 1988. IERS usually decides to apply a leap second whenever the difference between UTC and UT1 approaches 0.6 s, in order to keep the difference between UTC and UT1 from exceeding 0.9 s.
The UTC standard allows leap seconds to be applied at the end of any UTC month, with first preference to June and December and second preference to March and September. {{As of|May 2023}}, all of them have been inserted at the end of either 30 June or 31 December. IERS publishes announcements every six months, whether leap seconds are to occur or not, in
<!--
{| style="float:left;"
|{{Listen
Line 233:
When it is mandated, a positive leap second is inserted between second 23:59:59 of a chosen UTC [[calendar date]] and second 00:00:00 of the following date. The definition of UTC states that the last day of December and June are preferred, with the last day of March or September as second preference, and the last day of any other month as third preference.<ref>{{cite web|url=https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en|title=International Telecommunication Union Radiocommunications sector recommendation TF.460-6: Standard-frequency and time-signal emissions|access-date=9 February 2017|url-status=live|archive-url=https://web.archive.org/web/20161017185018/https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en|archive-date=17 October 2016}}</ref> All leap seconds (as of 2019) have been scheduled for either 30 June or 31 December. The extra second is displayed on UTC clocks as 23:59:60. On clocks that display local time tied to UTC, the leap second may be inserted at the end of some other hour (or half-hour or quarter-hour), depending on the local time zone. A negative leap second would suppress second 23:59:59 of the last day of a chosen month so that second 23:59:58 of that date would be followed immediately by second 00:00:00 of the following date. Since the introduction of leap seconds, the mean solar day has outpaced atomic time only for very brief periods and has not triggered a negative leap second.
Recent changes to the Earth's rotation rate have made it more likely that a negative leap second will be required before the abolition of leap seconds in 2035.<ref>{{Cite web |last=Matsakis |first=Demetrios |date=September 21, 2022 |title=Will we have a negative leap second? |url=https://www.gps.gov/cgsic/meetings/2022/matsakis.pdf |access-date=3 June 2024 |website=gps.gov}}</ref><ref>{{Cite journal |last=Agnew |first=Duncan Carr |date=April 2024 |title=A global timekeeping problem postponed by global warming |url=https://www.nature.com/articles/s41586-024-07170-0 |journal=Nature |language=en |volume=628 |issue=8007 |pages=333–336 |doi=10.1038/s41586-024-07170-0 |pmid=38538793 |bibcode=2024Natur.628..333A |issn=1476-4687|url-access=subscription }}</ref>
==Future==
Line 247:
A number of objections to the proposal have been raised. P. Kenneth Seidelmann, editor of the Explanatory Supplement to the Astronomical Almanac, wrote a letter lamenting the lack of consistent public information about the proposal and adequate justification.<ref>{{cite mailing list |url=https://lists.igs.org/pipermail/igsmail/2005/006563.html |title=UTC redefinition or change |author=P. Kenneth Seidelmann |mailing-list=IGS Mail}}</ref> In an [[op-ed]] for ''[[Science News]]'', Steve Allen of the [[University of California, Santa Cruz]] said that the process has a large impact on astronomers.<ref>{{cite magazine |last=Cowen |first=Ron |date=22 April 2006 |title=To Leap or Not to Leap: Scientists debate a timely issue |url=https://www.sciencenews.org/article/leap-or-not-leap |url-status=live |magazine=[[Science News]] |archive-url=https://web.archive.org/web/20230526024544/https://www.sciencenews.org/article/leap-or-not-leap |archive-date=26 May 2023 |access-date=26 May 2023}}</ref>
At the 2014 General Assembly of the [[International Union of Radio Scientists]] (URSI), Demetrios Matsakis, the [[United States Naval Observatory]]'s Chief Scientist for Time Services, presented the reasoning in favor of the redefinition and rebuttals to the arguments made against it.<ref>{{cite web |url=http://tycho.usno.navy.mil/papers/ts-2014/Matsakis-LeapSecondComments.URSI-2014.pdf |title=Comments on the Debate over the Proposal to Redefine UTC |author1=Demetrios Matsakis |date=18 August 2014 |access-date=31 October 2017 |url-status=
The United States formulated its position on this matter based upon the advice of the [[National Telecommunications and Information Administration]]<ref>{{cite web|url=https://www.ntia.doc.gov/files/ntia/publications/ai_1.14_usa_proposal_2014-02-06_0.pdf|title=United States Proposals, Proposal for the Work of the Conference, Agenda Item 1.14|publisher=[[National Telecommunications and Information Administration]]}}</ref> and the [[Federal Communications Commission]] (FCC), which solicited comments from the general public.<ref>{{cite web|url=https://apps.fcc.gov/edocs_public/attachmatch/DA-14-88A1.pdf|title=FCC Seeks Comment On Recommendations Approved By The Advisory Committee For The 2015 World Radiocommunication Conference|publisher=[[Federal Communications Commission]]|date=28 January 2014|url-status=live|archive-url=https://web.archive.org/web/20140729075437/https://apps.fcc.gov/edocs_public/attachmatch/DA-14-88A1.pdf|archive-date=29 July 2014}}</ref> This position is in favor of the redefinition.<ref>{{cite web|url=https://www.ntia.doc.gov/files/ntia/publications/sitt-stit-357221-v1-citel_presentation_for_regional_meetings_on_wrc-15-r2.ppt|title=Preliminary Views and Proposals Regarding WRC-15 Agenda Items|publisher=[[Organization of American States]]|format=PPT|url-status=live|archive-url=https://web.archive.org/web/20140729090447/http://www.ntia.doc.gov/files/ntia/publications/sitt-stit-357221-v1-citel_presentation_for_regional_meetings_on_wrc-15-r2.ppt|archive-date=29 July 2014}}</ref>{{efn|The FCC has posted its received comments, which can be found using their search engine for proceeding 04–286 and limiting the "received period" to those between 27 January and 18 February 2014, inclusive.<ref>{{cite web|url=http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=04-286&applicant=&lawfirm=&author=&disseminated.minDate=&disseminated.maxDate=&received.minDate=1%2F27%2F14&received.maxDate=2%2F18%2F14&dateCommentPeriod.minDate=&dateCommentPeriod.maxDate=&dateReplyComment.minDate=&dateReplyComment.maxDate=&address.city=&address.state.stateCd=&address.zip=&daNumber=&fileNumber=&bureauIdentificationNumber=&reportNumber=&submissionTypeId=&__checkbox_exParte=true|title=Search for Filings Results|work=fcc.gov|url-status=live|archive-url=https://web.archive.org/web/20150701090036/http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=04-286&applicant=&lawfirm=&author=&disseminated.minDate=&disseminated.maxDate=&received.minDate=1%2F27%2F14&received.maxDate=2%2F18%2F14&dateCommentPeriod.minDate=&dateCommentPeriod.maxDate=&dateReplyComment.minDate=&dateReplyComment.maxDate=&address.city=&address.state.stateCd=&address.zip=&daNumber=&fileNumber=&bureauIdentificationNumber=&reportNumber=&submissionTypeId=&__checkbox_exParte=true|archive-date=1 July 2015}}</ref>}}
Line 296:
* Some older versions of Motorola Oncore VP, UT, GT, and M12 GPS receivers had a software bug that would cause a single timestamp to be off by a day if no leap second was scheduled for 256 weeks. On 28 November 2003, this happened. At midnight, the receivers with this firmware reported 29 November 2003, for one second and then reverted to 28 November 2003.<ref>{{cite web|url=http://www.leapsecond.com/notes/leapsec256.htm|title=256-Week Leap Second Bug|date=2 July 2013|url-status=live|archive-url=https://web.archive.org/web/20160304002759/http://www.leapsecond.com/notes/leapsec256.htm|archive-date=4 March 2016}}</ref><ref>{{cite web|url=http://compgroups.net/comp.protocols.time.ntp/motorola-oncore-receivers-and-leap-se/287130|title=Motorola Oncore receivers and Leap Second bug|date=2 July 2013|url-status=usurped|archive-url=https://web.archive.org/web/20130118233907/http://compgroups.net/comp.protocols.time.ntp/motorola-oncore-receivers-and-leap-se/287130|archive-date=18 January 2013}}</ref>
* Older Trimble GPS receivers had a software flaw that would insert a leap second immediately after the [[List of GPS satellites|GPS constellation]] started broadcasting the next leap second insertion time (some months in advance of the actual leap second), rather than waiting for the next leap second to happen. This left the receiver's time off by a second in the interim.<ref>{{cite web|url=http://www.guralp.com/howtos/leap-second-problem-with-older-gps-receivers.shtml|title=Leap-second problem with older GPS receivers|date=19 November 2014|url-status=live|archive-url=https://web.archive.org/web/20141129055128/http://www.guralp.com/howtos/leap-second-problem-with-older-gps-receivers.shtml|archive-date=29 November 2014}}</ref><ref>{{cite web|url=http://www.spirent.com/Blogs/Positioning/2015/May/How_Leap_Seconds_Can_Interfere_with_GNSS_Receivers|title=How Leap Seconds Can Interfere with GNSS Receivers|date=13 May 2015|url-status=live|archive-url=https://web.archive.org/web/20160306014132/http://www.spirent.com/Blogs/Positioning/2015/May/How_Leap_Seconds_Can_Interfere_with_GNSS_Receivers|archive-date=6 March 2016}}</ref>
* Older Datum/Symmetricom
* Four different brands of navigational receivers that use data from [[BeiDou]] satellites were found to implement leap seconds one day early.<ref>{{cite web |date=3 March 2015 |title=BeiDou Numbering Presents Leap-Second Issue |url=https://www.gpsworld.com/beidou-numbering-presents-leap-second-issue/ |publisher=GPS World}}</ref> This was traced to a bug related to how the BeiDou protocol numbers the days of the week.
| |||