[PROPOSED 1/2] Don’t be so sure about leap seconds going away
* NEWS, theory.html (Leap seconds): * tz-link.html (Precision timekeeping): Use less-sure wording about leap seconds discontinuance, since the situation is still murky. --- NEWS | 2 +- theory.html | 10 +++++----- tz-link.html | 1 + 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 5c2cd1e5..e5db26b4 100644 --- a/NEWS +++ b/NEWS @@ -322,7 +322,7 @@ Release 2023a - 2023-03-22 12:39:33 -0700 To improve tzselect diagnostics, zone1970.tab's comments column is now limited to countries that have multiple timezones. - Note that leap seconds are planned to be discontinued by 2035. + Note that there are plans to discontinue leap seconds by 2035. Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/theory.html b/theory.html index 50e9ee4d..4cb293da 100644 --- a/theory.html +++ b/theory.html @@ -1278,11 +1278,11 @@ between now and the future time. <p> Leap seconds were introduced in 1972 to accommodate the difference between atomic time and the less regular rotation of the earth. -Unfortunately they caused so many problems with civil -timekeeping that they -are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned -to be discontinued by 2035</a>. -Despite their impending obsolescence, a record of leap seconds is still +Unfortunately they have caused so many problems with civil +timekeeping that there are +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">plans +to discontinue them by 2035</a>. +Even if these plans come to fruition, a record of leap seconds will still be needed to resolve timestamps from 1972 through 2035. </p> diff --git a/tz-link.html b/tz-link.html index c6d96101..aaab7555 100644 --- a/tz-link.html +++ b/tz-link.html @@ -1129,6 +1129,7 @@ discontinuous adjustments be made to UTC for at least a century. The World Radiocommunication Conference <a href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved in 2023</a> to cooperate with this process. +However, there is still no consensus on how exactly to get rid of them. </li> </ul> </section> -- 2.40.1
* zic.8: Mention SMPTE timecodes as a possible application of rolling leap seconds. --- zic.8 | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zic.8 b/zic.8 index 34cdcea7..11a31ec3 100644 --- a/zic.8 +++ b/zic.8 @@ -773,16 +773,16 @@ or if the leap second time given by the other fields should be interpreted as local (wall clock) time. .PP -Rolling leap seconds were implemented back when it was not -clear whether common practice was rolling or stationary, -with concerns that one would see +Rolling leap seconds would let one see Times Square ball drops where there'd be a .q "3... 2... 1... leap... Happy New Year" countdown, placing the leap second at midnight New York time rather than midnight UTC. -However, this countdown style does not seem to have caught on, -which means rolling leap seconds are not used in practice; -also, they are not supported if the +Although stationary leap seconds are the common practice, +rolling leap seconds can be useful in specialized applications +like SMPTE timecodes that may prefer to put leap second +discontinuities at the end of a local broadcast day. +However, rolling leap seconds are not supported if the .B \*-r option is used. .PP -- 2.40.1
participants (1)
-
Paul Eggert