5 ms·

Is there a reason why a leap second wouldn't be added if the difference between TAI and UTC is 35s?

by kintamanimatt 12y ago

fsk 12y ago
35s is the cumulative sum of all leap seconds so far
- kintamanimatt 12y ago
  Follow-up question: what's the condition for a leap second to be added?
  - viraptor 12y ago
    Changes in Earth rotation speed. Have a look at wikipedia's "Leap second". It's explained pretty well with some historic data.
- oofabz 12y ago
  It sounds like the leap seconds all have the same sign. If corrections are always being applied in the same direction, that implies a second is not as close to 1/86400 of a solar day as it could be. Maybe we should redefine the second. It is currently defined as "9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom." 9,192,631,770 * 35s / 40y ~= 255. If we adjust the definition by 255 periods, TIA and UTC would stay in sync much better.
  - jebeck 12y ago
    While all leap seconds so far have been positive, that is not a requirement. Negative leap seconds are a possibility - one accounted for in any valid implementation. More significant for this particular suggestion, leap seconds do not occur/become necessary on any nice linear basis. They are tragically bound to the rotation of the Earth, which does not care about what would be nice for us and changes in a non-linear fashion.
  - vilhelm_s 12y ago
    The basic problem is that the solar day keeps getting longer. The definition of the second was based on a length-of-day averaged over the 19th century, so now it's too short. We could keep redefining the second every so often, but that sounds even worse than the system we have now. :)
  - gpvos 12y ago
    Scientists would hate you if you redefined the second by such a large amount. And since we've delegated the definition of a second to scientists (notably physicists), it's not going to happen.
taejo 12y ago
Leap seconds are added to UTC to keep it within one second of UT1; the drift from TAI is unbounded. In TAI, each second is the same length, and each day lasts the same number of seconds; UT1 is (conceptually, approximately) the solar time in Greenwich, so the length of seconds depends on the position of the earth; UTC has seconds of fixed length, like TAI, but occasionally has more or (potentially) fewer seconds in a day, to keep synch with UT1. If you used TAI, eventually the sun would not be overhead at noon -- and after many millennia, the sun would be up during the "night" and down during the "day" (after around 70 000 years if leap seconds continue to be added at the same rate, but the whole point is that they aren't -- at the moment they seem to be accelerating).
- ggreer 12y ago
  Thank you for explaining the various time standards concisely. I think a lot of people don't know about TAI, but would prefer it to UTC if they did. Leap second handling has been responsible for some pretty serious software bugs. It's so bad that Google doesn't use them internally. I think it makes the most sense for computers to use TAI internally, and have UTC as a time zone on top of that. Whenever there's a leap second, just push out a TZ update. Most applications don't have special code for time zone updates, which means a lower likelihood of bugs. Using TAI internally would have another advantage: Computers with GPS receivers could just add 19 seconds to GPS time to get a very accurate TAI. (GPS time is defined to be 19 seconds behind TAI. That was UTC in 1980.)
  - gpvos 12y ago
    Using TAI internally would be much better than what we have now. But another problem is that leap seconds are only announced 6 months in advance, which is not enough to update all computing devices (including embedded ones, etc.). See Poul Henning Kamp's article linked elsewhere in this discussion for an idea on how to address that.
  - datenwolf 12y ago
    Actually the most sensible thing would be to just use UT1 for wall clock time. The deviation of a UT1 second to TAI second (`d/dT UT1(T) - T` where `T = TAI time`) is small enough that your average time signal distribution system (NTP, radio time signal, etc.) can not even resolve it (less than a microsecond). Yes, with GPS time distribution or checking against an atomic clock you can resolve it. But it doesn't really matter (even if you go the Google-way and "smear out" a leap second, the deviation is less than a ms which is below the resolution of most operating systems' scheduler tick length). Leap seconds are stupid, because they create discontinuities. Here's a nice picture: http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lang=en http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lan... At home I hacked a OpenNTP based time server to hand out UT1 instead of UTC. Right now it's based on a simple software patch, I yet have to a program to fetch the Bulletin B reports and parse them (ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat). I don't know what they're smoking over there, but they're giving UT1 deviation relative to UTC instead of TAI. So first you've to get to UTC from TAI (respecting the leap seconds, gah), just so that you can go to UT1. Why not simply publish the value for UT1 - TAI instead? Anyway everytime a report gets out, the clock rescaler in the UT1 timeserver gets adjusted apropriately (manually). In the long run I plan to make this a small embedded project that uses GPS time to stabilize a high precision temperature compensated crystal oscillator^1 (TXCO), maybe I'll add a rubidum clock either, just because. And this is then to act as a stratum 1 time server on my local network. ---- [1] from my work I know that those have way less short term jitter than "naked" rubidium clocks; most precision frequency normals that come in a nice box with buttons and a display are actually TXCOs that are frequency stabilized by a rubidium clock.

Is there a reason why a leap second wouldn't be added if the difference between TAI and UTC is 35s?

fsk 12y ago

35s is the cumulative sum of all leap seconds so far

kintamanimatt 12y ago
Follow-up question: what's the condition for a leap second to be added?
- viraptor 12y ago
  Changes in Earth rotation speed. Have a look at wikipedia's "Leap second". It's explained pretty well with some historic data.
oofabz 12y ago
It sounds like the leap seconds all have the same sign. If corrections are always being applied in the same direction, that implies a second is not as close to 1/86400 of a solar day as it could be. Maybe we should redefine the second. It is currently defined as "9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom." 9,192,631,770 * 35s / 40y ~= 255. If we adjust the definition by 255 periods, TIA and UTC would stay in sync much better.
- jebeck 12y ago
  While all leap seconds so far have been positive, that is not a requirement. Negative leap seconds are a possibility - one accounted for in any valid implementation. More significant for this particular suggestion, leap seconds do not occur/become necessary on any nice linear basis. They are tragically bound to the rotation of the Earth, which does not care about what would be nice for us and changes in a non-linear fashion.
- vilhelm_s 12y ago
  The basic problem is that the solar day keeps getting longer. The definition of the second was based on a length-of-day averaged over the 19th century, so now it's too short. We could keep redefining the second every so often, but that sounds even worse than the system we have now. :)
- gpvos 12y ago
  Scientists would hate you if you redefined the second by such a large amount. And since we've delegated the definition of a second to scientists (notably physicists), it's not going to happen.

taejo 12y ago

Leap seconds are added to UTC to keep it within one second of UT1; the drift from TAI is unbounded. In TAI, each second is the same length, and each day lasts the same number of seconds; UT1 is (conceptually, approximately) the solar time in Greenwich, so the length of seconds depends on the position of the earth; UTC has seconds of fixed length, like TAI, but occasionally has more or (potentially) fewer seconds in a day, to keep synch with UT1. If you used TAI, eventually the sun would not be overhead at noon -- and after many millennia, the sun would be up during the "night" and down during the "day" (after around 70 000 years if leap seconds continue to be added at the same rate, but the whole point is that they aren't -- at the moment they seem to be accelerating).

ggreer 12y ago
Thank you for explaining the various time standards concisely. I think a lot of people don't know about TAI, but would prefer it to UTC if they did. Leap second handling has been responsible for some pretty serious software bugs. It's so bad that Google doesn't use them internally. I think it makes the most sense for computers to use TAI internally, and have UTC as a time zone on top of that. Whenever there's a leap second, just push out a TZ update. Most applications don't have special code for time zone updates, which means a lower likelihood of bugs. Using TAI internally would have another advantage: Computers with GPS receivers could just add 19 seconds to GPS time to get a very accurate TAI. (GPS time is defined to be 19 seconds behind TAI. That was UTC in 1980.)
- gpvos 12y ago
  Using TAI internally would be much better than what we have now. But another problem is that leap seconds are only announced 6 months in advance, which is not enough to update all computing devices (including embedded ones, etc.). See Poul Henning Kamp's article linked elsewhere in this discussion for an idea on how to address that.
- datenwolf 12y ago
  Actually the most sensible thing would be to just use UT1 for wall clock time. The deviation of a UT1 second to TAI second (`d/dT UT1(T) - T` where `T = TAI time`) is small enough that your average time signal distribution system (NTP, radio time signal, etc.) can not even resolve it (less than a microsecond). Yes, with GPS time distribution or checking against an atomic clock you can resolve it. But it doesn't really matter (even if you go the Google-way and "smear out" a leap second, the deviation is less than a ms which is below the resolution of most operating systems' scheduler tick length). Leap seconds are stupid, because they create discontinuities. Here's a nice picture: http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lang=en http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lan... At home I hacked a OpenNTP based time server to hand out UT1 instead of UTC. Right now it's based on a simple software patch, I yet have to a program to fetch the Bulletin B reports and parse them (ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat). I don't know what they're smoking over there, but they're giving UT1 deviation relative to UTC instead of TAI. So first you've to get to UTC from TAI (respecting the leap seconds, gah), just so that you can go to UT1. Why not simply publish the value for UT1 - TAI instead? Anyway everytime a report gets out, the clock rescaler in the UT1 timeserver gets adjusted apropriately (manually). In the long run I plan to make this a small embedded project that uses GPS time to stabilize a high precision temperature compensated crystal oscillator^1 (TXCO), maybe I'll add a rubidum clock either, just because. And this is then to act as a stratum 1 time server on my local network. ---- [1] from my work I know that those have way less short term jitter than "naked" rubidium clocks; most precision frequency normals that come in a nice box with buttons and a display are actually TXCOs that are frequency stabilized by a rubidium clock.