Talk:Leap second/Archive 2

Archive 1

Archive 2

Screenshot

I like the screenshot (got one myself). I like that it's actually a UTC time, compared to the previous Central Time image (and my new Pacific Time image). However, it's odd that it reads "Right now, the official U.S. time is". I know why it does, but perhaps crop that image to exclude that line. (On the other hand, the source is from NIST in the U.S., so I suppose it could be considered the "official U.S. UTC time".) goodeye (talk) 01:28, 1 July 2012 (UTC)

Negative leap seconds

The article should mention that leap seconds can be either added or removed. The article currently gives the impression that they can only be added. Thue (talk) 19:34, 4 July 2012 (UTC)

The article states "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. However, since the UTC standard was established, negative leap seconds have never been needed." Jc3s5h (talk) 20:26, 4 July 2012 (UTC)

It would probably help to insert explicit references to ITU-R TF.460 both here and on the UTC page. The ITU-R made the recent versions of this defining document openly available starting in December 2010.Steven L Allen (talk) 02:00, 12 July 2012 (UTC)

Although recent versions are useful for current practice, they are useless as historical documents. Only the 1970 and 1974 versions of CCIR Recommendation 460, or a reprint of them, or of their leap second sections would serve that purpose. — Joe Kress (talk) 08:36, 12 July 2012 (UTC)

US NBS reprinted the 1970 original Rec. 460 on page 31 of Monograph 140, Time and frequency: theory and fundamentals (Byron E. Blair, 1974). Prior to that it also reprints numerous other original defining documents about the SI second and TAI.Steven L Allen (talk) 18:31, 12 July 2012 (UTC)

Why can't the abolition movement just change to using TAI?

I am curious why the article makes no mention of the idea that those who wish to abolish the leap second might do better simply to use the existing TAI time system for their purposes rather than altering UTC to make it resemble TAI. We've had TAI since the 1950s, and it does what those who seek to abolish the leap second want a timescale to do. Why don't they just switch from using UTC to using TAI? If there are any interesting reasons why they would rather alter UTC than switch to using the existing TAI system, those reasons ought to be discussed in this article.

I'd edit the article to discuss these reasons myself, if I knew of any. But if there are no good reasons, that point ought to be addressed in the article as well, and I'm not enough of an expert in this subject to make assertions about the absence of good reasons.

In particular it's kind of crazy that we already have GPS time, which is a variant of TAI that differs from it by a constant offset. Abolishing the leap second would just leave us with a third such constant-offset-differing timescale when TAI is already adequate for all such purposes. Reasons for wanting to multiply the number of constant-offset atomic timescales should be discussed in this article, if such reasons exist.

--arkuat (talk) 23:41, 26 July 2012 (UTC)

Only arguments that have been reported in reliable noteworthy sources should go in the article. But I suspect the reason many of these sources have not adopted TAI is that it is not the legal civil time anywhere in the world. Many systems must keep legal time, and many other systems must interface with systems that are keeping legal time. Jc3s5h (talk) 03:08, 27 July 2012 (UTC)

What is "legal time"? -- Q Chris (talk) 07:23, 27 July 2012 (UTC)

In any country, civil time (rather than "legal time") is the timescale approved for official and commercial use.

In Switzerland for example civil time is defined as UTC+1 (+2 in the summer). So that's what you are required to use, by law, whether in a contract, a bus schedule, a police report or whatever. In the same way that you are required to sell, say, gasoline by the liter.

In practice the civil time of most (all?) countries is based on UTC. So for any system that interact with the outside world using anything else than UTC is not an option. Thus if you are not happy with UTC you can't just use something else, you need the whole word to switch.

TAI couldn't be used directly as we don't want clocks to suddenly jump backwards. Continuity with the current time has to be maintained. Whether you formally introduce a new timescale or change the definition of UTC is a detail.

So the real question, which IMO is not really addressed in the article at this time, is why would you want to abolish leap seconds ?

The main reason is that leap seconds are a huge pain in the butt for computers and networks

Bomazi (talk) 16:39, 17 January 2013 (UTC)

I think the pain in the butt is covered in the first paragraph of the Proposal to abolish leap seconds section. -—Kvng 15:07, 20 January 2013 (UTC)

Ok, I didn't read that part. Bomazi (talk) 21:56, 20 January 2013 (UTC)

One area where "traceable" time comes into play is in the financial markets where messages between traders and stock exchanges are time-stamped and people calculate transmission times between parties to the nearest millisecond and get excited once these take longer than 0.1 seconds. The only way that the times can be measured is for the transmitter to place a timestamp on their electgronic message and for the recipient to note the timestamp upon receipt. Martinvl (talk) 07:47, 21 January 2013 (UTC)

Incorrect edit

The following was added today:

Applications for which leap seconds cause problems can use one of the other existing time standards, such as TAI, which is the basis for UTC,[1] or GPS time, which may be calculated from satellite-broadcast signals.[2]

[Citations changed slightly to work in talk page.]

References

1. E. Felicitas Arias, Gianna Panfilo, and Gérard Petit (2011-09-11). "Status of UTC/TAI" (PDF). Retrieved 2013-08-20.{{cite web}}: CS1 maint: multiple names: authors list (link)

2. Geoffrey Blewitt (1997). "Basics of the GPS Technique: Observation Equations" (PDF). Retrieved 2013-08-20.

This is not correct. In the earlier part of the edit, it is claimed that TAI is the basis for UTC, which is partly true, but TAI is not broadcast or disseminated, so an application occurring outside a time laboratory does not have direct access to it. Furthermore, TAI is more than 30 seconds different from UTC, which is the defacto basis for civil time throughout the world. So for many applications TAI may not be used instead of UTC.

Which part of "TAI is the basis for UTC" is partly true. If you actually want to argue this further, it is probably best to do so at International Atomic Time or Coordinated Universal Time. ~KvnG 03:15, 25 August 2013 (UTC)

In the later part of the edit it is claimed that GPS time may be calculated from satellite-broadcast signals. This is backwards; GPS satellites broadcast GPS time. They also broadcast data that can be used to calculate UTC from GPS, but some applications cannot obtain the UTC calculation data in time to make use of it.

GPS time is based on TAI. A simple and completely accurate calculation (TAI – GPS = 19 seconds) converts between the two. No calculation data necessary. See Gps#Timekeeping. ~KvnG 03:15, 25 August 2013 (UTC)

Also, the second citation is unacceptable in that it fails to state what page in a 46 page paper supports the claim. Furthermore the strings "UTC" and "coordinated" (with no sensitivity to capitalization) cannot be found in the paper. Jc3s5h (talk) 16:34, 20 August 2013 (UTC)

I agree with this. ~KvnG 03:15, 25 August 2013 (UTC)

Dubious edit

user:Rightismight made this edit, with no citation provided. Rightismight asserts

In the event the ITU resolution passes and leap seconds are no longer inserted, special Network Time Protocol and other time servers could be set up that provide UT1 rather than UTC. Those astronomical observatories and other users that require UT1 could run off that time - although in many cases these users already downloaded UT1-UTC from the IERS, and apply corrections in software.

However, one of the concerns frequently raised is that no though analysis has been done to determine which systems will fail if leap seconds are eliminated. Not knowing which systems will be affected, there is no way to assess how effective a particular solution would be. Also, it is not known whether the systems will be accessible to make any software updates that may be required, or whether the documentation and skills that would be needed to update potentially old systems still exist.

Such a statement ought not to be made by a Wikipedia editor; it must come from a reliable source. Jc3s5h (talk) 02:23, 4 July 2014 (UTC)

I have added a reference, from a respected scientist, made at a well-known conference on this matter. Hope this is considered sufficient. — Preceding unsigned comment added by Rightismight (talk • contribs) 04:39, 4 July 2014 (UTC)

I support removing this apparently speculative and uncited contribution. ~KvnG 14:02, 22 July 2014 (UTC)

Citation clean-up

The citation format for this article is a mess. The usual practice is to follow the format that was first introduced, which appears to be the APA style. Comments? Jc3s5h (talk) 17:49, 15 July 2014 (UTC)

Manually formatting references is not fun. I prefer to use {{citation}} and friends. ~KvnG 14:02, 22 July 2014 (UTC)

Future of the leap second.

This source [1] seems to indicate to me that no decision was made at the 2015 conference WRC-15 to abolish the leap second although it was resolved to look at this possibility. Are there any secondary sources confirming this? What should we say about the subject in the article? Martin Hogbin (talk) 12:49, 14 November 2015 (UTC)

My impression is the conference is still in progress. The document cited by Martin Hogbin seems to me to just repeat the resolution from 2012 to consider the matter at this year's conference; it seems more like an agenda item than a decision. Jc3s5h (talk) 20:55, 14 November 2015 (UTC)

I have had another read and I think you are correct. Do we know when the decision is likely to be made? Martin Hogbin (talk) 13:29, 15 November 2015 (UTC)

I recall that the conference is to end near the end of November. Jc3s5h (talk) 18:16, 15 November 2015 (UTC)

This mailinglist thread states that the proposal to eliminate them is dead for now. —Steve Summit (talk) 17:22, 19 November 2015 (UTC)

Whoops! But now this mailinglist thread cites this reasonably definitive-looking press release. I'll update the article unless someone beats me to it. —Steve Summit (talk) 17:25, 19 November 2015 (UTC)

Negative Leap Seconds

I added a note about negative leap seconds which was quickly reverted by AstroLynx. The comment given was “discussing (negative) leap seconds before 1972 does appear to be useful here”. Where else but in an article on leap seconds would one discuss negative leap seconds? In order to avoid an edit war I am asking for a discussion. John Sauter (talk) 14:36, 18 May 2016 (UTC)

The practice of leap seconds was only introduced in 1972. What is the use of discussing leap seconds before 1972? AstroLynx (talk) 16:54, 18 May 2016 (UTC)

My intent is to correct this sentence: “However, negative leap seconds have never been needed since the UTC standard was established, and are highly unlikely to ever be.” First, the UTC standard was established earlier than 1972, but did not include leap seconds until 1972. Correcting this would result in “However, negative leap seconds have never been needed since leap seconds started in 1972, and are highly unlikely to ever be.” The second problem is that “are highly unlikely to ever be” is a judgment not supported by any reference. It would be adequate to simply remove it, but I tried to do better by mentioning that in the recent past (1885) the rotation rate of the Earth would have required a negative leap second if leap seconds had existed. John Sauter (talk) 17:14, 18 May 2016 (UTC)

Such a discussion could be useful further down in the article. The opening paragraph of this article is already rather long and should not be burdened with too much information. There might be a problem however with the source which you propose to add as it seems to be mainly based on WP:OR. AstroLynx (talk) 10:41, 19 May 2016 (UTC)

Would it be acceptable to delete the offending sentence, and add a section on negative leap seconds? Perhaps it would be better to move all but the first paragraph pf the lead into the body, change Insertion of Leap Seconds to Scheduling of Leap Seconds, and add subsections on positive and negative leap seconds. John Sauter (talk) 00:31, 20 May 2016 (UTC)

I support removing the sentence from the lead. The second paragraph of the lead is pretty thick if anyone wants to do some additional trimming. Scheduling of leap seconds seems like an improved title for the second section. The end of this section would be a good place to mention negative leap seconds because the next section is Slowing of the Earth. I don't think subsections are necessary to cover negative and positive. ~Kvng (talk) 14:02, 24 May 2016 (UTC)

Since the Earth is slowing down (and I do not think it would be too hard to find references for this), the unlikeliness of negative leap seconds is quite obvious. C.f. the graph in the article ΔT. — Edgar.bonet (talk) 19:06, 19 May 2016 (UTC)

As I read the graph of LOD in this article, the Earth was completing a rotation in less than 86,400 seconds as recently as 2005. Looking at the graph you mentioned, notice that to obtain a negative leap second doesn't require that the graph go back to 0, but only that it slopes downward for a while. I don't think it is unreasonable to imagine that the Earth might speed up again in the next few decades, and next time it might be enough to cause a negative leap second. John Sauter (talk) 00:39, 20 May 2016 (UTC)

You are right, a negative leap second is not completely unreasonable. But the secular deceleration only makes it less and less likely. This deceleration is not visible in the LOD graph of this article, as it covers too short a time span. It is more obvious in the ΔT graph. — Edgar.bonet (talk) 09:58, 20 May 2016 (UTC)

In the long run, the Earth is slowing down. 3000 years ago, a positive leap second would have been completely unreasonable, and 3000 years from now, a negative leap second will be completely unreasonable. Today, however, both are within the realm of possibility. John Sauter (talk) 01:10, 21 May 2016 (UTC)

Notwithstanding the discussion of negative leap seconds here on the talk page, which concluded that negative leap seconds are possible, though unlikely, an editor has modified the article to say that negative leap seconds are not possible. I deleted the sentence in the lead that characterizes the likelihood of negative leap seconds. John Sauter (talk) 20:41, 21 May 2016 (UTC)

Table of announced leap seconds to date

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)

Fake screenshot

Showing 23:59:60 when there's still more than two hours to go! — Preceding unsigned comment added by 81.98.254.105 (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 62.235.4.230 (talk) 22:16, 30 June 2015 (UTC)

The layout and colors at Time.gov 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)

External links modified

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:

• Added archive http://www.webcitation.org/666iH0vl1?url=http://tycho.usno.navy.mil/leapsec.html to http://tycho.usno.navy.mil/leapsec.html

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

Y 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

Hello

From the reference provided by Wikipedia: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.52 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 (talk • contribs) 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

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 ${\frac {9,192,631,875}{9,192,631,770}}$ 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...”

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 (talk • contribs) 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)

External links modified

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:

• Added archive https://web.archive.org/web/20150505061854/https://www.theice.com/leap-second to https://www.theice.com/leap-second

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

Y 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)

dubious power utilities

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 (talk • contribs) 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 [2] 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 [3] 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)

IEC/IEEE 61850-9-3 reference

At the end of the second paragraph under “Proposal to abolish leap seconds” a reference was added to IEC/IEEE 61850-9-3 to support this sentence: “With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times larger than the required accuracy for industry clocks (1 microsecond for IEC/IEEE 61850-9-3).” The reference does not support the sentence because IEC/IEEE 61850-9-3 is based on TAI rather than UTC. Thus, it is a solution to the problem rather than a motivation to abolish leap seconds. John Sauter (talk) 20:59, 31 October 2018 (UTC)

The reference to IEC/IEEE 61850-9-3 is being used to support the fact that a 1 second jump is not acceptable behavior for many systems - in this case synchronization of the electrical grid. ~Kvng (talk) 15:49, 3 November 2018 (UTC)

Then would anyone object to breaking the sentence in two, for clarification, as follows: “With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times larger than the required accuracy for industry clocks. For example, IEC/IEEE 61850-9-3, which is used for synchronization of the electrical grid, uses TAI rather than UTC so it can have 1 microsecond accuracy.” John Sauter (talk) 17:07, 3 November 2018 (UTC)

That looks like an improvement to me. I think we could do even better but let's start there and see where it goes. ~Kvng (talk) 14:07, 6 November 2018 (UTC)

I made the update, but it was reverted with the comment “implies that TIA is more accurate than UTC”. My intent was to imply that TIA is more convenient than UTC for some purposes. Rather than get into an edit war, I invite the editor to discuss better wording here, on the talk page. John Sauter (talk) 22:55, 13 November 2018 (UTC)

Here is your proposed update:

For example, IEC/IEEE 61850-9-3, which is used for synchronization of the electrical grid, uses TAI rather than UTC so it can have 1 microsecond accuracy.

My issue is basically with so. Leap seconds don't fundamentally make clocks less accurate, they make them more complicated. It is problems in implementation where the "accuracy" problems arise. Something more like this could work for me:

For example, IEC/IEEE 61850-9-3, which is used for synchronization of the electrical grid, achieves 1 microsecond accuracy.

~Kvng (talk) 14:26, 16 November 2018 (UTC)

OK, so the IEC/IEEE 61850-9-3 page says that:

IEC/IEEE 61850-9-3 uses the following IEEE Std 1588 options:

• uses the PTP timescale based on TAI International Atomic Time, also delivers UTC Coordinated Universal Time

My copy of IEEE 1588 says:

5.3.3 Timestamp

The Timestamp type represents a positive time with respect to the epoch.

struct Timestamp {

UInteger48 secondsField;

UInteger32 nanosecondsField;

};

The secondsField member is the integer portion of the timestamp in units of seconds.

The nanosecondsField member is the fractional portion of the timestamp in units of nanoseconds.

and also says

7.2.2 Epoch

The epoch is the origin of the timescale of a domain.

The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC.

so I assume IEC/IEEE 61850-9-3 times are represented as counts of seconds and nanoseconds that have elapsed since 1 January 1970 00:00:00 TAI/31 December 1969 23:59:51.999918 UTC - where "that have elapsed" means that, during a leap second, the count increases just as it does during a normal second.

One could also use January 1970 00:00:00 UTC as an epoch, and again have the count increase just as it does during a normal second. Seconds/nanoseconds time stamps would, in the latter scale, forever be 8.000082 lower than those in the former scale (because a counter, in both cases, goes up by 1 nanosecond every nanosecond, regardless of whether that nanosecond elapses within a leap second or not). That time scale would not be POSIX time.

The complication introduced by UTC is in converting a count-of-seconds-and-nanoseconds-since-an-epoch time stamp to YYYY-MM-DD HH:MM:SS.FFFFFFFFF human-oriented representation converting that representation to such a time stamp. If the time stamp precedes the current time, that's doable - the sample code provided by the maintainers of the tz database can do it, using the leap-second database provided as part of the tz database - it's just more work for the code. If the time is in the future, however, you can't do the conversion and get a result guaranteed to be correct unless you know for certain what leap seconds will be introduced before the time in question.

I presume that, in human-oriented representation of TAI times, SS is always in the range 00-59, and always rolls over from 59 to 00, in which case the same algorithm for converting POSIX time to and from human-oriented representations, which doesn't take leap seconds into account, works. Guy Harris (talk) 20:11, 16 November 2018 (UTC)

Yes, IEC/IEEE 61850-9-3 and IEEE 1588 use TAI and don't have leap seconds. But that's not how they achieve 1 microsecond accuracy. You can have 1 microsecond accuracy using UTC time scale too, you just need to know the leap second behavior ahead of time. The 1-second jumps described in this section are due to uncareful implementation and dealing with simple or legacy systems that can't accomodate a 61st second. The mention of IEC/IEEE 61850-9-3 is useful because it demonstrates that there are common applications that require much better than 1 second clock accuracy; these jumps are unacceptable to these applications and abolishing leap seconds would eliminate them from all systems, those that can accomodate them smoothly and those that can't. None of this makes TAI more fundamentally accurate than UTC but that's what I read John Sauter's proposed changes as implying. ~Kvng (talk) 22:51, 16 November 2018 (UTC)

OK, how about this: “With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times larger than the required accuracy for industry clocks. For example, IEC/IEEE 61850-9-3, which is used for synchronization of the electrical grid, uses TAI rather than UTC so it can have 1 microsecond accuracy without the need for a table of leap seconds.” John Sauter (talk) 19:20, 17 November 2018 (UTC)

The offending paragraph says:

The irregularity and unpredictability of UTC leap seconds is problematic for several areas, especially computing. For example, to compute the elapsed time in seconds between two given UTC past dates requires the consultation of a table of leap seconds, which needs to be updated whenever a new leap second is announced. Moreover, it is not possible to compute accurate time intervals for UTC dates that are more than about six months in the future. Most time distribution systems (SNTP, IRIG-B, PTP) only announce leap seconds at most 12 hours in advance and sometimes only in the last minute. With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times larger than the required accuracy for industry clocks (1 microsecond for IEC/IEEE 61850-9-3).

I'm still not sure in what way IEC/IEEE 61850-9-3 is relevant.

TAI (as in "representing dates and times as YYYY-MM-DD HH:MM:SS.{fraction}, with a particular instant in time being identified as 1958-01-01 00:00:00, and with the seconds counter always going from 59 to 00 and carrying into the higher-order parts of the date and time"), UTC (as in "representing dates and times as YYYY-MM-DD HH:MM:SS.{fraction}, by taking the TAI representation of the date and time and adjusting it based on the then-in-effect delta between TAI and UTC, in a fashion that may cause the seconds counter to go from 59 to 60 and then to 00 and carrying, or to go from 58 to 00 and then carrying, or..."), PTP (IEEE 1588) time (as in "representing dates and times as a count of seconds and nanoseconds of seconds that have elapsed since some specified point in time"), POSIX time (as in "representing dates and times as a count of "seconds since the Epoch" and fractions of a second, where "seconds since the Epoch" doesn't count leap seconds, so every day is exactly 86400 seconds long"), NTP time, etc. are all mechanisms for assigning labels to particular instants of time.

IEEE 1588, and thus IEC/IEEE 61850-9-3, only "uses TAI" to the extent that "The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC." It doesn't represent dates and times as YYYY-MM-DD HH:MM:SS.{fraction}, it represents them as a 48-bit count of seconds and a 32-bit count of nanoseconds, so it doesn't "use TAI" in the sense of using TAI's labeling. And users of PTP could, in theory, use 1 January 1970 00:00:00 UTC - i.e., the POSIX epoch - as long as they all agree to use that rather than the PTP epoch.

POSIX time only "uses UTC" to the extent that the POSIX epoch is 1 January 1970 00:00:00 UTC". It doesn't represent dates and times as YYYY-MM-DD HH:MM:SS.{fraction}, it represents them as counts of seconds and (with APIs other than time()) fractions of a second, so it doesn't "use UTC" in the sense of using UTC's labeling. Furthermore, if you use gmtime() in a POSIX-conformant system to translate a POSIX time to a UTC-like label, it won't ever give a label with 60 as the seconds value, so it doesn't generate UTC labels, it just generates UTC-like labels.

When it comes to leap seconds:

• TAI labels mostly have no problem - you can subtract two TAI labels (as long as you can predict leap years) to get a time delta without needing a table of leap seconds, and you can, given a "seconds and fractions of a second that have elapsed since some epoch" label for some instant in time, convert it to a TAI label for the same instant in time without needing a table of past leap seconds or a prediction of future leap seconds. Converting between TAI and UTC labels, of course, has the usual leap second problems.

• UTC labels have problems - for times preceding the next point in the future at which a leap second might be inserted, you can subtract two UTC labels (as long as you can predict leap years) to get a time delta, and you can, given a "seconds and fractions of a second that have elapsed since some epoch" label for some instant in time, convert it to a UTC label for the same instant in time, but you need a table of leap seconds in order to do so, and that means that, for times at or past the next point in the future at which a leap second might be inserted, you have to guess what leap seconds might be inserted, and, if your guess turns out to be wrong, fix up the conversion.

• PTP labels mostly have no problem - you can subtract two PTP labels to get a time delta without needing a table of leap seconds, and you can convert a TAI label to a PTP label. Converting between PTP and UTC labels, of course, has the usual leap second problems.

• POSIX labels have problems - if you want to subtract two POSIX labels to get a time delta, you'd have to add in leap seconds with a leap-second table if you want the delta to be "number of seconds that elapsed between the two instants represented by the two labels" rather than "number of seconds that elapsed between the two instants represented by the two labels, give or take leap seconds, it doesn't have to be that accurate", and you can't convert a UTC label for an instant of time during a leap second to a POSIX label. Converting other UTC labels to POSIX labels, however, doesn't have a leap second problem.

So which one you use depends on, among other things, which problems you need to worry about. If you're going to be dealing with humans, you're probably going to use UTC or TAI labels somewhere, even if you use, for example, PTP times internally as much as possible, as more people are likely to know what 2018-12-06 00:00:00 UTC, or even 2018-12-06 00:00:00 TAI, is than what 1544054400 is. If you're using UTC labels anywhere, you may have to deal with leap seconds in some fashion.

If you use PTP times internally, and TAI when you show dates and times to or get dates and times from humans, leap seconds won't matter. If you use PTP times internally, and UTC when you show dates and times to or get dates and times from humans, leap seconds will be an issue every time you convert from PTP time to UTC.

So PTP, and thus IEC/IEEE 61850-9-3, doesn't seem to be worthy of note here. UTC vs. TAI is, but, again, it's not as if PTP "uses TAI rather than UTC" to any degree other than the struct Timestamp values differing by the TAI-UTC difference as of 1 January 1970. If PTP had used 1 January 1970 00:00:00 UTC rather than 1 January 1970 00:00:00 TAI as its epoch, that wouldn't introduce any leap seconds issues. Guy Harris (talk) 21:14, 17 November 2018 (UTC)

IEC/IEEE 61850-9-3 is relavent because it demonstrates the need for high-precision timing in industrial applications, in this case the electric grid. Do you have an alternative proposal for the text? John Sauter (talk) 12:06, 19 November 2018 (UTC)

Presumably you mean "the fact that people bothered to specify microsecond resolution in IEC/IEEE 61850-9-3 demonstrates the need for high-precision timing in industrial applications..." - "we have to conform to IEC/IEEE 61850-9-3" isn't the reason why there's a need for high-precision timing, the need for high-precision timing is the reason why IEC/IEEE 61850-9-3 specifies microsecond resolution. There is presumably something else that's the reason why microsecond resolution is necessary.

One possibility is

The irregularity and unpredictability of UTC leap seconds is problematic for several areas, especially computing. For example, to compute the elapsed time in seconds between two given UTC past dates requires the consultation of a table of leap seconds, which needs to be updated whenever a new leap second is announced. Moreover, it is not possible to compute accurate time intervals for UTC dates that are more than about six months in the future. Most time distribution systems (SNTP, IRIG-B, PTP) only announce leap seconds at most 12 hours in advance and sometimes only in the last minute. With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times or more larger than the required accuracy for industry clocks; for example, the electrical power generation industry has specified, in IEC/IEEE 61850-9-3, 1 microsecond resolution for clocks.

That indicates that IEC/IEEE 61850-9-3 isn't the reason that 1 microsecond resolution is required; instead, it leaves the reason unspecified, leaving it implied that they wouldn't have specified 1 microsecond resolution if it weren't necessary. If somebody has an explicit "we specified 1 microsecond resolution because..." reference, that would be even better; if somebody wants that paragraph to just say "for example, the electrical power generation industry expects 1 microsecond accuracy for clocks", without bothering to mention IEC/IEEE 61850-9-3 at all, that would also be OK by me.

It also doesn't speak of that protocol "using" TAI rather than UTC; as I indicated, the only ways in in which it "uses" TAI is that 1) the PTP epoch happens to have more 0's in the time portion when expressed as TAI rather than UTC and 2) it doesn't throw in a POSIX-style ""seconds since the Epoch" doesn't mean all seconds that have elapsed since the Epoch" hack. It doesn't transmit TAI times over the network, it transmits "seconds and nanoseconds since 31 December 1969 23:59:51.999918 UTC" times over the network. Guy Harris (talk) 17:45, 19 November 2018 (UTC)

Just getting caught up here. The most recent proposal from John Sauter still has the so that led me to revert his original contribution. What Guy Harris suggests is making an argument for eliminating leap seconds and is flirting with WP:OR in so doing. I don't think we need to go so deep here. What we need is a simple statement that demonstrates that 1 second is not accurate enough for modern synchronization applications and that real-world implementations of timescales with leap seconds don't always achieve that. ~Kvng (talk) 15:16, 22 November 2018 (UTC)

"What @Guy Harris suggests is making an argument for eliminating leap seconds" "Eliminating" in what sense? And as for WP:OR, I don't think that applies to talk pages (and think it'd be silly if WP:OR did apply to talk pages). Guy Harris (talk) 17:25, 22 November 2018 (UTC)

And about the only change I'd recommend might be to, as I suggested above, change the paragraph to:

The irregularity and unpredictability of UTC leap seconds is problematic for several areas, especially computing. For example, to compute the elapsed time in seconds between two given UTC past dates requires the consultation of a table of leap seconds, which needs to be updated whenever a new leap second is announced. Moreover, it is not possible to compute accurate time intervals for UTC dates that are more than about six months in the future. Most time distribution systems (SNTP, IRIG-B, PTP) only announce leap seconds at most 12 hours in advance and sometimes only in the last minute. With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump often a million times or more larger than the required accuracy for industry clocks; for example, the electrical power generation industry has specified, in IEC/IEEE 61850-9-3, 1 microsecond resolution for clocks.

to further clarify why we're bothering to mention IEC/IEEE 61850-9-3 - it's being mentioned to indicate that there are applications where microseconds matter, not to directly say anything about leap seconds or about TAI vs. UTC, as it's not directly relevant to that issue (and any claim that it is would be a real case of WP:OR).

Or we could simply remove the mention of IEC/IEEE 61850-9-3 completely, and give some other indication + citation of how microsecond/nanosecond timing is relevant in some applications. Guy Harris (talk) 20:52, 22 November 2018 (UTC)

What bothers me about the reference to IEC/IEEE 61850-9-3 is that the section is named "Proposal to abolish leap seconds". The cited standard illustrates the need for high precision timing, but also solves the problem of leap seconds, not by eliminating them but by using the TAI time scale instead of UTC. To refer to the standard but not mention that it undermines the arguments in the section doesn't seem right. I vote for eliminating the reference to the standard from this paragraph. The last sentence could read “With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump larger than the required accuracy for industry clocks.” John Sauter (talk) 15:53, 23 November 2018 (UTC)

1) In what fashion does IEC/IEEE 61850-9-3 "[use] the TAI time scale instead of UTC", rather than defining its own time scale as seconds and nanoseconds, not bothering with days, hours and minutes, since an epoch that is not the TAI 1 January 1958 epoch?

2) In what fashion does citing IEC/IEEE 61850-9-3 purely as a system providing microsecond resolution cause a problem? A system could use IEC/IEEE 61850-9-3 to maintain time internally in the PTP time scale, and then convert between it and TAI or UTC when dealing with humans. The conversion to TAI is uncomplicated (it involves converting either to days, hours, minutes, seconds, and fractions of a second or to a date and hours/minutes/seconds and fractions); the conversion to UTC is complicated, involving a leap second table (the sample code supplied by the tz database maintainers is an example of how to do such a conversion), and doesn't work for future times at or past the first point at which a leap second could be inserted by at which it hasn't yet been indicated whether there will be one inserted. If the system has to convert to UTC, using IEC/IEEE 61850-9-3 doesn't solve the leap second problem, it just pushes it out to the point at which conversion to and from more human-friendly representation is done. Only if such a system uses TAI (or raw PTP time) when communicating with humans is there no leap-second problem.

And if that system can't use PTP or TAI when communicating with other computers - for example, if it has to use POSIX time or UTC - it would again have a leap-second problem. Guy Harris (talk) 18:09, 23 November 2018 (UTC)

While I agree with everything you say, you appear to be arguing about the justification for the change I proposed, rather than with the change itself. Consider this for the justification: “The cited standard illustrates the need for high precision timing, but also solves the problem of leap seconds by using a simple count of SI seconds since an epoch.” Would you then be happy with the suggested change to the last sentence: “With increasing requirements for accuracy in automation systems and high-speed trading, this raises a number of issues, as a leap second represents a jump larger than the required accuracy for industry clocks.” John Sauter (talk) 14:22, 25 November 2018 (UTC)

"The cited standard" only solves the problem if everything using it also uses TAI - if, at any point, a PTP time has to be converted to UTC (for example, for display), or a UTC time has to be converted to a PTP time (for example, from input from a user), "the problem of leap seconds" shows up, as you need a table of leap seconds to do such a conversion.

Unfortunately, given that, as far as I know, most if not all forms of civil time are based on UTC, not TAI, somebody involved in the process will probably be using UTC, so leap seconds will probably pop up somewhere in the process.

BTW, an earlier version of this page, with an edit by Hubert Kirrmann, said:

This request was presented to ITU-R at the Geneva meeting of October 2014. ITU-R postponed the decision to 2023 and advised TC57 to use TAI instead (minutes not public). Indeed, nothing would prevent IEC 61850 from allowing TAI right now for all technical operations and leave UTC for the human interface (the time stamps are the same). Unfortunately, IEC 61850-7-2 prescribes the use of the GMT and UTC time scales and does not mention TAI. UTilities that introduce TAI would be non-standard.

That standard speaks in section 6.1.2.9 "TimeStamp type" of a type that "shall represent a UTC time with the epoch of midnight (00:00:00) of 1970-01-01", indicating that a TimeStamp has three attributes:

• SecondSinceEpoch, which is a 32-bit unsigned "interval in seconds continuously counted from the epoch 1970-01-01 00:00:00 UTC";
• FractionOfSecond, which is a 24-bit unsigned "fraction of the current second when the value of the TimeStamp has been determined", and appears to be a binary fraction (1/2^'n' rather than 1/10^'n');
• TimeQuality, which is a list of sub-attributes, including LeapSecondsKnown, for which "The value TRUE of the attribute LeapSecondsKnown shall indicate that the value for SecondSinceEpoch contains all leap seconds occurred. If it is FALSE, then the value does not take into account the leap seconds that occurred before the initialization of the time source of the device. Instead the seconds since start of the epoch are calculated from the current date assuming a constant day length of 86 400 s."

so, if TimeQuality.LeapSecondsKnown is FALSE, it's keeping POSIX time, and if it's TRUE, it's keeping a non-POSIX-compliant time that's at a fixed offset from PTP time (the offset is the difference between 1970-01-01 00:00:00 TAI and 1970-01-01 00:00:00 UTC). The latter is the time that the tzdb sample code expects as input to, for example, gmtime() to convert to YYYY-MM-DD HH:MM:SS as a UTC value, if the tzdb leap second information is being used.

"allowing TAI right now for all technical operations and [leaving] UTC for the human interface" still involves leap seconds; perhaps the theory is that it defers conversion to UTC, so that fewer places in the system do that conversion and thus fewer places in the system are at risk of problems due to leap seconds.

As for what the page should say, at this point I'd just say that we should, in the paragraph in question, just give examples of industries requiring microsecond-or-better timing, preferably with direct citations for the requirement rather than "this industry uses protocol XXX with a profile specifying microsecond timing, so this industry requires microsecond timing", and should not say anything about the use of TAI, or of a time scale that counts all seconds, as solving the problem of leap seconds, as only the complete elimination of leap seconds everywhere will solve the problem of leap seconds (rather than just moving the problem from one place to another). Guy Harris (talk) 20:38, 25 November 2018 (UTC)

I agree with your suggestion on the content of the paragraph, and I invite you to do the edit. John Sauter (talk) 13:59, 26 November 2018 (UTC)

Networked media is one area that requires precise timing. Some information on these requirements can be found in RFC 7164, RFC 7272 and RFC 7273. ~Kvng (talk) 13:56, 29 November 2018 (UTC)

Television is another example of an industry that requires precise timing. SMPTE ST-2059-2 uses PTP and specifies an epoch of 63,072,010 seconds before January 1, 1972, 00:00 UTC. That is equivalent to December 31, 1969, at 23:59:50 UTC. I have seen this date referred to as the “1970 epoch” by contrast with the “1958 epoch”. Unfortunately this SMPTE standard is hard to cite--I have not been able to locate a non-paywalled copy of it on the web. John Sauter (talk) 19:13, 1 December 2018 (UTC)

References

Moving reference longitude

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 70.116.95.245 (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)

Well, we need to separate two matters here:

• First, "universal time will no longer correspond to mean solar time" (seemingly the core objection) is all sorts of nonsense – there would always be somewhere that a time standard (with or without leap seconds) does correspond to local mean solar time; I'll call that the "nominal meridian" of the time standard. That meridian will move around; indeed, for UTC with leap seconds, that meridian drifts steadily, with each leap second jumping it back a way (each second of drift or jump equating to a quarter arc-minute of longitude; about 289m at Greenwich's latitude); ditching leap seconds would just mean no longer trying to keep UTC's nominal meridian close to Greenwich (it currently always stays within Greenwich Park). Which, from a time-keeping point of view, is entirely unproblematic. However…
• Longitude is measured from The Prime Meridian, which happens to be the one through Greenwich; of course, that's why UTC chose it. So the benefit (such as it is) of leap seconds is that our time-keeping and our geography have a nice easy relationship: keeping the nominal meridian for UTC within Greenwich Park ensures that every time-zone's nominal meridian has (give or take the width of Greenwich Park) some tidy multiple of 15 degrees as its longitude. Nice and easy to keep track of.

Then again, I'm not convinced it's really that important, in much the same way that the difference between magnetic and celestial North is seldom a big deal (and, where it is, it's usually easy enough to take into account). The nominal meridian of a time standard, after all, is only where mean solar time matches it; if we look at the meridian at which current local solar time matches the standard, the equation of time's 32-minute range amounts to 8 whole degrees of seasonal longitude variation every year (so UTC's meridian swings from Swansea to Rotterdam, roughly). Given how little trouble that causes, it's hard to see how an arc-minute or two of drift per decade could cause any real problem. I can also see how folk might enjoy having the time-keeping meridian come to "visit them", with different parts of the world getting to enjoy hosting it, as the centuries pass; and, as each zone's meridian drifts, different parts of the zone get to experience the subtly different consequences of being how far east or west of it. 84.212.163.209 (talk) 17:04, 7 April 2019 (UTC) Eddy.