Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment first proposed in 2004, not resolved before 2024 (Score 2) 143

The first proposal to abandon leap seconds was presented to the ITU-R in 2004, and subsequent versions have been rejected for over a decade. It is evident that the usual process of ITU-R decisions is not capable of coming to agreement on the subject of leap seconds. It remains to be seen whether they will produce a new framework for studies which can produce an agreement in 8 years.

Comment Re:If you can't deal, don't use UTC (Score 1) 291

I wish we lived in a world where regulators paid attention to astronomers. Astronomers were the ones who warned that implementing leap seconds was a bad idea (see the section "Coordinated Time" starting on page 345). Nobody listened to astronomers then, and astronomers have not gained such powers in the ensuing 45 years.

Comment Why this has been debated for 15 years (Score 1) 291

The ITU-R first received this issue as Question 236/7 in year 2001. They have spent nearly 15 years coming up with this list of 6 methods for dealing with leap seconds. In that note the most recent "Method D" from a group of countries who prefer no change because they are not satisfied with the documents that have been submitted to the ITU-R during the past decade.

The debate continues because it is not a technical issue. We know how to count SI seconds by physicists watching cesium atoms, and we know how to count calendar days by astronomers watching the earth rotate. The question is about time producers and time consumers -- which of the time producers will have the hegemony, and whether the time consumers have enough agency to choose what time scale to use for their applications. The question is whether the days of the civil calendar will remain related to the rotating earth, or change to be 794 243 384 928 000 hyperfine oscillations of cesium-133.

Comment Re:Daily adjustments? (Score 1) 233

Been there, did that, in the US from about 1957, the US and UK starting in 1960, and internationally from 1961 until 1972. The authorities in charge of the distribution of time utterly rejected that in favor of leap seconds. Then they went on a world tour getting agencies and governments to officially adopt UTC with leap seconds as the perfect time scale for all purposes.

Comment Re:We should do what GPS does (Score 1) 233

The designers of GPS system time did understand. GPS system time is *about* 19 seconds behind TAI, not exactly 19, and the difference varies by nanoseconds. Perhaps nanoseconds is unimportant to some, but for others nanoseconds is very important. That makes them not the same, so choosing a separate name and offset avoided any confusion that they were the same. Think of it like a trademark issue; there are many kinds of cola, but TAI is a name for the original cola, and only BIPM is authorized to make cola with the name TAI.

Comment Re:Buggy software is buggy (Score 1) 233

Take another look at Method D, which was just added in March: "No change to the Radio Regulations as the results of the studies are inconclusive." This is one group of delegations going on official record saying that all the effort expended by the ITU-R over the past 15 years has been worthless for making any decision to change the definition of UTC. That is serious disagreement.

Comment choose what standard to violate (Score 4, Informative) 233

A problem for sysadmins is that the status quo of the standards requires that we choose which standard we want to violate. We can violate the specification of UTC by not counting 23:59:60 or we can violate POSIX by counting it or we can violate POSIX and the SI second by not actually keeping the system clock on UTC using smeared seconds that are not suitable for tracking projectiles and other real-time applications. This problem is old, 50 years old, as seen in the 3 plots on this web page.

Slashdot Top Deals

Old programmers never die, they just become managers.