3 ms·

Steve Allen is one of the more vocal proponents of leap seconds and knows much more than I do about the issue. However the general thesis that "Discontinuing le

by dfc 12y ago

Steve Allen is one of the more vocal proponents of leap seconds and knows much more than I do about the issue. However the general thesis that "Discontinuing leap seconds would require many observatories and other organizations to procure new hardware and rewrite software that deals with time and the earth's rotation" has always left something to be desired. I have never understood why the needs of a small minority (astronomers) should be the deciding factor for society as a whole. The argument for leap seconds would be a lot stronger if it did not seem like a tyranny of the minority.

acqq 12y ago
The leap seconds in the UTC aren't making any problem if the operating systems wouldn't do "unexpected" things with them, as described by Kuhn. Specifically, the software "clocks" for "humans," those that are bound to the calendar time, should just have 86400 seconds in a day. (2) When the atomic clocks signal them the "leap" second they should just "smooth" it. We can have that with some updates of our favourite operating systems. It's a pure software thing. The solution (UTC-SLS) is simple and good enough for most of the uses, including Google's synchronisation needs of the millions of their computers. The UTC is still just the to-the-second approximation of the UT1 (1) which is by definition bound to the Earth rotation ( http://en.wikipedia.org/wiki/Universal_Time http://en.wikipedia.org/wiki/Universal_Time ). Steve Allen just tries to make people understand that the UTC is by definition "the human calendar time" (like: year, month, day, hour, minute, second) sent over the radio clocks. For the time less dependent on Earth TAI also exists ( http://en.wikipedia.org/wiki/International_Atomic_Time http://en.wikipedia.org/wiki/International_Atomic_Time ). So we already have the time reference that "just counts the atomic seconds." Had there been less confusion among the programmers regarding the leap second handling on the common systems we'd already all use the UTC-SLS solution and we wouldn't have to care about the leap seconds unless we really need TAI. --- 1) Watch out for http://www.itu.int/en/ITU-R/conferences/wrc/2015/Pages/default.aspx http://www.itu.int/en/ITU-R/conferences/wrc/2015/Pages/defau... (2 to 27 November 2015) if that changes. 2) POSIX already specifies that every day has exactly 86400 seconds for "Seconds Since the Epoch" and the current code relies on that: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
- dfc 12y ago
  Why deal with the complexity of leap seconds; given TAI why should society as a whole deal with the complexity of leap seconds just because it makes life a little easier for astronomers?
  - acqq 12y ago
    It's not about being easy for the astronomers but for the humans. The astronomers already have to use all of TAI, UT0, UT1 and UTC and much more complex calculations. We other humans use days. We have the daylight saving time and nobody cares for an hour difference twice a year because those who do care use the less moving time stamps, often called UTC, even if they are just "synchronized with UTC" and not exactly UTC, as they have in POSIX-inspired systems exactly 86400 seconds in a day, always. Only some of the programmers then "discover" the definition of the leap second and remain confused by the fact that their computers use "UTC" name and wrongly think that the exact leap seconds are important for them even if they only need the calendar time. If you use the POSIX time routines (and you almost certainly do use them unless you tweaked something wrongly) you already don't have to deal with the complexities of the leap seconds (but you should care about DST!) Every day in what POSIX calls "Seconds Since the Epoch" (but is sometimes referred to as UTC) has in fact the same number of seconds (if you know C it's what you get in time_t for all the time stamps). Only the OS-es have to be fixed to smooth the leap seconds instead of introducing them at once, and then even some obscure sync bugs will never happen any more. Google proved that it's a good approach.

by dfc 12y ago

acqq 12y ago

The leap seconds in the UTC aren't making any problem if the operating systems wouldn't do "unexpected" things with them, as described by Kuhn. Specifically, the software "clocks" for "humans," those that are bound to the calendar time, should just have 86400 seconds in a day. (2) When the atomic clocks signal them the "leap" second they should just "smooth" it. We can have that with some updates of our favourite operating systems. It's a pure software thing. The solution (UTC-SLS) is simple and good enough for most of the uses, including Google's synchronisation needs of the millions of their computers. The UTC is still just the to-the-second approximation of the UT1 (1) which is by definition bound to the Earth rotation ( http://en.wikipedia.org/wiki/Universal_Time http://en.wikipedia.org/wiki/Universal_Time ). Steve Allen just tries to make people understand that the UTC is by definition "the human calendar time" (like: year, month, day, hour, minute, second) sent over the radio clocks. For the time less dependent on Earth TAI also exists ( http://en.wikipedia.org/wiki/International_Atomic_Time http://en.wikipedia.org/wiki/International_Atomic_Time ). So we already have the time reference that "just counts the atomic seconds." Had there been less confusion among the programmers regarding the leap second handling on the common systems we'd already all use the UTC-SLS solution and we wouldn't have to care about the leap seconds unless we really need TAI. --- 1) Watch out for http://www.itu.int/en/ITU-R/conferences/wrc/2015/Pages/default.aspx http://www.itu.int/en/ITU-R/conferences/wrc/2015/Pages/defau... (2 to 27 November 2015) if that changes. 2) POSIX already specifies that every day has exactly 86400 seconds for "Seconds Since the Epoch" and the current code relies on that: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

dfc 12y ago
Why deal with the complexity of leap seconds; given TAI why should society as a whole deal with the complexity of leap seconds just because it makes life a little easier for astronomers?
- acqq 12y ago
  It's not about being easy for the astronomers but for the humans. The astronomers already have to use all of TAI, UT0, UT1 and UTC and much more complex calculations. We other humans use days. We have the daylight saving time and nobody cares for an hour difference twice a year because those who do care use the less moving time stamps, often called UTC, even if they are just "synchronized with UTC" and not exactly UTC, as they have in POSIX-inspired systems exactly 86400 seconds in a day, always. Only some of the programmers then "discover" the definition of the leap second and remain confused by the fact that their computers use "UTC" name and wrongly think that the exact leap seconds are important for them even if they only need the calendar time. If you use the POSIX time routines (and you almost certainly do use them unless you tweaked something wrongly) you already don't have to deal with the complexities of the leap seconds (but you should care about DST!) Every day in what POSIX calls "Seconds Since the Epoch" (but is sometimes referred to as UTC) has in fact the same number of seconds (if you know C it's what you get in time_t for all the time stamps). Only the OS-es have to be fixed to smooth the leap seconds instead of introducing them at once, and then even some obscure sync bugs will never happen any more. Google proved that it's a good approach.