F-ckin Leap Seconds, how do they work?
http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. On 6/30/12, Paul WALL <pauldotwall@gmail.com> wrote:
Comments?
Drive Slow Paul
-- -JH
See International Earth Rotation Service, http://www.iers.org/, particularly http://data.iers.org/products/6/15003/orig/bulletina-xxv-026.txt Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Jun 30, 2012 at 9:16 PM, Paul WALL <pauldotwall@gmail.com> wrote:
Comments?
Drive Slow Paul
From: Paul WALL <pauldotwall@gmail.com> Subject: F-ckin Leap Seconds, how do they work?
Comments?
Addressing the Subject question, _as_asked_ -- "Very well". *SNORT* Mechanically, instead of rolling over from second #59 to second #0 of the next minute, it goes 59->60->0. The 'why' is to keep terrestrial clocks in sync with celestial references.
----- Original Message -----
From: "Robert Bonomi" <bonomi@mail.r-bonomi.com>
Subject: F-ckin Leap Seconds, how do they work?
Comments?
Addressing the Subject question, _as_asked_ -- "Very well".
*SNORT*
Yes. But I'm sure the reference was to the Insane Clown Posse spawned meme, which rapidly became popular with liberals, dissing the apparentl distaste of conservatives for the scientific method: http://knowyourmeme.com/memes/fcking-magnets-how-do-they-work Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 6/30/2012 3:16 PM, Paul WALL wrote:
Comments?
Drive Slow Paul
Not very well if you have a modern box (RHES/CentOS 6) and Java apps running on them. RHES/CentOS 5 merrily ignored it. Worse, just bouncing the Java stack didn't fix it, it required the box to be rebooted. A sizeable number of annoyed sysadmins tweeting about it this afternoon. Paul
Hi!
Drive Slow Paul
Not very well if you have a modern box (RHES/CentOS 6) and Java apps running on them. RHES/CentOS 5 merrily ignored it. Worse, just bouncing the Java stack didn't fix it, it required the box to be rebooted. A sizeable number of annoyed sysadmins tweeting about it this afternoon.
Anything with java running seems hit. We just finished up a firm round of reboots... :( Recent Ubuntu boxes and RHES 6... all the same ... Bye, Raymond.
Anything with java running seems hit. We just finished up a firm round of reboots... :(
Recent Ubuntu boxes and RHES 6... all the same ...
Bye, Raymond.
Yeah, in the process of doing the same. http://news.ycombinator.com/item?id=4183122 Might try this for machines with Java applications in order to avoid reboot: https://bugzilla.mozilla.org/show_bug.cgi?id=769972 See comment 5
Anything with java running seems hit. We just finished up a firm round of reboots... :(
Recent Ubuntu boxes and RHES 6... all the same ...
Bye, Raymond.
Yeah, in the process of doing the same.
http://news.ycombinator.com/item?id=4183122
Might try this for machines with Java applications in order to avoid reboot:
https://bugzilla.mozilla.org/show_bug.cgi?id=769972
See comment 5
And we have verified that this clears the issue for us. YMMV.
We haven't had any issues with any of our VMs. We run several of our own Java/Tomcat apps, Jira, and Confluence on a mixture of Solaris and CentOS 5 and 6. We do not run NTP on our VMs though; instead, we rely on VMware Tools to sync the VMs' time with the ESXi hosts. The ESXi hosts run NTP. On 6/30/2012 11:16 PM, George Bonser wrote:
Anything with java running seems hit. We just finished up a firm round of reboots... :(
Recent Ubuntu boxes and RHES 6... all the same ...
Bye, Raymond.
Yeah, in the process of doing the same.
http://news.ycombinator.com/item?id=4183122
Might try this for machines with Java applications in order to avoid reboot:
https://bugzilla.mozilla.org/show_bug.cgi?id=769972
See comment 5
And we have verified that this clears the issue for us. YMMV.
Same here with KVM guests on Scientific Linux 6 (RHEL 6 clone) hosts. No issues on SL 6 and CentOS 5 guests. We also do not run NTP on the VMs, only on the hosts. The guest VM kernels did not log any leap second clock change, but appear to have the same time as the hosts. The hosts DID have issues though. The "reset the date" workaround solved the issue immediately, with no requirement to restart anything, including ntpd. The hosts logged leap second clock updates: Jun 30 19:59:59 vmhost kernel: Clock: inserting leap second 23:59:60 UTC My Fedora 16 laptop was also being sluggish due to chromium-browser sucking up CPU. That too was fixed immediately by resetting the date. On Sun, Jul 01, 2012 at 12:41:25AM -0400, Derek Ivey wrote:
We haven't had any issues with any of our VMs. We run several of our own Java/Tomcat apps, Jira, and Confluence on a mixture of Solaris and CentOS 5 and 6. We do not run NTP on our VMs though; instead, we rely on VMware Tools to sync the VMs' time with the ESXi hosts. The ESXi hosts run NTP.
On 6/30/2012 11:16 PM, George Bonser wrote:
Anything with java running seems hit. We just finished up a firm round of reboots... :(
Recent Ubuntu boxes and RHES 6... all the same ...
Bye, Raymond.
Yeah, in the process of doing the same.
http://news.ycombinator.com/item?id=4183122
Might try this for machines with Java applications in order to avoid reboot:
https://bugzilla.mozilla.org/show_bug.cgi?id=769972
See comment 5
And we have verified that this clears the issue for us. YMMV.
Talk about people not testing things, leap seconds have been around since 1961. There have been nine leap seconds in the last twenty years. Any system that can't handle a leap second is seriously flawed.
-----Original Message----- From: Roy Sent: Saturday, June 30, 2012 10:03 PM To: nanog@nanog.org Subject: Re: F-ckin Leap Seconds, how do they work?
Talk about people not testing things, leap seconds have been around since 1961. There have been nine leap seconds in the last twenty years. Any system that can't handle a leap second is seriously flawed.
Roy, this was a problem in only certain kernel versions. Unfortunately the range of versions affected are pretty widely deployed right now. Earlier and later versions did not have the problem.
Do you happen to know all the kernels and versions affected by this? -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 7/1/12 12:44 PM, George Bonser wrote:
-----Original Message----- From: Roy Sent: Saturday, June 30, 2012 10:03 PM To: nanog@nanog.org Subject: Re: F-ckin Leap Seconds, how do they work?
Talk about people not testing things, leap seconds have been around since 1961. There have been nine leap seconds in the last twenty years. Any system that can't handle a leap second is seriously flawed.
Roy, this was a problem in only certain kernel versions. Unfortunately the range of versions affected are pretty widely deployed right now. Earlier and later versions did not have the problem.
----- Original Message -----
From: "Alex Harrowell" <a.harrowell@gmail.com>
On 02/07/12 16:47, AP NANOG wrote:
Do you happen to know all the kernels and versions affected by this?
2.6.26 to 3.3 inclusive per news.ycombinator.com/item?id=4183122
Well, my 2.6.32 CentOS6/64 machine, which is not running Java, just purred right along, logging the leapsecond at 7pm, and not even blinking, so... (Amazon EC2, NTP enabled; 3 strat-2s from us.pool) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 07/02/2012 09:04 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Alex Harrowell" <a.harrowell@gmail.com> On 02/07/12 16:47, AP NANOG wrote:
Do you happen to know all the kernels and versions affected by this? 2.6.26 to 3.3 inclusive per news.ycombinator.com/item?id=4183122 Well, my 2.6.32 CentOS6/64 machine, which is not running Java, just purred right along, logging the leapsecond at 7pm, and not even blinking, so... (Amazon EC2, NTP enabled; 3 strat-2s from us.pool)
My centos 6/64 running 3.0 seemed to weather it too. I'm not quite clear on what I should be looking for to classify it as being "broken" though. Mike
Made the press.. http://www.washingtonpost.com/business/technology/leap-second-bug-takes-down... -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -
On Mon, Jul 02, 2012 at 09:13:42AM -0700, Michael Thomas wrote:
My centos 6/64 running 3.0 seemed to weather it too. I'm not quite clear on what I should be looking for to classify it as being "broken" though.
The problems I saw were related to programs that use futex(2) (Java, MySQL, Chromium, in my personal experience) chewing up lots of CPU because the futex system call wasn't quite doing what it was supposed to be doing (waking up threads when they were OK to proceed) and instead constantly waking the threads up, having the threads go "OK, so my lock is clear and I'm ready to go?", the kernel saying "oh, no, sorry" and the thread going back to sleep again -- only to be woken up again immediately. Sort of an object lesson in why busy-wait locks suck. - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace "special tool no. 2-112-A" -- Matt Roberds in asr.
+------------------------------------------------------------------------------ | On 2012-07-03 17:27:14, Matthew Palmer wrote: | | The problems I saw were related to programs that use futex(2) (Java, MySQL, | Chromium, in my personal experience) chewing up lots of CPU because the | futex system call wasn't quite doing what it was supposed to be doing | (waking up threads when they were OK to proceed) and instead constantly | waking the threads up, having the threads go "OK, so my lock is clear and | I'm ready to go?", the kernel saying "oh, no, sorry" and the thread going | back to sleep again -- only to be woken up again immediately. Sort of an | object lesson in why busy-wait locks suck. A good dig into the problem, and previous problems with that code: http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm... Cheers. -- bdha cyberpunk is dead. long live cyberpunk.
On Jul 2, 2012, at 11:47 AM, AP NANOG wrote:
Do you happen to know all the kernels and versions affected by this?
See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm... --Steve Bellovin, https://www.cs.columbia.edu/~smb
On 7/2/12, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jul 2, 2012, at 11:47 AM, AP NANOG wrote:
Do you happen to know all the kernels and versions affected by this? See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm... --Steve Bellovin, https://www.cs.columbia.edu/~smb
Someone should write a dastardly system clock daemon to cause the insertion of frequent spurious positive leap seconds, followed by the spurious insertion of negative leap seconds. For testing purposes... any application which crashes under such a test, should be repaired or not used in any critical capacity -- -JH
On Mon, Jul 2, 2012 at 8:46 PM, Jimmy Hess <mysidia@gmail.com> wrote:
Someone should write a dastardly system clock daemon to cause the insertion of frequent spurious positive leap seconds, followed by the spurious insertion of negative leap seconds.
Chaos time bandit? -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -
Jimmy Hess <mysidia@gmail.com> wrote:
Someone should write a dastardly system clock daemon to cause the insertion of frequent spurious positive leap seconds, followed by the spurious insertion of negative leap seconds.
For testing purposes... any application which crashes under such a test, should be repaired or not used in any critical capacity
For testing applications you can try libfaketime. Testing systems is a bit harder... https://github.com/wolfcw/libfaketime Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FitzRoy, Sole: West or southwest 4 or 5, occasionally 6. Moderate or rough. Occasional rain or drizzle, fog patches. Moderate or good, occasionally very poor.
Steven Bellovin <smb@cs.columbia.edu> writes:
See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm...
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. -wolfgang -- g+: https://plus.google.com/114566345864337108516/about
DST is a time-zone specific phenomenon. Leap seconds are changes to the actual core time. UTC moves with leap seconds. It doesn't move with DST or other timezone weirdnesses. The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Owen On Jul 3, 2012, at 1:54 AM, Wolfgang S. Rupprecht wrote:
Steven Bellovin <smb@cs.columbia.edu> writes:
See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm...
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way.
-wolfgang -- g+: https://plus.google.com/114566345864337108516/about
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
DST is a time-zone specific phenomenon.
Nobody said *anything* about DST; that's a complete red herring to discussions of leap seconds.
Leap seconds are changes to the actual core time. UTC moves with leap seconds.
Correct.
The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not. Are you suggesting that NTP timekeeping should be based on UT1? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are you suggesting that NTP timekeeping should be based on UT1?
The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the "common" notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain "wall clock" time (UT1) but rather some other timebase and then "step" that time to keep it in sync with UT1. NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com>
Are you suggesting that NTP timekeeping should be based on UT1?
The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the "common" notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain "wall clock" time (UT1) but rather some other timebase and then "step" that time to keep it in sync with UT1.
UTC is monotonic, and is based on UT1. Just not deterministically. :-) The root cause *is* that someone made a bad decision about kernel timekeeping, but it wasn't the choice of timescale. Non-monotonic time is not a feature of UTC *either*.
NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1.
As I undertstand it, the problem is not how NTP disciplined the kernel, it's what the kernel does itself. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
The system clock needs to be UTC, not UTC =C2=B1 some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are you suggesting that NTP timekeeping should be based on UT1?
The system clock should be based on UT1 and should be monotonically increas= ing since this matches the common concept of time. Calculations done with = this value are all based on it being UT1 and using the "common" notion of U= T1 rules. The root cause of the difficulties is that someone decided that = the system clock would not maintain "wall clock" time (UT1) but rather some= other timebase and then "step" that time to keep it in sync with UT1.
NTP can keep time in UTC (or anything else) if it wants, but it should disc= ipline the system clock to monotonically increasing UT1.
UTC is the universal time. UT1 is "astronomical time". As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, "everyone" can make a second in their lab, that's TAI. Just add the lepsecond ofset and you have UTC. UT1-UTC is done by observations from radio astronomers VLBI telecopes and a comitee, you can't make one in your lab, and it's not real time. --P (The only SI metric you can't make is a kilogram, you have to have one of the 28 kilos in the world..)
Peter Lothberg <roll@Stupi.SE> wrote:
As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, "everyone" can make a second in their lab, that's TAI.
No, TAI isn't based on the SI second you realise in your lab. It's the SI second realised on the geoid by a large fleet of clocks. If you are on Mars then TAI isn't based on your SI second, because TAI doesn't tick at a fixed rate relative to local proper time owing to the orbital differences of the two planets.
UT1-UTC is done by observations from radio astronomers VLBI telecopes and a comitee, you can't make one in your lab, and it's not real time.
You can make quite a good approximation to UT1 with a transit instrument and knowledge of your position. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Southeasterly 4 or 5. Slight or moderate. Rain or drizzle, fog banks. Moderate or poor, occasionally very poor.
On 7/3/2012 2:35 PM, Tony Finch wrote:
Peter Lothberg <roll@Stupi.SE> wrote:
As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, "everyone" can make a second in their lab, that's TAI.
No, TAI isn't based on the SI second you realise in your lab. It's the SI second realised on the geoid by a large fleet of clocks.
I think if anyone here is well aware of that that's be Peter:) The reason for the fleet of clocks is partly political, partly practical (cesium clocks are not the most precise... so averaging between a bunch of them is used to calibrate better master clocks). But in theory, if you can get the technical wrinkles worked out, you can derive the same frequency standard in your lab with a single instrument. (One more issue is that non-relativistic time is not only the frequency of oscillators, but also a reference point). --vadim
Vadim Antonov <avg@kotovnik.com> wrote:
But in theory, if you can get the technical wrinkles worked out, you can derive the same frequency standard in your lab with a single instrument.
(One more issue is that non-relativistic time is not only the frequency of oscillators, but also a reference point).
Your parenthetical point explains why TAI does not tick at the same rate as the SI second in your lab, expecially if your lab is (for example) in Colorado. You have to adjust the frequency depending on your difference in gravitational potential from the geoid. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Biscay: West or southwest 4 or 5, decreasing 3 at times. Moderate. Rain then showers. Moderate or good, occasionally poor at first.
On 7/3/2012 4:15 PM, Tony Finch wrote:
Vadim Antonov <avg@kotovnik.com> wrote:
But in theory, if you can get the technical wrinkles worked out, you can derive the same frequency standard in your lab with a single instrument.
(One more issue is that non-relativistic time is not only the frequency of oscillators, but also a reference point).
Your parenthetical point explains why TAI does not tick at the same rate as the SI second in your lab, expecially if your lab is (for example) in Colorado. You have to adjust the frequency depending on your difference in gravitational potential from the geoid.
Tony.
I'm afraid I didn't express my thoughts clearly... I means besides agreement of what a second is there is also an agreement on when the zeroeth second was, a fixed reference point in time. *That* cannot be recreated in a lab. (You can correct for relativistic effects of local gravity and moving frame of reference, though, to match conditions on the Earth and thus the SI definition of second). However, the whole concept of universal standard of _time_ (as opposed to standard of second) is thoroughly non-relativistic because it claims to have clocks at different locations ticking simultaneously. The special relativity, of course, makes it clear than simultaniety is in the eye of the observer:) In the end, you can only do limited Einstein-Poincare synchronization within a chosen reference frame. An interesting factoid: the notion of synchronized time differs if you synchronize clocks from East-to-West and from West-to-East, due to Sagnac effect:) --vadim PS. I would vote for using TAI instead of UTC as the non-relativistic time base in computer systems. The idea of expressing UTC as a single number (instead of <minute, second within minute> tuple) is silly because it creates aliases or gaps. You cannot do simple interval arithmetic over UTC, no more than you can do that over local daylight savings time; and doing accurate time computation for events in the future is impossible in both because they depend on unpredictable factors (Earth rotation rate, politics, etc). TAI is also not a fixed given, because the standards are being refined, but at least the refinements tend to be predictably in the direction of improved accuracy, so they don't break things.
On 2012 Jul 3, at 18:13, Vadim Antonov wrote:
PS. I would vote for using TAI instead of UTC as the non-relativistic time base in computer systems.
A problem with the use of TAI is that the BIPM and CCTF (who make TAI) expressed strongly that they do not want it used as a system time in document CCTF09-27 http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf so strongly that they end by contemplating the discontinuation of TAI. Unless there is international agreement that a time scale should be used, and support of the agency making that time scale, there will be trouble. The only way out of those constraints is to have the wherewithal of the US DoD or the Chinese government who simply asserted that the GPS system time and Beidou system time would be something other than those international standards. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On 7/3/2012 6:28 PM, Steve Allen wrote:
On 2012 Jul 3, at 18:13, Vadim Antonov wrote:
PS. I would vote for using TAI instead of UTC as the non-relativistic time base in computer systems.
A problem with the use of TAI is that the BIPM and CCTF (who make TAI) expressed strongly that they do not want it used as a system time in document CCTF09-27 http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf so strongly that they end by contemplating the discontinuation of TAI.
There's always a possibility of using pseudo-TAI internally by reconstructing it from UTC. This is not the best solution (because it requires systems to have long-term memory of past leap seconds, or ability to access a reliable storage of such), but at least this removes the burden of doing complicated time handling from application software. Actually, what they are saying is that they would discontinue TAI *if* definition of UTC is amended to remove future leap seconds. The document makes it clear that they recognize the necessity of continuous coordinate time standard. --vadim
came for the meme, stayed for the epic rant on time. thanks for making my holiday start awesome. -chris
On 7/3/12, Vadim Antonov <avg@kotovnik.com> wrote:
There's always a possibility of using pseudo-TAI internally by reconstructing it from UTC. This is not the best solution (because it requires systems to have long-term memory of past leap seconds, or How about, instead of requiring systems to "remember" past leap seconds;
You represent every single timestamp instead of as timestamp = <32-bit int, seconds since jan 1 1970 00:00:00> You represent all system timestamps as tuples: timestamp = ( <32-bint int seconds since jan 1 1970 00:00:00>, <integer representing the leap-second offset since jan 1 1970> ) No need to retain a history. Just retain the data in the same way that Hours, Minutes, and Second are retained. Comparison is simple. (Timestamp2 - Offset2) - (Timestamp1 - Offset1) The downside is you can no longer set your system clock by hand, because humans won't know the right number of "leap seconds" to supply when setting the time from their wall clock. That's a problem necesitating you keep a history anyways. For time to be universally coordinated, it has to be coordinated. One of the basic requirements for system time is that it interacts with humans, and humans have to be able to set their clock from conventional time sources which are based on local time, without the machine having to be constantly updated or reach out on a network and figure out how that translates into a reasonable machine time. -- -JH
Most systems that deals with time has a slightly different way of doing it than U*ix.. ref: CCIR 457-1 Like this: 56113.6294791667 56113.6301736111 56113 is MJD, modified julian date (http://tycho.usno.navy.mil/mjd.html) Want to knew the time between two observations, just subtract and you get days and fraction of day. (I's about 60sec between the lines above..) --P Ps: Tops20/Twenex/Tenex keeps the kernel time this way, in 18+18 bits...
On 7/3/12, Vadim Antonov <avg@kotovnik.com> wrote:
There's always a possibility of using pseudo-TAI internally by reconstructing it from UTC. This is not the best solution (because it requires systems to have long-term memory of past leap seconds, or How about, instead of requiring systems to "remember" past leap seconds;
You represent every single timestamp instead of as timestamp = <32-bit int, seconds since jan 1 1970 00:00:00>
You represent all system timestamps as tuples: timestamp = ( <32-bint int seconds since jan 1 1970 00:00:00>, <integer representing the leap-second offset since jan 1 1970> )
No need to retain a history. Just retain the data in the same way that Hours, Minutes, and Second are retained. Comparison is simple.
(Timestamp2 - Offset2) - (Timestamp1 - Offset1)
The downside is you can no longer set your system clock by hand, because humans won't know the right number of "leap seconds" to supply when setting the time from their wall clock.
That's a problem necesitating you keep a history anyways. For time to be universally coordinated, it has to be coordinated.
One of the basic requirements for system time is that it interacts with humans, and humans have to be able to set their clock from conventional time sources which are based on local time, without the machine having to be constantly updated or reach out on a network and figure out how that translates into a reasonable machine time.
-- -JH
On Jul 3, 2012, at 1:08 PM, Keith Medcalf wrote:
The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch.
Nope. UTC *includes* leap seconds already. It's UT1 that does not.
Are you suggesting that NTP timekeeping should be based on UT1?
The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the "common" notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain "wall clock" time (UT1) but rather some other timebase and then "step" that time to keep it in sync with UT1.
It only matches the common concept of time at some particular instant. Over the course of several years it will become less and less aligned with the common concept of time. Most people operate on the assumption that there are 86400*365.25 seconds per year overall and that every day is 86,400 seconds. UTC matches that common conception of time. UT1 does not because UT1 monotonically increments one second for every elapsed second of time and continues to drift out of synchronization with the celestial phenomena on which the common conception of time is based.
NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1.
This will break many many currently correct applications and is not a change that should be undertaken lightly. Especially not if it is intended to fix a moderately esoteric bug in a few things that crops up once per decade or so. Owen
Tony Finch dot at dotat.at wrote
No that is not correct, or at least it's nowhere near as simple as that. The atomic second was matched to the second of ephemeris time, and that was based on Newcomb's tables of the sun, which in effect used the average length of the second from the 1800s. http://ucolick.org/~sla/leapsecs/dutc.html
Last fall we held a meeting to consider how UTC might be changed and what the implications of leaps seconds were. The proceedings fill 400 pages of a book. For the sound bite version (only 3 pictures) of leap seconds http://www.ucolick.org/~sla/leapsecs/amsci.html For a view of the international legal mess caused by leap seconds http://www.ucolick.org/~sla/leapsecs/epochtime.html For a blow-by-blow review of the international bureaucratic regulatory situation for leap seconds see http://www.ucolick.org/~sla/leapsecs/onlinebib.html For a worked example that could alleviate the disagreement between POSIX and leap seconds, and which might break the international stalemate http://www.ucolick.org/~sla/leapsecs/right+gps.html In there are also links to those 400 pages of the book, but I suggest that this forum is not the best place to rehash this information. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Tue, Jul 3, 2012 at 4:48 PM, Owen DeLong <owen@delong.com> wrote:
.... Most people operate on the assumption that there are 86400*365.25 seconds per year overall and that every day is 86,400 seconds. UTC matches that common conception of time. UT1 does not because UT1 monotonically increments one second for every elapsed second of time and continues to drift out of synchronization with the celestial phenomena on which the common conception of time is based.
Let's be clear - the "celestial phenomena" vary regularly. The Sun and Moon do not rise and set at the same exact time every day; people would not practically notice a second-a-year skew in this for decades or longer, much less societally have grounds to object to it. And it's only historically been about 0.625 s / yr averaged since 1972. At that long term rate (if that's what it ended up being) it would be about a minute a century, or 6000 years before we saw things happening a whole hour off from "expected solar time", which to be frank stops being meaningful around when you have real clocks and astronomy. The only people for which the celestial phenomena timing matters this precisely are astronomers, who ALREADY have to do their own things to keep everything straight, much more precisely than the leap seconds correct the ongoing skews. This (irregular leap seconds) is a solution which is monumentally badly matched to the actual problem set.
NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1.
This will break many many currently correct applications and is not a change that should be undertaken lightly. Especially not if it is intended to fix a moderately esoteric bug in a few things that crops up once per decade or so.
From an Internet Stability point of view, one can easily take the
I would argue exactly the opposite. It's unpredictable and irregular enough that a nearly completely new set of software and administrators are what encounters it each time it comes through. It broke chunks of the internet this time. Last time, this was a "Oh, well, some geeks inconvenienced, shrug". This time it was fortunately small enough (esp. in comparison to the recent AWS outage due to more malign natural forces) that it wasn't a big deal. It could be more disruptive next time. position that This Just Does Not Do. So - It's there to keep us in sync with the stars, except it's done in increments nobody will notice but astronomers, who have to do better than that anyways; it disrupts technology, to a mild to moderate degree. Why are we doing it again? I like this atomic time thing. It's sounding better and better each day we keep arguing about it. If it bothers you that much we can schedule in a leap hour for Y8000 (or, Y5000, Y11000, Y17000, ....). It's not a butthead thing to do to assert that the Internet's stability in this matter now outweighs an arbitrary and abstract argument among timekeepers. We matter more than they do, now. If they want to keep a more true Solar Time they can do so; we can run on atomic and put this silly notion of trying to say Sun-centric behind us. This is the 21st century. Leapsecondo Delenda Est! -- -george william herbert george.herbert@gmail.com
On Tue, Jul 3, 2012 at 11:15 PM, George Herbert <george.herbert@gmail.com> wrote:
It's not a butthead thing to do to assert that the Internet's stability in this matter now outweighs an arbitrary and abstract argument among timekeepers. We matter more than they do, now. If they want to keep a more true Solar Time they can do so; we can run on atomic and put this silly notion of trying to say Sun-centric behind us. This is the 21st century.
Leapsecondo Delenda Est!
I don't see why everyday computers, servers, and routers need the functionality to add (or subtract) an arbitrary second once every 3 or 4 years. These things are supposed to be synced to a NTP source anyway. Easiest solution is just remove leap second functionality from mainline code, and make it something you have to special-compile for. The fact there is a 400 page book on the subject really makes me wonder how well the average kernel hacker is doing the implementation. (Oh wait, we saw EXACTLY how well it was done). All this is a time bomb (lame I know) waiting to go off every few years there is a leap second. We get to find out which servers are running which out-of-date kernels that attempt to implement some arcane time function practically no one cares about. (Sorry time aficionados. I appreciate your work, but I'd rather just look it up and not trust my computer to calculate it.)
On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote:
4 years. These things are supposed to be synced to a NTP source anyway.
Easiest solution is just remove leap second functionality from mainline code, and make it something you have to special-compile for.
Please reconcile these two statements. Thanks, --msa
On Tue, Jul 3, 2012 at 11:59 PM, Majdi S. Abbas <msa@latt.net> wrote:
On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote:
4 years. These things are supposed to be synced to a NTP source anyway.
Easiest solution is just remove leap second functionality from mainline code, and make it something you have to special-compile for.
Please reconcile these two statements.
Thanks,
--msa
Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years.
Tyler Haske <tyler.haske@gmail.com> writes:
Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years.
Ah, Tyler, I see the problem here. An NTP server is not like an XML-spitting web server which one consults each and every time one wants to know a piece of data (for instance a stock quote, the weather, or in this case, what time it is). NTP assumes a local clock, and the results of periodic queries to higher-than-or-equal-to-local-stratum servers are used to _discipline_ the local clock, steering it to have minimal error. Local clocks have to be consulted much too frequently (logging, timestamping, etc) for "just put it in the cloud" to work. You might want to read up on NTP (wikipedia provides a reasonable introduction). cheers, -r
On 7/4/12, Robert E. Seastrom <rs@seastrom.com> wrote: [snip]
Local clocks have to be consulted much too frequently (logging, timestamping, etc) for "just put it in the cloud" to work. You might want to read up on NTP (wikipedia provides a reasonable introduction).
The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump. The breakage doesn't occur for whatever reason when the time is stepped forward or backwards, or slewwed. So accept the inaccuracy and correct the clock in the normal way that NTP corrects clocks that have drifted. -- -JH
On 2012 Jul 4, at 08:50, Jimmy Hess wrote:
So accept the inaccuracy and correct the clock in the normal way that NTP corrects clocks that have drifted.
This is basically the "leap smear" that google instituted after the issues in 2005. It works nicely in cloud applications where real-time is not an issue. It does not work so well when precision calculations of real-time physics are important, nor in heterogeneous environments where not all devices pay attention to NTP or some handle the leap differently than others. Those are places where a kernel should never be asked to do what the combination of POSIX and leap seconds demand. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump.
Unless I'm mis-reading things, it already does - of sorts. According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) : *The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider: If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary. If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. * Linux does implement the "kernel discipline" (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option ("disable kernel") or via ntpdc at which point I'm presuming it will fall back to the second option. The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference. Of course there would be side effects of this (the kernel implementation of NTP is there for a reason, and this disables it), but at least it's better than a server hang... Scott.
On Wed, Jul 4, 2012 at 17:22 UTC, Scott Howard wrote:
On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump.
Unless I'm mis-reading things, it already does - of sorts.
I hope anyone implementing systems that depend on minutae of leap seconds does not rely solely on your reading, but actually tests by inconveniently setting their clock and ntpd leapfile to actually insert a leap second.
According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) :
That FAQ is woefully out of date. http://support.ntp.org/ has more current information. The best reference for a given ntpd version is the html docs included in the tarball for that version. Some widely-used versions' html documentation is archived at http://doc.ntp.org/
*The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider:
If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary.
But exactly how it handles it is up to the kernel. Linux and FreeBSD essentially step the clock backward 1s at 23:59:60.0 UTC. At least one system (I believe it was NetBSD or OpenBSD) instead stalls the clock for 1s, though each reading of the clock during that period is greater than the prior, the delta is microscopic and not related to elapsed time within that second, but simply preserves ordering of events. Dr. Mills attempted to exhort kernel developers to implement leap seconds while keeping the system time ever-increasing, but that advice was largely ignored because of implementation difficulty. For example, when first considered, NTP kernel extensions had microsecond precision. The approach of adding a tiny amount with each reading would open the system up to problems if apps could read the clock more than 1 million times during the leap second. It's also ugly for a SMP kernel to maintain global state on the last clock reading across processors. Most systems offer a monotonic alternative to the wall clock, typically implemented as an uptime counter in nominal SI seconds (nominal as defined by hardware, as the monotonic clock is _not_ disciplined by ntpd or affected by steps (setting the wall clock to a particular value). Look for CLOCK_MONOTONIC in the documentation of clock_gettime. There are also interval-only timer facilities like timer_settime. The tools are at hand for those who understand the implications of clock steps (which can occur under circumstances other than leap seconds).
If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. *
This is the historic behavior of ntpd, but after years of complaints, it was changed. ntpd 4.2.6 and later step the clock backward 1s at the scheduled insertion if using the daemon loop discipline (as opposed to the kernel loop discipline).
Linux does implement the "kernel discipline" (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option ("disable kernel") or via ntpdc at which point I'm presuming it will fall back to the second option.
The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference.
That is incorrect. -x is often misunderstood -- it does not disable stepping entirely, it raises the "step threshold" from 0.128s default to 600s. When ntpd synchronizes the clock and determines the offset exceeds the step threshold, the clock is stepped to the correct time. So long as you manage to keep your clock within 10 minutes of correct, -x isn't terribly different from disabling steps, but that's not what it does. In particular, when ntpd using the daemon loop implements a leap second by stepping the clock backward one second, the step threshold (and hence -x) are not a decision factor -- the step is taken. Cheers, Dave Hart
On Tue, Jul 3, 2012 at 11:59 PM, Majdi S. Abbas <msa@latt.net> wrote:
On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote:
4 years. These things are supposed to be synced to a NTP source anyway.
Easiest solution is just remove leap second functionality from mainline code, and make it something you have to special-compile for.
Please reconcile these two statements.
Thanks,
--msa
Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years.
A "cesium clock" don't knew it should do leap seconds unless you tell it, and it only affects the display and the internal time of the clock.. -:) The S1 NTP server and it's host OS has to be told to set the leap-second indicator by hand to.. But all the system on the internet has to knew what to do with this information. In the case of a host_os that do not knew about leap-seconds, NTP will have the correct time and then try to stear the host as fast as it can to loose/gain a second.. -P
On (2012-07-03 01:54 -0700), Wolfgang S. Rupprecht wrote:
kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and
Yes. TAI time natively and presentation uses leap lookup tables to convert to UTC. Unixtime is not monotonously increasing which is incredibly broken by design. http://en.wikipedia.org/wiki/Unixtime#TAI-based_variant http://cr.yp.to/libtai.html -- ++ytti
On Jul 3, 2012, at 7:39 AM, Saku Ytti wrote:
On (2012-07-03 10:33 -0400), valdis.kletnieks@vt.edu wrote:
On the other hand, how many subtle bugs will we introduce when we break code that currently assumes the system clock is UTC, not TAI?
Progress has non zero cost :)
-- ++ytti
Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided. Owen
On (2012-07-03 10:11 -0700), Owen DeLong wrote:
Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided.
Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 -> 60 -> 00, but we go 59 -> 59 -> 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken. It's quite hard to find code which stores timestamp and then compares it in future to timestamp which assumes time can travel backwards. Most bugs are just things that should last 5s last 6s or 4s, but certainly the bugs exist and developers were not aware that they exist. -- ++ytti
On 03/07/2012 18:59, Saku Ytti wrote:
Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 -> 60 -> 00, but we go 59 -> 59 -> 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken.
Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds. Certainly if POSIX were being redesigned, they ought to consider using libtai. Google's approach to this is interesting:
http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping-seconds.ht...
i.e. controlled clock slew until the correct offset is reached, thereby allowing their developers to assume a monotonic system clock. Nick
On (2012-07-03 19:33 +0100), Nick Hilliard wrote:
Google's approach to this is interesting:
http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping-seconds.ht...
Yes. I'm sure this is good enough for most people, most people don't need precise time but virtually everyone needs monotonic time. And this is easy to deploy TAI + UTC presentation using leapsecond file lookup isn't exactly easy. Too bad this isn't standard configuration option in NTPd. Also one thing I wonder, why did GOOG choose to skew in just 24h, why not the moment leap is announced? Everyone has some accuracy budget, what ever that might be, it almost certainly is same every day. So you could live with tighter accuracy budget the longer you spend skewing. PC clock on average is probably like 15PPM accurate (or order magnitude of worse, IBM servers seem to be exception). If you'd skew 3 months, your skewing would cause inaccuracy of 0.19PPM. Skewing in single day causes inaccuracy of 11.6PPM (still almost certainly better than free-running PC oscillator) -- ++ytti
God damn that's a horrid piece of shit web site. You have to disable security and permit remote code execution or it does not work. What a crock! --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Tuesday, 03 July, 2012 12:33 To: Saku Ytti Cc: nanog@nanog.org Subject: Re: F-ckin Leap Seconds, how do they work?
On 03/07/2012 18:59, Saku Ytti wrote:
Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 -> 60 -> 00, but we go 59 -> 59 -> 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken.
Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds. Certainly if POSIX were being redesigned, they ought to consider using libtai.
Google's approach to this is interesting:
http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping- seconds.html
i.e. controlled clock slew until the correct offset is reached, thereby allowing their developers to assume a monotonic system clock.
Nick
Nick Hilliard <nick@foobar.org> wrote:
Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds.
No a minute cannot have 62 seconds. That is an old documentation bug which has been fixed. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 4 or 5, increasing 6 at times. Moderate. Occasional rain, fog patches. Moderate, occasionally very poor.
On Jul 3, 2012, at 10:59 AM, Saku Ytti wrote:
On (2012-07-03 10:11 -0700), Owen DeLong wrote:
Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided.
Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 -> 60 -> 00, but we go 59 -> 59 -> 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken.
It's quite hard to find code which stores timestamp and then compares it in future to timestamp which assumes time can travel backwards. Most bugs are just things that should last 5s last 6s or 4s, but certainly the bugs exist and developers were not aware that they exist.
-- ++ytti
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write. It is well known that leap seconds exist. The rotation of the planet does not line up well with the orbit of the planet and neither of these lines up particularly well with the rotation and orbit of the moon. Since we have a long standing tradition of using the orbit of the earth to determine years and the orbit of the moon to divide years into months, we use some fudge-factors on the months to make years and months line up. (12 true months would leave us several days short of a complete orbit at the end of the year and seasons would migrate.) Since we have a tradition of measuring diurnal and other repetitive cycles (days) based on the rotation of the earth, we end up with fudge factors to make that line up with months from time to time. (leap seconds). So it goes. Time is much more complex than many people realize. If you write software where time matters, it is your responsibility to learn about these things. Owen
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write.
If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now > foo, virtually never expects time to move backwards. UTC doesn't move backwards (it goes 59 -> 60 -> 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that.
It is well known that leap seconds exist.
Quite. But it is not well known that unixtime travels backwards. -- ++ytti
(source http://physics.nist.gov/cuu/Units/second.html ) Unit of time (second) Abbreviations: CGPM, CIPM, BIPM The unit of time, the second, was defined originally as the fraction 1/86 400 of the mean solar day. The exact definition of "mean solar day" was left to astronomical theories. However, measurement showed that irregularities in the rotation of the Earth could not be taken into account by the theory and have the effect that this definition does not allow the required accuracy to be achieved. In order to define the unit of time more precisely, the 11th CGPM (1960) adopted a definition given by the International Astronomical Union which was based on the tropical year. Experimental work had, however, already shown that an atomic standard of time-interval, based on a transition between two energy levels of an atom or a molecule, could be realized and reproduced much more precisely. Considering that a very precise definition of the unit of time is indispensable for the International System, the 13th CGPM (1967) decided to replace the definition of the second by the following (affirmed by the CIPM in 1997 that this definition refers to a cesium atom in its ground state at a temperature of 0 K): The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom. If anyone still thinks UT1; We have a NTP server on Earth (say Washington-DC) and Vint has extended the Internet to planet Mars, can we use NTP? (Hints: Looking at the clock on Earth from Mars, you se a satellite with a orbit, gravity changes by other plaets, unknown distance, unknown orbits and time runs faster on mars than on earth..) --P
Peter Lothberg <roll@Stupi.SE> wrote:
We have a NTP server on Earth (say Washington-DC) and Vint has extended the Internet to planet Mars, can we use NTP?
No. http://fanf.livejournal.com/116480.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Rockall: Cyclonic, becoming northerly later, 4 or 5, occasionally 6 in far north. Moderate or rough. Rain or showers. Moderate or good, occasionally poor.
On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write.
If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now > foo, virtually never expects time to move backwards.
Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers.
UTC doesn't move backwards (it goes 59 -> 60 -> 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that.
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
It is well known that leap seconds exist.
Quite. But it is not well known that unixtime travels backwards.
In part because it shouldn't actually do so. It should simply chime 59 twice. Owen
Once upon a time, Owen DeLong <owen@delong.com> said:
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
That would be true if the highest resolution clock was one second, but that's not the case. Anything that uses gettimeofday() sees time repeat (which means it counts up to 59.999999 seconds and then goes back to 59.000000). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
No, it really shouldn't. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Owen DeLong <owen@delong.com> wrote: On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write.
If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now > foo, virtually never expects time to move backwards.
Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers.
UTC doesn't move backwards (it goes 59 -> 60 -> 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that.
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
It is well known that leap seconds exist.
Quite. But it is not well known that unixtime travels backwards.
In part because it shouldn't actually do so. It should simply chime 59 twice. Owen
On Tue, Jul 03, 2012 at 04:53:32PM -0700, Owen DeLong wrote:
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
Owen, ...that is going backwards, since we'll repeat 59.XXXXXX. Which is really bad for a lot of applications, system timers, pretty much any database, sleep mechanisms, locking mechanisms, etc. What happens if you were trying to execute some code at 59.5926725? Has it already happened or is it yet to come? Looking back at two financial transactions, which came first? I've had an environment where large reverse steps occured with some regularity -- you don't want to go there. At all. There is a LOT more software that wigs out when you reverse step the clock (which you will be, if you 'repeat' a second.) than does when a leap occurs.
In part because it shouldn't actually do so. It should simply chime 59 twice.
You must have written some NMEA code in a past life. I'd be fine with rolling TAI for systems use, but it does not make much sense to condemn the leap second in UTC for this. We've had a fair number of them, in the Internet age, without this much trouble. This is about bad software development. If you change something like the leap second handler in your code, please test it. If not right away, before 2 more leap seconds have occured several years down the road. Also, people that build production environments on operating systems that do not receive that sort of testing, do so at their own risk. That's their fault, despite any fist shaking/angry tweeting at 23:59:60. It's pathetic that advertising clocks in public places can get this right (and did in 2008) and 'the Internet' cannot: http://www.youtube.com/watch?v=PJ4TWChcKpI --msa
On 7/3/2012 1:53 PM, Owen DeLong wrote:
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
If they do that, they're "doing it wrong", UTC and the system clock should go 58->59->60->00. From the IERS bulletin announcing the leap second just past: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat "A positive leap second will be introduced at the end of June 2012. The sequence of dates of the UTC second markers will be: 2012 June 30, 23h 59m 59s 2012 June 30, 23h 59m 60s 2012 July 1, 0h 0m 0s"
On 2012 Jul 3, at 21:29, Paul Graydon wrote:
Which is simply reiterating an older version of the regulatory document that specifies how UTC shall be done http://www.itu.int/rec/R-REC-TF.460/en On paper it is a scheme that will work for 1000 years, but the original regulation contained no implementation details, no interoperability studies, no agency responsible for describing how implementations might communicate requirements, and that paper was locked behind a paywall for the first 40 years of its existence. All of that is too late to fix now. The events in January showed that the notion of simply abandoning leap seconds could not achieve consensus required for change. We are in Disney's Haunted Mansion with the spirit taunting us to find a way out. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On (2012-07-03 16:53 -0700), Owen DeLong wrote:
Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers.
Inclusive you no longer know order of events based on your logs, and virtually none of your software are logging 60th second. What are only interesting and what can cause with luck (or bad luck) catastrophic failures is guess work, no one is going to review all the code written, and almost all of it assumes monotonic time.
Quite. But it is not well known that unixtime travels backwards. In part because it shouldn't actually do so. It should simply chime 59 twice.
Chiming 59 twice is traveling backwards. It goes to what ever precision you have between 59 and 00, then it goes back to 59 flat. -- ++ytti
Owen DeLong <owen@delong.com> wrote:
Since we have a tradition of measuring diurnal and other repetitive cycles (days) based on the rotation of the earth, we end up with fudge factors to make that line up with months from time to time. (leap seconds).
That is not what leap seconds are. Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Faeroes, South-east Iceland: Easterly 5 or 6, backing northeasterly 4 or 5. Moderate. Occasional rain, fog patches in Faeroes. Moderate or good, occasionally very poor in Faeroes.
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth.
You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation. Once upon a time eclipses of the sun and moon were "random magic", before the mechanism was understood. So to the periodic cycles of the rotation of the earth about its axis, the planet about the sun, etc., are viewed as "magical". This is not due to magic, but rather limitations of understanding. Leap seconds are to align the artifical timescale (which we presently assume, based on facts not in evidence) to be very stable with the simple observation of the equinox and zenith of the sun, on which "time" reconning is based. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Keith Medcalf <kmedcalf@dessus.com> wrote:
You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation.
There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Hebrides, Bailey: East backing northeast 5 or 6, decreasing 4 later in Hebrides. Rough in Bailey at first, otherwise moderate. Rain at times, fog patches. Moderate, occasionally very poor.
On Tue, Jul 03, 2012 at 11:33:22PM +0100, Tony Finch wrote:
Keith Medcalf <kmedcalf@dessus.com> wrote:
You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation.
There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second.
This. Shoot, seismic activity has a measurable effect. The best we can do is approximate it and align the timescales as needed. There's no lack of understanding here, just a changing planet. Now, changing your kernel's leap second handler and not testing it, well, you can't blame that one on the ITU or the aforementioned planet. --msa
Tony Finch <fanf2@hermes.cam.ac.uk> wrote:
Keith Medcalf <kmedcalf@dessus.com> wrote:
You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation.
There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second.
What you mean is that it is subject to periodicities and forces which you do not understand, and that within your limited perception, this ignorance is taken as "irregularity". Just because the system encompasses rules and properties beyond your understanding and observation does not mean that it is magic. It is impossible for the earth's rotation to be irregular, just as it is impossible for the orbit around the sun to be irreglar, or the orbit of the solar system within the galaxy, or the galaxy within the universe, or the universe within the multiverse, to be irregular. The irregularity is due to inability to comprehend the rather simple set of rules governing the motion, or failures of observation. Once upon a time (not too long ago) the orbit of Pluto was thought to be "irregular". It was not. There was another body right where it would be expected to be found affecting the orbit of Pluto. All that was required to "discover" it was someone who applied logical thought processes rather than magical thought processes to the observed data. The earth's rotation and orbit is perfectly regular. Your error is one of assumption and a failure to admit that your knowledge is imperfect. ** "your" is the general y'all, not you in particular ** --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Keith Medcalf <kmedcalf@dessus.com> wrote:
What you mean is that it is subject to periodicities and forces which you do not understand, and that within your limited perception, this ignorance is taken as "irregularity". Just because the system encompasses rules and properties beyond your understanding and observation does not mean that it is magic.
You seem to have a strange interpretation of the word "irregular". All I mean is that it does not rotate at a regular rate, i.e. smoothly. It is not a regular oscillator. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Cromarty, Forth, Tyne, Dogger: Southeast 4 or 5, decreasing 3 at times. Slight or moderate. Rain or drizzle, fog patches. Moderate, occasionally very poor.
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth.
You are assuming facts not in evidence. The rotation is merely irregular w= ithin the capabilities of our scheme of measurement, calculation, and obser= vation. Once upon a time eclipses of the sun and moon were "random magic",= before the mechanism was understood. So to the periodic cycles of the rot= ation of the earth about its axis, the planet about the sun, etc., are view= ed as "magical". This is not due to magic, but rather limitations of under= standing.
Earth is 10e-8 in frequency, a nanosecond a day is kindof 10e-14 on frequency. Tom has done the work to document it.. http://www.leapsecond.com/museum/earth/ --Peter
On Thu, Jul 5, 2012 at 9:55 AM, Peter Lothberg <roll@stupi.se> wrote:
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth.
You are assuming facts not in evidence. The rotation is merely irregular w= ithin the capabilities of our scheme of measurement, calculation, and obser= vation. Once upon a time eclipses of the sun and moon were "random magic",= before the mechanism was understood. So to the periodic cycles of the rot= ation of the earth about its axis, the planet about the sun, etc., are view= ed as "magical". This is not due to magic, but rather limitations of under= standing.
Earth is 10e-8 in frequency, a nanosecond a day is kindof 10e-14 on frequency.
Tom has done the work to document it..
And, by the way, the deformations and exchanges of angular momentum that drive Earth rotation variations are probably the best understood global geophysical processes there are. Absolutely no magic is required. Regards Marshall
--Peter
On Jul 5, 2012, at 8:14 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
And, by the way, the deformations and exchanges of angular momentum that drive Earth rotation variations are probably the best understood global geophysical processes there are. Absolutely no magic is required.
Not the tectonic ones. The deeper geophysical ones yes, but tectonics is irregular. We understand the underlying plate segment motions well but they express very irregularly over year-decade scales. George William Herbert Sent from my iPhone
On Tue, Jul 3, 2012 at 5:24 PM, Tony Finch <dot@dotat.at> wrote:
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth.
What do you want to use for a clock? It is convenient (if provincial) for me to use the sky as the ultimate clock. Thus these adjustments.
Wolfgang S. Rupprecht <wolfgang.rupprecht@gmail.com> wrote:
I wonder why the system's internal time isn't run that way.
For compatibility with software that does time calculations without using the crappy libc time API. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Humber, Thames, Dover, Wight: South 4 or 5. Slight or moderate. Occasional rain or drizzle, fog patches. Moderate, occasionally very poor.
On 7/3/12 01:54 , Wolfgang S. Rupprecht wrote:
Steven Bellovin <smb@cs.columbia.edu> writes:
See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.htm...
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way.
Neither timezones nor dst impact length of the mean solar day. TAI is some 35 seconds ahead of UTC this point. and will continue to diverge in a fashion which is not sufficiently predictable that you can know over the long term. Not using utc as the timebase is certainly possible, gps does that for example. Apps are buggy sounds like a really poor excuse for doing so.
-wolfgang
On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said:
Apps are buggy sounds like a really poor excuse for doing so.
When the published API has been "the system clock is in UTC" for some 3 decades, I hardly think it's acceptable to call apps "buggy" for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it?
On 7/3/12 07:51 , valdis.kletnieks@vt.edu wrote:
On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said:
Apps are buggy sounds like a really poor excuse for doing so.
When the published API has been "the system clock is in UTC" for some 3 decades, I hardly think it's acceptable to call apps "buggy" for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it?
right you and I agree, proposing to switch off UTC becuase of buggy applications is a rather bad premise. software runs into trouble with the handling of leap years. yet few people (apart from perhaps the orthdox church is proposing to throw off the julian and gregorian calender reforms.
----- Original Message -----
From: "valdis kletnieks" <valdis.kletnieks@vt.edu>
When the published API has been "the system clock is in UTC" for some 3 decades, I hardly think it's acceptable to call apps "buggy" for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it?
Correct. It's very likely that there is *no* sufficiently compelling application requirement that justifies switching NTP from UTC to UT1/TAI. So far as I can tell, the *only* requirement is "I need to be able to calculate unixtime<->ISO8601 reliably to the second for times further away than the next possible leapsecond"; I have not had pointed out to me yet an application which actually requires that; I'm 99 44/100% certain that there isn't one with a sufficiently compelling story to break 3 decades of code. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
----- Original Message -----
From: "Wolfgang S. Rupprecht" <wolfgang.rupprecht@gmail.com>
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way.
I cannot tell you how (literally) shocked I was, to learn from John Stull (at IBM, the first guy, apparently, to locate the current screwup and create kernel patches for it) that *the kernel gets this so wrong*. It's so off that I wasn't sure I was interpreting the situation properly until you posted this. This pain should have been undergone at least 15 years ago; 235960 is a perfectly valid timestamp; ISO8601 says so. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way.
I cannot tell you how (literally) shocked I was, to learn from John Stull (at IBM, the first guy, apparently, to locate the current screwup and create kernel patches for it) that *the kernel gets this so wrong*.
It's so off that I wasn't sure I was interpreting the situation properly until you posted this.
This pain should have been undergone at least 15 years ago; 235960 is a perfectly valid timestamp; ISO8601 says so.
I leave the computer kernels out of this for a second..:-) We have a timescale that runs at constant speed forward it's named "TAI", it is based on the definition on the atomic second. Some systems like GPS have their own idea of a "base time" and then they have a way of telling the difference between "their timescale" and UTC. In the case of GPS, they took the numer of leap seconds currently in play when the system was launched and keept that. (as their calendar is 1024 weeks, mosty receivers use the UTC-GPS ofset to figure out what modulo 1024 weeks we are in). TAI is atomic time, UTC(k) is what we use for practical timekeeping, and the problem at hand is that the atomic second runs at constant speed, but the earth is not. Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds. There are applications on the earth that deals with the earth position in repect to other planets and the sun, so in order to have one timescale for everyone UTC is compensated for the earth rotation speed, when the solar time differs from atomic time with more than 0.94 seconds, we compensate by adding or deleting a second the last minute of the last day of a month, in pratice they have picked new-years and jun/jul. You have all heard "GMT", if we don't insert leap seconds as the earth is slowing down "GMT" will be "PMT" (paris mean time) in some 65000 years. And day and night will be swapped in 12*65000 years. So in order to avoid having to ask someone gving you a time and date what timescale he/she refers to refered we have UTC, and as all things in life it's a compromize. --Peter Ps: fix your broken code, most systems can handle "leap days" by now, every 4 years, except years that ends with 00..
On Tue, Jul 03, 2012 at 09:49:40PM +0200, Peter Lothberg wrote:
I leave the computer kernels out of this for a second..:-)
We have a timescale that runs at constant speed forward it's named "TAI", it is based on the definition on the atomic second.
Notice that in inertial frame dragging context it's provably impossible to synchronize oscillators. Luckily, Earth has negligible frame dragging, for the kind of accuracy we currently need. For operative values of time lunaticism, there's always http://www.leapsecond.com/time-nuts.htm
In a message written on Tue, Jul 03, 2012 at 10:47:52PM +0200, Eugen Leitl wrote:
Notice that in inertial frame dragging context it's provably impossible to synchronize oscillators. Luckily, Earth has negligible frame dragging, for the kind of accuracy we currently need.
I think everyone on this list is going in the wrong direction with this issue. What you're all arguing over is the "correct time" for some defintion of "correct". I'm a bit more practical. How about we write software so a leap second doesn't crash everything? We can then allow the time nuts get back to arguing which leap seconds we should use, or time reference, or whatever. I'd even take off by a second but didn't crash, over crashed. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
----- Original Message -----
From: "Leo Bicknell" <bicknell@ufp.org>
I'd even take off by a second but didn't crash, over crashed.
You would, but lots of people would not, and that's not the contract made by the API definition. If you want to run a Google-patched NTP server and talk to it, you're welcome to. The rest of us would prefer to just get it right, so we don't have to get lied to. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
If you want to run a Google-patched NTP server and talk to it, you're welcome to. The rest of us would prefer to just get it right, so we don't have to get lied to.
The timescale implementation in NTP is correct accoring to how UTC is defined. I suggest leaving it alone, chances of improving on this part over what Mills has done in half a lifetime is slim. (For those who want to state more incorrect things on this matter, let me just point out that Dave Mills received the PTTI award 2006, so NTP's implementioon of time has sufficient peer review of people who defined how UTC/TAI works.. ) The time format has a best_before date like Unix, so it will require outside information to tell what modulos of time we are in after it runs out of bits. At the IETF TICTOC BOF (a long time ago, and no_one payed attention, as we where being DOSed by the 1588 and mobile people) it was suggested to make a timescale represenation that would be future prof and work on places where time has a different rate compared to earth at sea level. -Peter
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync. The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule.
valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> wrote:
Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year.
No leap seconds have nothing to do with years. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Rockall: Cyclonic, becoming northerly later, 4 or 5, occasionally 6 in far north. Moderate or rough. Rain or showers. Moderate or good, occasionally poor.
UTC and time is defined as part of the SI system and ITU etc, so we just need to implement the time system correct. If you try to invent your own way, there are surprises we don;t need to re-explore..
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync.
The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule.
I'm not an astronomer, but some of the errors we have in the second intenmtion ended up in the earth position measurements, so the table is not nicely spaced.. On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no "-" # @(#)leapseconds 7.17 # Allowance for leapseconds added to each timezone file. # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of UT1 # (which measures the true angular orientation of the earth in space); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is UTC # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S Leap 1976 Dec 31 23:59:60 + S Leap 1977 Dec 31 23:59:60 + S Leap 1978 Dec 31 23:59:60 + S Leap 1979 Dec 31 23:59:60 + S Leap 1981 Jun 30 23:59:60 + S Leap 1982 Jun 30 23:59:60 + S Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S Leap 1989 Dec 31 23:59:60 + S Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S Leap 1994 Jun 30 23:59:60 + S Leap 1995 Dec 31 23:59:60 + S Leap 1997 Jun 30 23:59:60 + S Leap 1998 Dec 31 23:59:60 + S Leap 2005 Dec 31 23:59:60 + S Leap 2008 Dec 31 23:59:60 + S Leap 2012 Jun 30 23:59:60 + S # INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) # # SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE # # SERVICE DE LA ROTATION TERRESTRE # OBSERVATOIRE DE PARIS # 61, Av. de l'Observatoire 75014 PARIS (France) # Tel. : 33 (0) 1 40 51 22 26 # FAX : 33 (0) 1 40 51 22 91 # Internet : services.iers@obspm.fr
On Jul 3, 2012, at 5:06 PM, Peter Lothberg wrote:
On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no "-"
No, but they're allowed; see Figure 9 of RFC 5905: LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9. +-------+----------------------------------------+ | Value | Meaning | +-------+----------------------------------------+ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +-------+----------------------------------------+ Figure 9: Leap Indicator --Steve Bellovin, https://www.cs.columbia.edu/~smb
On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no "-" No, but they're allowed; see Figure 9 of RFC 5905:
Steve, I commented that it was stated that we where doing both positive and negative corrections. Only positive corrections have been made, and yes, negative are possible. I pointed out in a previous post that we can count 57, 58, 00 or 57, 58, 59, 00 or 57, 58, 59, 60, 00. And actually, this is the only thing operating-systems and applications need to be capable to handle to make it a non_issue.
LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9.
+-------+----------------------------------------+ | Value | Meaning | +-------+----------------------------------------+ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +-------+----------------------------------------+
That's NTP packet format, used to implemment NTP's represenation of UTC, but not the definition of UTC... (What do I do if I receive a packet with "3".) Or better, all the UTC(k) are free-running and the (old) recomenadtion was to try to keep them within 1us, is that unsyncronized -:) And ooops, I did not catch that before, should it not say "last minute of the month"? If I remember right the posix standard don't allow "60" in seconds... -Peter
On Jul 5, 2012, at 10:49 48AM, Peter Lothberg wrote:
On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no "-" No, but they're allowed; see Figure 9 of RFC 5905:
Steve,
I commented that it was stated that we where doing both positive and negative corrections. Only positive corrections have been made, and yes, negative are possible.
I pointed out in a previous post that we can count 57, 58, 00 or 57, 58, 59, 00 or 57, 58, 59, 60, 00. And actually, this is the only thing operating-systems and applications need to be capable to handle to make it a non_issue.
Fair enough.
LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9.
+-------+----------------------------------------+ | Value | Meaning | +-------+----------------------------------------+ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +-------+----------------------------------------+
That's NTP packet format, used to implemment NTP's represenation of UTC, but not the definition of UTC... (What do I do if I receive a packet with "3".) Or better, all the UTC(k) are free-running and the (old) recomenadtion was to try to keep them within 1us, is that unsyncronized -:)
And ooops, I did not catch that before, should it not say "last minute of the month"?
The text as I copied it is certainly not consistent...
If I remember right the posix standard don't allow "60" in seconds...
-Peter
--Steve Bellovin, https://www.cs.columbia.edu/~smb
On Jul 3, 2012, at 1:54 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync.
IIRC, isn't it: Add a leap day every 4 years. Exception: If the year ends in 00, do not add a leap day. (an exception seemingly glossed over in the thread so far) Exception to the exception: If the year is a multiple of 400, add a leap day. (so called 400 hack) With that set of rules, we get close enough to only fudge by a second here and there. Owen
On Tue, Jul 03, 2012 at 04:54:24PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said:
Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds.
That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync.
The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule.
Leap Seconds and Leap Years are completely unrelated and solve two completely different problems. Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours. Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days. Without leap seconds, the sun stops being overhead at noon. Without leap years, the equinozes and solstices start drifting to different days. -- Brett
On Wed, 04 Jul 2012 12:44:40 -0500, Brett Frankenberger said:
Leap Seconds and Leap Years are completely unrelated and solve two completely different problems.
Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours.
Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days.
Actually, it's the same exact problem - an astronomical value isn't exactly conformant to the civil value, and thus adjustments are needed. And you missed the bigger point - that leap seconds aren't needed because the earth is slowing any more than leap days are needed because the year is getting longer. If an actual siderial day was a fixed unchanging 86400.005 seconds long, you'd still need a leap second every 200 days. *SLOWING* would be indicated by the "every 200 days" changing to "every 175" or "every 150". For bonus points - at the current rate of slowing, in what year will the day be of sufficient length that the current "rule of 400" for leap days requires changing? You may assume that the orbital parameters of the Earth do not also change. :)
On Wed, Jul 04, 2012 at 05:02:02PM -0400, valdis.kletnieks@vt.edu wrote:
On Wed, 04 Jul 2012 12:44:40 -0500, Brett Frankenberger said:
Leap Seconds and Leap Years are completely unrelated and solve two completely different problems.
Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours.
Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days.
Actually, it's the same exact problem - an astronomical value isn't exactly conformant to the civil value, and thus adjustments are needed.
No. Leap Years arise because the solar year is not an integral multiple of the solar day. Yes, you can argue that leap years exist because the Earth doesn't revolve around the sun in 86400*365 seconds, but that missed the underlying point that since well before civil time differed from solar time, people have defined a year in terms of days, preferring not to have years starting a midnight, then dawn, then noon, then dusk, and so on. Leap years have existed since well before civil time and solar time were any different.
And you missed the bigger point - that leap seconds aren't needed because the earth is slowing any more than leap days are needed because the year is getting longer. If an actual siderial day was a fixed unchanging 86400.005 seconds long, you'd still need a leap second every 200 days. *SLOWING* would be indicated by the "every 200 days" changing to "every 175" or "every 150".
I assume you meant "solar" instead of "[sidereal]" -- the sidereal day hasn't been 86400.anything seconds ever. And if the mean solar day were unchanging, then it would be 86400 civil seconds today, just like it was (by definition) in 1900. The civil second was initially defined as 1/86400 of the mean solar day in 1900 (then later redefined based on radiation from the cesium atom, but the redefinition didn't change the length of the second by enough to matter for the purposes of this discission). The only reason the mean solar day today isn't 86400 is because the Earth's rotation has slowed since 1900 and we've elected to not redefine the length of a second. Yes, technically, you're right that if the Earth's rotation rate were constant and were such that the mean solar day were 86400.005 seconds long, we'd still need leap sections. But that's a highly unlikely counterfactual hypothetical, because, again, if the Earth weren't slowing, then 1/86400-of-mean-solar-day defintion of the second would still hold. There's virtually no chance that on a hypothetical Earth that wasn't slowing, that population would have decided that the second should be 1/86400.005 of a solar day. -- Brett
On Wed, 04 Jul 2012 21:01:50 -0500, Brett Frankenberger said:
No. Leap Years arise because the solar year is not an integral multiple of the solar day.
And leap seconds arise because the astronomical day is not an integral multiple of the hour, minute, or second. Same problem.
still hold. There's virtually no chance that on a hypothetical Earth that wasn't slowing, that population would have decided that the second should be 1/86400.005 of a solar day.
Look up the *original* definition of the meter, and think about the phrase "measurement error".
On Wed, Jul 4, 2012 at 1:44 PM, Brett Frankenberger <rbf+nanog@panix.com> wrote:
Without leap seconds, the sun stops being overhead at noon.
But that's ridiculous. The sun *isn't* overhead at noon except at one particular longitude within each time zone. Everywhere else time synch to local noon is +/- half an hour. IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, Jul 04, 2012 at 06:10:45PM -0400, William Herrin wrote:
On Wed, Jul 4, 2012 at 1:44 PM, Brett Frankenberger <rbf+nanog@panix.com> wrote:
Without leap seconds, the sun stops being overhead at noon.
But that's ridiculous. The sun *isn't* overhead at noon except at one particular longitude within each time zone. Everywhere else time synch to local noon is +/- half an hour.
IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise.
Yeah but what you don't understand is that manual navigation after a certain point of difference becomes inaccurate to a degree that is unacceptable by most military standards. 100 or a 1000 years the difference is too big. Someone somewhere at some point evaluated this need in the range of "0.3 - 0.9? in order for nauticle and other means of direction to not be impacted. It would be easy to disagree and say "Well! we have GPS and other such digital devices to tell where you are now!"... and if those go out just like all these failing Java Apps ?. I would not want to be the guy that would have to calculate all possible differences just to attempt to get a accurate location and then find out the math was wrong and you are 100 miles off target. Just sayin! -- - (2^(N-1))
On Jul 4, 2012, at 3:29 PM, Jason Hellenthal <jhellenthal@dataix.net> wrote:
Yeah but what you don't understand is that manual navigation after a certain point of difference becomes inaccurate to a degree that is unacceptable by most military standards.
Manual navigation (sextant, etc) is dead. It's not taught for new pilots or mariners / navigators. A few hobbyists still learn that, but they can easily keep a solar-true time clock around if they wish. Maintaining any time standard for that purpose is not supported. It's no reason for the timekeepers, nothing we need to care about. The few navigation systems that look at the sun and stars have - and inherently need - better time reference than the allowed 0.9 sec before we leap. They already handle this internally. That 0.9 sec max error comes to up to about 400 meters for equitorial surface nav or 6500 for orbital objects (or suborbital - cough). Already unacceptable... George William Herbert Sent from my iPhone
On 7/4/12, William Herrin <bill@herrin.us> wrote:
IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. [snip]
Instead of having leap seconds; redraw the world timezone map, so that the boundaries of every time zone are shifted by a distance in feet that corresponds to one second; and such that after a thousand years and an hour's worth of leap seconds, the physical locations of the timezones will have shifted just so far, that there is a 1 hour adjustment. :) -- -JH
On Jul 4, 2012, at 8:39 PM, Jimmy Hess wrote:
On 7/4/12, William Herrin <bill@herrin.us> wrote:
IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. [snip]
Instead of having leap seconds; redraw the world timezone map, so that the boundaries of every time zone are shifted by a distance in feet that corresponds to one second; and such that after a thousand years and an hour's worth of leap seconds, the physical locations of the timezones will have shifted just so far, that there is a 1 hour adjustment. :)
-- -JH
Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Owen
On 7/4/12 8:48 PM, Owen DeLong wrote:
Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Owen Before we had timezones your clock offset was forward or backward 4 minutes every-time you crossed a meridian.
On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote:
Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly.
Russian govt. did eliminate DST. http://www.rt.com/news/daylight-saving-time-abolished/ --vadim
On Jul 5, 2012, at 1:35 PM, Vadim Antonov wrote:
On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote:
Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly.
Russian govt. did eliminate DST.
:) http://themoscownews.com/vote/20120629/189902272-results.html
--vadim
On Thu, 2012-07-05 at 14:00 +0400, Dmitry Burkov wrote:
On Jul 5, 2012, at 1:35 PM, Vadim Antonov wrote:
On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote:
Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly.
Russian govt. did eliminate DST.
:) http://themoscownews.com/vote/20120629/189902272-results.html
75.9% of people are dimwits :) --vadim
On 05/07/2012 11:34, Jared Mauch wrote:
Live further north and you will see the difference dst makes.
This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win. Nick
On 05/07/12 13:05, Nick Hilliard wrote:
On 05/07/2012 11:34, Jared Mauch wrote:
Live further north and you will see the difference dst makes.
This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win.
Nick
Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh. Henning
On Jul 5, 2012, at 7:18 AM, Henning Stener <h.stener@sportradar.com> wrote:
On 05/07/12 13:05, Nick Hilliard wrote:
On 05/07/2012 11:34, Jared Mauch wrote:
Live further north and you will see the difference dst makes.
This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win.
Nick
Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh.
I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense.
"I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly." "There is a band of latitudes where it does make more sense." It sure isn't Indiana. http://thinkprogress.org/climate/2010/03/13/205642/daylight-saving-time-ener... On 07/05/2012 07:25 AM, Jared Mauch wrote:
On Jul 5, 2012, at 7:18 AM, Henning Stener <h.stener@sportradar.com> wrote:
On 05/07/12 13:05, Nick Hilliard wrote:
Live further north and you will see the difference dst makes. This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and
On 05/07/2012 11:34, Jared Mauch wrote: the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win.
Nick
Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh. I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly.
There is a band of latitudes where it does make more sense.
On Thu, Jul 05, 2012 at 09:33:05AM -0700, Owen DeLong wrote:
I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly.
There is a band of latitudes where it does make more sense.
Why punish the rest of us to accommodate a few people who live between about 50º and 55º latitude?
(easier typing with a real keyboard)... This is a local/states rights issue imho :) AZ ignores DST and as a result I never know what time it is there ;) This is a local state-by-state and county-by-county issue as evidenced by the behavior of counties in Indiana that are close to or within the Chicago MSA. This is more a social issue than anything else. Many people prefer some daylight when they are not working. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Jul 5, 2012, at 10:07 AM, Jared Mauch wrote:
On Thu, Jul 05, 2012 at 09:33:05AM -0700, Owen DeLong wrote:
I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly.
There is a band of latitudes where it does make more sense.
Why punish the rest of us to accommodate a few people who live between about 50º and 55º latitude?
(easier typing with a real keyboard)...
This is a local/states rights issue imho :) AZ ignores DST and as a result I never know what time it is there ;)
This is a local state-by-state and county-by-county issue as evidenced by the behavior of counties in Indiana that are close to or within the Chicago MSA. This is more a social issue than anything else.
Many people prefer some daylight when they are not working.
As do I... Which, if we simply go with PDT all year long, I'd basically have most of the year. I don't get that with standard time during winter anyway and PDT wouldn't help with that. Daylight time does not add length to the daylight period of the day, it merely reduces the time between wake-up and daylight for some portion of winter time. (Standard time has become the anomaly with daylight savings time being practiced for nearly 8 months each year now). I'm fine with leaving all the clocks permanently on daylight time. Just get rid of the twice-a-year timezone shift. I don't care what timezone we pick, just pick one and stick with it. Owen
On Thu, Jul 05, 2012 at 01:07:04PM -0400, Jared Mauch wrote:
This is a local/states rights issue imho :) AZ ignores DST and as a result I never know what time it is there ;)
AZ actually tried DST for a year, and then came to a couple of conclusions: 1) The state with the highest insolation in the country really has no need to conserve daylight. 2) It actually wastes energy here by driving more business air conditoning use. As for how it actually works: It's very simple. I never touch my clocks unless I'm setting or winding them. It's fantastic. Where this falls down: Outlook will still attempt to scramble your calendar based on other people's silly clock change. Your phone will tell you it's updated the clock for DST...when it hasn't. Or worse, despite being set for no DST change, it'll do it. Some will even lock up. There's lots and lots of broken time of day code out there. People don't understand the distinction between, say, Mountain Standard Time, and Mountain Daylight Time (Equinix, I'm looking at *YOU* -- your MST setting in the portal is not, in fact, MST. There's no option appropriate for me at all.) Everyone keeps asking you what time it is 'there' because they can't wrap their brains around a static -7 offset. Anyway, given the number of software bugs around the DST change, the leap is the least of our worries. Perhaps we should stop rewarding people that write bad code. --msa
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime.
On 7/5/2012 12:47 AM, Roy wrote:
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system.
You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime.
Oblig: http://xkcd.com/927/ - Pete
On 7/4/2012 10:06 PM, Peter Kristolaitis wrote:
On 7/5/2012 12:47 AM, Roy wrote:
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system.
You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime.
Oblig: http://xkcd.com/927/
- Pete
Right on!
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system.
You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime.
And what do you do if "OpenTime" and "UTC" differs so that it matters? Do the fligt leave at 1200 UTC or 1200 OpenTime? Most countries have a law that says something like "measurement is to be traceable to a national standard" for legal and trade use. (weight, mass, volume, current, time ...). For those who don't knew, none of the national labs that have local representation of UTC have the EXACT same time. So if there is a dispute you need to be able to show traceability to YOUR national lab. -P
On 7/5/2012 5:54 PM, Peter Lothberg wrote:
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system.
You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime. And what do you do if "OpenTime" and "UTC" differs so that it matters?
Do the fligt leave at 1200 UTC or 1200 OpenTime?
...
Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
On Thu 2012-07-05T10:26:22 -0700, Roy hath writ:
Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute
There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html
Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On 7/5/2012 10:42 AM, Steve Allen wrote:
On Thu 2012-07-05T10:26:22 -0700, Roy hath writ:
Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html
Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime. Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html
...
So basically the concept of OpenTime is already implemented. All that's needed is a list of Stratum-1 servers that anyone can use.
On Thu, Jul 5, 2012 at 2:02 PM, Roy <r.engehausen@gmail.com> wrote:
On 7/5/2012 10:42 AM, Steve Allen wrote:
On Thu 2012-07-05T10:26:22 -0700, Roy hath writ:
Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute
There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html
Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html
...
So basically the concept of OpenTime is already implemented. All that's needed is a list of Stratum-1 servers that anyone can use.
From the website:
The scheme described in this web page uses a non-standard NTP server and a non-standard set of "right" zoneinfo files. The hard part is that the zoneinfo files must be hacked for GPS time and recompiled whenever a leap second is announced. Hopefully that recompile happens long before the leap second occurs. In this scheme the kernel does not have to handle the leap second. All of the handling of the leap second happens in the zoneinfo files. This is effectively the same as the bi-annual handling of daylight/summer time transitions. There are no real-time changes. Everything about the changes can be easily tested at any time by any user. ---- Wouldn't an easier way to be separate out the timescales where one is just 84600 seconds a day for the next 100 years, and another can keep accurate time for those that need that kind of accuracy? The POSIX standard can remain unchanged, and time can be monotonic. When the cumulative difference like like 5 minutes, we can have a huge pubic 5 year lead time thing to sync the timescales again. (Kind of like DST, no mater how publicly and how often and how well you tell people, folks will still show up to work late).
From the website again:
A system whose time_t is set using an NTP server giving GPS time (thus the kernel does not have to handle leap seconds) and which is configured to use the usual zoneinfo files will produce formatted date/time strings which are 15 seconds larger than official time. (The value 15 will increment at each leap second.) According to the developer forums this is the variation that Google has chosen for Android devices. ---- This seems like a good kludge. But a second is an arbitrary measure. We might as well add leap half seconds, or leap tenths of a second. I'd prefer leap minutes, so we can have these kinds of threads about 1/60th of the time :) Not that I don't find this entertaining.
On Thu, Jul 05, 2012 at 10:26:22AM -0700, Roy wrote:
Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
Obviously you need a machine time, which is monotonous, high-resolution (you don't need too many bits even if you resolve down to Planck time and gigayears) and works on any planetary body or in space at any speed, and a human time, which is dynamically derived from machine time, using algorithms depending on particular location and occasion. The sooner we can separate the machine time from people time, the better.
On Wed, Jul 04, 2012 at 06:10:45PM -0400, William Herrin wrote:
IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise.
Notice that already InterplaNet requires a time base not linked to a particular planetary body. If we're looking at kiloyear scales, then either nobody will care about celestial dynamics of a particular planetary body, or nobody will care about precise time standards any longer.
And I forgot: They made a "mistake" and missed their intentions of a solar day year 1900 when defining the atomic second. Off by 2s in 100 years. -p
Peter Lothberg <roll@Stupi.SE> wrote:
And I forgot: They made a "mistake" and missed their intentions of a solar day year 1900 when defining the atomic second. Off by 2s in 100 years.
No that is not correct, or at least it's nowhere near as simple as that. The atomic second was matched to the second of ephemeris time, and that was based on Newcomb's tables of the sun, which in effect used the average length of the second from the 1800s. http://ucolick.org/~sla/leapsecs/dutc.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 4 or 5, increasing 6 at times. Moderate. Occasional rain, fog patches. Moderate, occasionally very poor.
On Sat, Jun 30, 2012 at 04:43:16PM -1000, Paul Graydon wrote:
On 6/30/2012 3:16 PM, Paul WALL wrote:
Comments?
Not very well if you have a modern box (RHES/CentOS 6) and Java apps running on them. RHES/CentOS 5 merrily ignored it. Worse, just bouncing the Java stack didn't fix it, it required the box to be rebooted.
i didn't reboot: /etc/init.d/ntp stop date `date +"%m%d%H%M%C%y.%S"` /etc/init.d/ntp start seems to calm things right back to normal. --jim -- Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead"
A useful explanation may be found here: http://blogs.discovermagazine.com/badastronomy/2012/06/30/wait-just-a-second... ---rsk
http://www.sciencedaily.com/releases/2012/06/120629142607.htm ________________________________ From: Paul WALL <pauldotwall@gmail.com> To: NANOG list <nanog@nanog.org> Sent: Saturday, June 30, 2012 6:16 PM Subject: F-ckin Leap Seconds, how do they work? Comments? Drive Slow Paul
participants (53)
-
Alex Harrowell
-
AP NANOG
-
Brett Frankenberger
-
Bryan Horstmann-Allen
-
Chris Adams
-
Christopher Morrow
-
Chuck Anderson
-
Dave Hart
-
Derek Ivey
-
Dmitry Burkov
-
Donald Eastlake
-
Eugen Leitl
-
George Bonser
-
George Herbert
-
Henning Stener
-
Henry Linneweh
-
Jared Mauch
-
Jason Hellenthal
-
Jay Ashworth
-
Jim Mercer
-
Jimmy Hess
-
joel jaeggli
-
Joel jaeggli
-
Joly MacFie
-
Keith Medcalf
-
Leo Bicknell
-
Majdi S. Abbas
-
Marshall Eubanks
-
Matthew Palmer
-
Michael Thomas
-
Nick Hilliard
-
Owen DeLong
-
Paul Graydon
-
Paul WALL
-
Peter Kristolaitis
-
Peter Lothberg
-
Randy Fischer
-
Raymond Dijkxhoorn
-
Rich Kulawiec
-
Richard Irving
-
Robert Bonomi
-
Robert E. Seastrom
-
Roy
-
Saku Ytti
-
Scott Howard
-
Steve Allen
-
Steven Bellovin
-
Tony Finch
-
Tyler Haske
-
Vadim Antonov
-
valdis.kletnieks@vt.edu
-
William Herrin
-
Wolfgang S. Rupprecht