Talk:Leap second

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Time (Rated B-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

Moving reference longitude[edit]

The traditional (GMT) scheme was to establish mean solar time at the reference longitude of Greenwich, then to relate local civil times to GMT by offsets of (preferably) integer numbers of hours. This translated the mean solar time at the Greenwich reference longitude to a local reference longitude that was a multiple of 15 degrees. Eliminating the leap second is equivalent to abandoning Greenwich's longitude as the overall reference. Neglecting one leap second effectively moves all reference longitudes eastward a quarter of a nautical mile at the equator, an average rate of less than a meter per day at the rate leap seconds have been issued.

Since the vast majority of locations within one time zone are observing a civil time that differs from the true local mean solar time by much more than a second anyway, having the reference moving at so slow a rate can hardly be noticed. In any case, the drawing of time-zone boundaries has so much to do with geography and political borders, and recurs so frequently that so slowly creeping a reference is easily accommodated by tweaking a boundary every century or two.

This concept of a moving reference would seem to satisfy the requirement mentioned for some countries, that civil time be tied to solar time. It places the responsibility on the country's government of drawing and redrawing time-zone boundaries to keep times everywhere within the country reasonably close to the mean solar time at the local reference longitudes, a responsibility they already accept.

I am posting this idea here in the hope that someone will have seen it somewhere else, making it not original research and therefore able to be included in the article. — Preceding unsigned comment added by (talk) 22:52, 9 June 2013 (UTC)

As far as I know they are two ways to approximately keep civil time in line with local mean solar time:
  • Redefine the timezones every few centuries, using mechanisms that already exist.
  • Some proponents of the abolition of leap seconds have proposed that they be replaced with leap hours, to satisfy the requirement that UTC should be linked to solar time. It is not a real solution but no leap hour will be needed before a few thousand years so by that time we will probably use a different timekeeping system anyway. Bomazi (talk) 16:39, 16 May 2017 (UTC)

Fake screenshot[edit]

Showing 23:59:60 when there's still more than two hours to go! — Preceding unsigned comment added by (talk) 21:57, 30 June 2015 (UTC)

Indeed not serious because people looking are misinformed about the time it happens. — Preceding unsigned comment added by (talk) 22:16, 30 June 2015 (UTC)

The layout and colors at match the look of the screenshot including the arrow buttons to change the time zone from a local United States time zone. The image is set at UTC which is when the second is inserted to display as 23:59:60. 22yearswothanks (talk) 07:00, 6 April 2017 (UTC)

Table of announced leap seconds to date[edit]

Recently there have been several suggested edits to the style of the "Announced leap seconds to date" table. This edit added to the table a new column titled "Offset" that apparently contains a running total of the leap seconds. A subsequent edit fixed the slightly misleading column title by renaming the column to make it clear it was a running total of leap seconds, not the offset from TAI. I'd like to suggest that the table be restored to it's original layout. I don't think the running total adds much value to the table, and given the height of the table I think it fits the page better in the narrower three column layout rather than the current four column layout. Thoughts? —RP88 (talk) 07:58, 1 January 2017 (UTC)

I'm inclined to save space. I don't think many people will need to know the running total of leap seconds; the few who do can add it up for themselves. I also liked the change which removed years in which no leap second occurred. Jc3s5h (talk) 16:18, 1 January 2017 (UTC)
Sounds good to me. The cumulative total, with or without the initial 10 second offset, might be better presented graphically. Having such a graph with its constant time scale might eliminate the need to include years with no leap seconds, or change it into a single column table of mm/dd/yyyy of all leap seconds, perhaps color-coded to distinguish June seconds from December ones. YBG (talk) 22:51, 1 January 2017 (UTC)
I mostly object to the recent addition of the running total of leap seconds, I don't think it is helpful, so I'm inclined to revert that change if no one objects. To be honest, I also kind of like the constant time scale of the current table and think it would be worse if the years without leap seconds were removed, but I'm open to the idea of finding an alternative presentation for that information. For that matter, the Deviation of day length from SI based day graph that is already in the article (in the "Slowing rotation of the Earth" section) has red dots that indicate leap seconds in a cumulative fashion on a constant time scale. —RP88 (talk) 23:41, 1 January 2017 (UTC)
I don't have a strong preference but have no objection to removing the total column. Fundamentally this is a 2-column table {date, adjustment amount}. Although it hasn't yet happened, leap seconds can be inserted any month, not just June and December. I like the idea of representing it graphically. That would likely be in addition to the table but would allow the table to list only non-zero adjustments. ~Kvng (talk) 15:20, 4 January 2017 (UTC)
OK, since there appear to be no objections, I've removed the "total" column. —RP88 (talk) 11:52, 6 January 2017 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Leap second. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

YesY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:05, 13 May 2017 (UTC)

Hey, not so quick on the draw! That page still works - maybe check the URL twice, with some time between the tests, and if they both fail, then go to an archive. Guy Harris (talk) 01:44, 13 May 2017 (UTC)

Number of leap seconds is wrong, should change from 27 to 37[edit]


From the reference provided by Wikipedia: It says:

 from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC   : UTC-TAI = - 36s
 from 2017 January 1, 0h UTC, until further notice    : UTC-TAI = - 37s 

But the wikipedia article says

"Since this system of correction was implemented in 1972, 27 leap seconds have been inserted, the most recent on December 31, 2016 at 23:59:60 UTC.[1]"

This should be changed to 37 as per reference

I am not allowed to edit this page, hence this post. Can someone with rights update that figure please?

Thanks. — Preceding unsigned comment added by Mrojakeo (talkcontribs) 04:30, 15 August 2017 (UTC)

The number of inserted leap seconds is not the same as the difference between TAI and UTC. TAI started out 10 seconds ahead of UTC; as the International Atomic Time page says, "TAI is exactly 37 seconds ahead of UTC. The 37 seconds results from the initial difference of 10 seconds at the start of 1972, plus 27 leap seconds in UTC since 1972." When the system of correction was implemented, there were 10 seconds difference between UTC and TAI; after that, 27 more seconds were inserted. The initial 10 seconds are separate from the 27 inserted sections. Guy Harris (talk) 04:49, 15 August 2017 (UTC)
I agree with Guy Harris, except for started out. UTC began around 1960, but initially was aligned with UT2 and later UT1 through the use of small changes in the length of a second, and small time steps (much less than one second). Similar methods were used to keep radio time signals that were referenced to atomic time in step with UT2 before those time signals were named UTC, since 1958. So the 10 second difference is the difference at the beginning of leap seconds, not the beginning of UTC. Jc3s5h (talk) 09:31, 15 August 2017 (UTC)

A proposal for the solution of leap second problem[edit]

Wikipedia talk pages are for discussing improvements to the Wikipedia article, not for making proposals about the underlying subject matter of the article. Since leap seconds are controlled by ITU, and the [International Telecommunications Union|ITU] is an agency of the United Nations. Proposals are dealt with at periodic conferences to which governments send representatives. So you should address your proposal to the appropriate representative from your country. Jc3s5h (talk) 15:17, 16 August 2017 (UTC)

Proposal has been posted at my talk page. Georges T. (talk) 13:21, 20 October 2017 (UTC)

Georges, we've already had dubious original research in another article. Please don't start on the leap second. What on earth makes you think that your proposed method will cope with unpredictable variations? Dbfirs 15:03, 20 October 2017 (UTC)
Mr Dbfirs, please let me express my sincere glad for you address me again after many months. In the article about equal temperament my contribution is general formulas, relating examples, and background theory. Indeed formulas express mathematically psycho-acoustical law known to ancient Egyptians. Before me, many others have published formulas about, but not in general form, and background theory is just my presentation of psycho-acoustical law.
Now, regarding leap second, I do not contribute to the article, because proposal is really original work of mine.
On your question my answer is that just because some of earth's rotational speed's variations are unpredictable (irregular, random) we have to use regularly adjusting second for abolish leap second keeping track earth's rotation, not cesium atom oscillation as Americans propose. British strongly oppose american proposal, then you, as British, should support my proposal.
Because Mr. Jc3s5h considers that we are not permitted to discuss this matter here, please put your comments at my talk page Questions and Answers on the proposal. Regards. The Straw Man Georges Theodosiou Georges T. (talk) 16:22, 20 October 2017 (UTC)
Personally, I would prefer to keep the second at a fixed length, as defined by the International Committee for Weights and Measures. No other unit varies in size. Dbfirs 08:23, 21 October 2017 (UTC)

Mr Dbfirs, please permit me say, we use conversion factor 60 for minute (1 minute = 60 sec), also 60 for hour (1 hour = 60 minutes) and 24 for day (1 day = 24 hours). Also 61 seconds for the minute including leap second, 60 minutes + 1 second for the hour including leap secont, 24 hours + 1 second for the day including leap second, 365 (for common year) or 366 (for leap year) days + 1 second for the year including leap second. That's real situation in measuring time for someone who loves exactness. Then why not use conversion factor or similar for yas? Please read my Proposal for the solution of leap second problem. With regards and friendship, Georges Theodosiou, the Straw Man. Georges T. (talk) 12:28, 21 October 2017 (UTC)

Because it is not, and never can be exact. Dbfirs 12:32, 21 October 2017 (UTC)
Mr Dbfirs, please permit following question: Factor's precision is 1 pcar. Does it not satisfy you? With regards and friendship, Georges Theodosiou, The Straw Man, Georges T. (talk) 12:48, 21 October 2017 (UTC)
That's for the calculation based on the past, not for the real current rotation. Dbfirs 15:44, 21 October 2017 (UTC)

Mr Dbfris, please let me answer: yes, my algorithm is based on the nearest past, but it's the only solution since we can not predict random jerks. However always offset |UT1-IST| be far less than 0.9 sec, the limit demanded by International Community. If you are interested for authoritative answer, ask Mr. Director of IERS/EOC. With regards and friendship, Georges Theodosiou, The Straw Man, Georges T. (talk) 13:56, 23 October 2017 (UTC)

“Electrical utilities reported errors when interpolating voltage and current values sampled across a leap second...”[edit]

A recent edit claimed that electrical utilities had difficulty with leap seconds. The claim has no source. The closest thing to a source I was able to find with a Google search is a paywalled article in the IET digital library which appears to refer to a system for visualizing errors due to incorrect timestamps caused by GPS loss and leap seconds. If nobody can find a source for this paragraph I will delete it. 18:51, 27 September 2017 (UTC)

I have deleted the unsourced paragraph.  John Sauter (talk) 16:12, 1 October 2017 (UTC)

You will not find a source because we are talking about preventing issues, because an incident can have many reasons and because not everyone wants to disclose. You have to ask yourself what is a reliable source of information. My report as a witness to the leap second insertion test is confidential and restricted to the participants. — Preceding unsigned comment added by Hubert Kirrmann (talkcontribs) 13:02, 20 November 2017 (UTC)

You should have made it clear in the original paragraph that the electrical utilities were not reporting actual errors but rather were concerned about possible errors in the future. In any case, information in Wikipedia articles must be verifiable; see the Wikipedia article on verifiability for details. If the information you have is confidential, you should not be disclosing it. A secret meeting in which someone objected to leap seconds does not rise to the level of “problems with leap seconds” in my judgement. John Sauter (talk) 16:45, 20 November 2017 (UTC)

The information is verifiable. There are no secret meetings, only that only members / delegates of IEC or ITU-R have access to the minutes and therefore the links are not public.(talk) 2017-11-24 9:34 (UTC)

If only members / delegates of IEC or ITU-R have access to the minutes, how does a general Wikipedia user verify the information? John Sauter (talk) 14:31, 24 November 2017 (UTC)

dubious power utilities[edit]

I have flagged the paragraph on power utilities as dubious. The whole paragraph is dubious, as there have been many leap seconds without grid meltdown. Also the assertion that utilities are bound to use UTC for technical operations (i.e. not billing, etc) sounds very odd to me. -- Q Chris (talk) 16:33, 16 November 2017 (UTC)

The paragraph states that substations do not have a table of leap seconds, but does not explain why; that is the obvious solution to the problem. It proposes changing UTC rather than using TAI for “legal reasons” which seems silly, as pointed out by Q Chris above. It refers to reports, a questionnaire and a decision, but without any citation to documents on the web. All of the other problems with leap seconds are well-documented; this one has no references. I deleted a previous unsupported description of power utility problems because it was unsourced. If this problem remains unsourced it also deserves deletion. John Sauter (talk) 22:50, 16 November 2017 (UTC)

I supplied all required references as far as these were in the public domain. We do not need to have an incident before taking actions. These above deletings obviously come from persons not acquainted with the standardization process in IEC. At the 2017 meeting in New Orleans, the proposal to maintain a table of leap seconds in the substation was turned down by an industrial group (consensus calls not to include if one party opposes). The proposal to use TAI instead of UTC was turned down by a US-Consultant: UTC is legal time, the lawyers should decide. The possiblity to use TAI was expressely ruled out. An industrial group insisted ITU-R should change UTC instead. Hubert Kirrmann (talk), 2017 November 20, 12:07 UTC. Please inform me directly instead of deleting entries behind my back. — Preceding unsigned comment added by Hubert Kirrmann (talkcontribs) 12:12, 20 November 2017 (UTC)

So a substation may not contain a table of leap seconds because an industrial group objects, the proposal to use TAI was turned down by a US consultant, and an industrial group wants UTC to remove leap seconds, causing the rest of the world to suffer for its own convenience. That doesn't sound like a problem with leap seconds, it sounds like a problem with an industrial group. Given the recent history of rejection of the elimination of leap seconds, I don't think your industrial group is going to get its way, no matter how much it whines. I suggest they use GPS time, since it does not have leap seconds and is available at every substation using a radio receiver. Actually, I wouldn't be surprised if every substation already has a GPS receiver for keeping its clock accurate. John Sauter (talk) 16:28, 20 November 2017 (UTC)

In addition to that a lot of the stuff appears to be contradicted elsewhere:
Time in IEC 61850 is expressed by a 32-bit counter that counts the seconds since epoch 1970-01-01 and a 24-bit counter for the binary fractions of second.
But [1] says that it uses a 48 bit integer number (for seconds) and a 32 bit integer number (for nanoseconds).
The electrical power utilities used SNTP with an accuracy of 10 ms to time-stamp events in the grid, at that time leap second were not critical. ... Since 2012, the utilities introduced the PTP "Precision Time Protocol" IEEE 1588 that provides sub-microsecond-accurate measurements.
First of all 10ms is 1/100th of a leap second - so it is not clear why it was not critical before but is now. Secondly IEC/IEEE 61850-9-3 states "uses the PTP timescale based on TAI International Atomic Time, also delivers UTC Coordinated Universal Time". This is clarified by [2] which says "PTP is a network-based time distribution protocol operating by default on the PTP time-scale which is based on TAI and is therefore not affected by leap seconds. PTP does provide information (leap flags and UTC offset) to end devices relying on time based on UTC to alert when a leap second is expected to occur.". -- Q Chris (talk) 10:02, 21 November 2017 (UTC)

I have now removed this dubious paragraph, which was at best OR and at worst incorrect as it was contradicted by other sources. -- Q Chris (talk) 10:25, 5 January 2018 (UTC)

There is no contradiction beween the OMICRON paper and my statements. PTP (IEEE 1588) has a 48-bit seconds counter, the IEC 61850 TimeStamp (derived from SNTP) has a 32 bit seconds counter. There exists a difference between the time format supplied by the time distribution system on a node (GPS, PTP) and the time format that the application is using. If the application generates IRIG-B or C37.188 messages, it will use the format prescribed by these standards and not what they get from GPS or PTP. Ten years ago, NTP was used to time-stamp events with a resolution of 10ms. Substations do not spend money on PTP to replace NTP, but to add functionality, in particular precision time stamping of sampled values. The statement of Q Chris regarding industry wanting to fix their problem at expenses of the rest of the world is unprofessional. From the statements of Q Chris, I can only conclude that as long as a person with so little competence is allowed to wipe out statements, I should not waste my time further on it. -- Hubert Kirrmann (talk) 22:00, 12 January 2018 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Leap second. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

YesY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:38, 19 December 2017 (UTC)