Re: [ntp:questions] Leap second to be introduced in June
Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité. Benjimin Franklin Le 16 janv. 2015 à 08:42, Harlan Stenn st...@ntp.org a écrit : Terje Mathisen writes: cmad...@cmadams.net (Chris Adams) wrote: Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. The General Timestamp API handles this case, as those timestamps track the version number of the timescale. If you specify noon at (some future date), an absolute timestamp, and between now and then some leap seconds are added, they'll be added here, too. How can we take into account an unknown number of leaps? I will listen attentively to your presentation in Bruxelles. I can see how it might be feasible…. But I will have to check with Schrodinger's cat first. And this is _exactly_ why it is always a bad idea to use (UTC) seconds for those future timestamps: If you actually mean that something has to happen N seconds from now, that future timestamp has to be in TAI, since using UTC would obviously blow up across any leap second, right? If one used a relative/difference timestamp for this, then we're in the same boat and we might need some sort of trigger or signal to indicate that a leap event has happened. We're often in a similar boat though, if the clock steps during the interval this relative/difference timestamp covers. This should arguably be an option for cron jobs and timer events. cron is a notoriously bad scheduler. It only wakes up every minute to check the schedule tasks, so you can’t be sure of getting accurate execution times. It am not sure it is relevant either, as events are scheduled in terms of absolute times so will be correct whether or not a leap second is scheduled. Task execution on a callback, interval timer event is different. One scheduled for execution in 5 seconds, 3 seconds prior to a positive leap second will get dispatched 4 TAI seconds later, but from a legal point of view will be dead on. However if that is not already fixed, it could be. H -- If you instead meant a calendar event, then you need a different timescale which is either Julian Day Number (JDN) or YMD, followed by either HMS or an offset into the day, followed by the applicable time zone. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
strange response! Le 11 janv. 2015 à 21:18, Paul tik-...@bodosom.net a écrit : Why do folks mention leap seconds on this list? part of the NTP protocol deals with the scheduling insertion/deletion of leap seconds. Why do people point to leap-seconds.NTPtimestamp instead of just leap-seconds.list? leap-seconds.list is not the file itself, but a symbolic link, which in itself contains no relevant information other than the pathname, in this case relative, to the actual file. The symbolic link leap-seconds.list does not exist on some repositories of the information, for example on the navy server tyco. Using the full timestamped name is also the only way of unambiguously identifying this data. The time stamp differs on different sources. My five line leap second file with comments and one extra line for (completely unnecessary) context. #$ 3629404800 #@ 3660249600 3550089600 35 # 1 Jul 2012 3644697600 36 # 1 Jul 2015 #h 6eb5f274 cb8c4f5d 6ac15b69 6b095017 f219e7c ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? Yes. How large is the adjustment to be smeared out? 1 seconds. It was a test to see how useful is smearing when bringing an isolated network back to UTC in a controlled manner. The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? The frequency is changing too quickly at start (2nd derivative is at the maximum) and the clients don't have a chance to shorten their polling interval to better track the server. The point is that there are better functions than cosine for this. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/27/2015 10:16 AM, Terje Mathisen wrote: Jochen Bern wrote: Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. OK, but that's assuming that the client will absorb the leap second entirely by having an NTP server dragging it along within the limits of a normal NTP sync, without *ever* informing the client kernel's leap second handling routines that one even occurred. Which means that your client cannot be talking to a normal NTP server with normal NTP client s/w, and if kernels ever would attempt to keep track of past leap seconds on their own, *this* client's kernel would fail in that because it never gets *told* of leap seconds as they happen. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/26/2015 01:03 PM, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. I noticed that it lends itself to such properties (even if Googles specific implementation fails to do so). However, you pay for it either in a long window needed to perform the smear, on in some of said derivatives going *way* off their normal values. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. it weren't announced that NTPv5 will support labelling the actual timescale used, I'ld propose that future kernels SHOULD not only accept leap second upcoming bits from an NTP client s/w, but also hand leap second handling in progress bits back, so as to allow the s/w to mark itself as unsynced via NTP until the effects are over. That is already possible, via the leap bits, i.e. declare yourself unsynced if contacted from outside the designated smear region? Terje Regards, J. Bern -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Miroslav Lichvar wrote: On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? Yes. How large is the adjustment to be smeared out? 1 seconds. It was a test to see how useful is smearing when bringing an isolated network back to UTC in a controlled manner. 10K seconds in 1M seconds corresponds to a steering rate of 1:100 or 10K ppm, i.e. 20 times higher than the maximum ntpd adjustment rate. How would you expect it to work under those conditions? The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? The frequency is changing too quickly at start (2nd derivative is at the maximum) and the clients don't have a chance to shorten their polling interval to better track the server. The point is that there are better functions than cosine for this. OK, when the adjustment is way outside the control range for ntpd, then you are obviously correct: ntpd, either with or without smearing, is not the best tool. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen terje.mathi...@tmsw.no writes: The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. The point is that it is not smooth where it joins on to the regular passage of time... It is possible to do this in an infinitely smooth way, but using the cos formula just gives a few continuous derivatives. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Malone wrote: Terje Mathisen terje.mathi...@tmsw.no writes: The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. The point is that it is not smooth where it joins on to the regular passage of time... It is possible to do this in an infinitely smooth way, but using the cos formula just gives a few continuous derivatives. Mea Culpa. You are of course right. I can even see how using exponential functions with a totally flat tail would allow you to get arbitrarily close to the desired smoothness, but in the real world what we care about is to make the steering something that the normal ntpd control loop handles without breaking a sweat, i.e. in the same magnitude as the usual temperature-induced frequency swings. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/27/2015 10:16 AM, Terje Mathisen wrote: Jochen Bern wrote: Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. OK, but that's assuming that the client will absorb the leap second entirely by having an NTP server dragging it along within the limits of a normal NTP sync, without *ever* informing the client kernel's leap second handling routines that one even occurred. Which means that your client cannot be talking to a normal NTP server with normal NTP client s/w, and if kernels ever would attempt to keep track of past leap seconds on their own, *this* client's kernel would fail in that because it never gets *told* of leap seconds as they happen. That's correct, in all particulars, and as you note, it basically introduces a separate ntp domain for those servers that take part in this charade. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/22/2015 07:04 PM, William Unruh wrote: General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. (Bad choice because relativity says that clocks down the gravity well run faster, but we've been ignoring that fact so far, anyway, so ...) [...] while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. Actually I agree with that last sentence, but not in the way you expect. It's the *metric* that UTC defines, along with the representation, that makes the function continuous. Basically, UTC not only says that 23:59:60 is valid and shall be ordered between 23:59:59 and 00:00:00, but that it represents one SI second (as measured with any suitable instrument) wherever it is officially inserted. Hence, the difference between 23:59:59.9 UTC and 00:00:00.1 UTC is 0.2 SI seconds wherever a leap second is *not* inserted, and 1.2 SI seconds where it is, *because that's what you were told how to count it*, and since computing the difference between the two UTC timestamps (with a list of past and present leap seconds at hand) correspondingly results in 0.2 UTC seconds or 1.2 UTC seconds unless the timestamps are in the uncertain future, the two notions still agree down to any resolution you want - continuous, linear, derivative with slope = 1. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. UTC says that leap seconds are part of the UTC representation of time (i.e., on the conversion function's ordinate) and correspond to an actual SI second of physical time that passes (i.e., it's present on the abscissa as well). Your refusing both punches a square hole, one square second large, into the function's graph - that's not a discontinuity in a strict sense, it's a stretch where the function remains undefined by your refusal to acknowledge the definition. Anyone willing to re-insert that square with the diagonal line on it into the graph gets a straight line from one edge of the paper to the other, and has no reason whatsoever to see a discontinuity. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen terje.mathi...@tmsw.no writes: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Doesn't it only have two smooth deritives at the end points or [-w:w]? The usual function is constant 1 with all derivatves zero, and so this is what the derivative should be at the endpoints. They use (1.0 - cos(pi * t / w)) / 2.0, which is 1 at both end point, has first derative zero, but the second deritive is -pi*pi/w/w. (It should be possible to stitch together something that is infinitely smooth, probably using exp(-1/(x*x)), but it would requite a bit more work.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: Sorry for the delay, I'm *still* not back to my usual workplace ... On 01/21/2015 11:39 AM, Mike Cook wrote: I couldn’t find a definition of a monotonous function. Does it exist? As David already suggested, I learnt my math in Germany - and switched to CS before taking a shot at a PhD, which would have required me to tear into actual current research, which would have been written in English. So yes, (streng) monoton should have been translated as (strictly) monotonic, not (strictly) monotonous. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) The function can be non-linear. See below. Yes. In particular, implementing a leap second by decelerating your all minutes have 60 seconds clock results in a conversion function that is monotonic and continuous, but not linear. In the case of having it run at half its normal speed for two seconds, it would qualify as piecewise linear - and not have a defined derivative at the switchover points. One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions. Well, if you want to put it that way, yes. Though unavailability of leap second info within whatever system they're designing (say, a mechanic wrist watch worn by an average human) is a pretty *solid* reason to claim inability to do so. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. They could have chosen a better function though. If its second derivative (wander) started at zero, the NTP clients could adjust their polling interval if necessary before the error gets large and the maximum error between the clients could be minimized. Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/26/2015 01:03 PM, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. I noticed that it lends itself to such properties (even if Googles specific implementation fails to do so). However, you pay for it either in a long window needed to perform the smear, on in some of said derivatives going *way* off their normal values. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If it weren't announced that NTPv5 will support labelling the actual timescale used, I'ld propose that future kernels SHOULD not only accept leap second upcoming bits from an NTP client s/w, but also hand leap second handling in progress bits back, so as to allow the s/w to mark itself as unsynced via NTP until the effects are over. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, Terje Mathisen terje.mathi...@tmsw.no wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Nope. The function 1 x0; -1, xpi, cos(x) otherwise is continuous and its first derivative is continuous, but its second derivative is not, and its third does not exist at x=0 and pi. It is NOT maximally smooth. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. No. It arises from the fact that the second is defined according to a physical principle ( the frequency of oscillation of a cesium atom in a certain transition) and the rotation of the earth. It used to be defined by the rotation of the earth (which was the best clock available) 86400 seconds in a mean solar day. But as you say, defined in terms of the oscillations of that transition, the length of the day can vary-- both because of the moon and because of things like earthquakes and global warming. Were we to define the mean solar day as 86400 sec, then it would always be 86400 sec. But theory says that that would make the behaviour of may other systems much more difficult to describe. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, William Unruh un...@invalid.ca wrote: On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. No. It arises from the fact that the second is defined according to a physical principle ( the frequency of oscillation of a cesium atom in a certain transition) and the rotation of the earth. It used to be defined ^not by the rotation of the earth (which was the best clock available) 86400 seconds in a mean solar day. But as you say, defined in terms of the oscillations of that transition, the length of the day can vary-- both because of the moon and because of things like earthquakes and global warming. Were we to define the mean solar day as 86400 sec, then it would always be 86400 sec. But theory says that that would make the behaviour of may other systems much more difficult to describe. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 26/01/15 17:11, William Unruh wrote: physical principle ( the frequency of oscillation of a cesium atom in a XX certain transition) and the rotation of the earth. It used to be defined ^not It's a quantum spin flip. There is no physical oscillation. Not that that really changes anything about UTC or TAI. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Malone wrote: Terje Mathisen terje.mathi...@tmsw.no writes: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Doesn't it only have two smooth deritives at the end points or [-w:w]? The usual function is constant 1 with all derivatves zero, and so this is what the derivative should be at the endpoints. They use (1.0 - cos(pi * t / w)) / 2.0, which is 1 at both end point, has first derative zero, but the second deritive is -pi*pi/w/w. The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. Google uses a half cosine, i.e. something like adjustment = (1-cos(t * pi/adjustment_period))*adjustment_value/2; Since the adjustment_value is +/- a second, the normal form is adjustment = (1-cos(t*pi/adjustment_period))/2; which is zero at t=0 and +1 at t==adjustment_period. (It should be possible to stitch together something that is infinitely smooth, probably using exp(-1/(x*x)), but it would requite a bit more work.) Doesn't seem to be needed? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Miroslav Lichvar wrote: On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. They could have chosen a better function though. If its second derivative (wander) started at zero, the NTP clients could adjust their polling interval if necessary before the error gets large and the maximum error between the clients could be minimized. Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? How large is the adjustment to be smeared out? The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, David Woolley david@ex.djwhome.demon.invalid wrote: On 26/01/15 17:11, William Unruh wrote: physical principle ( the frequency of oscillation of a cesium atom in a XX certain transition) and the rotation of the earth. It used to be defined ^not It's a quantum spin flip. There is no physical oscillation. Not that that really changes anything about UTC or TAI. Tell that to the electromagnetic wave that comes out of the atom. The energy of that spin flip corresponds directly to a frequency via Planck's constant. And yes, an actual frequency of oscillation of the EM field. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
I'm expecting that NTPv5 will include things like the timescale used by the timestamp, so as long as the systems agree on how to convert timescales if they are not the same between the client and server (hello, General Timestamp API) it will be OK if an NTPv4 or NTPv5 box talks to an NTPv5 box, as the V5 machines will handle timescale conversions and we can specify in the Standard that v4 boxes speak POSIX, so the machine running the smear must do a conversion. I'll be talking about this a bit in my FOSDEM talk. And while there is much to appreciate about the half-cosine smear, one thing some folks *hate* about it is that time from these machines is wrong on both frequency *and* time, to varying degrees, throughout the day. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern writes: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via = NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? Nobody has talked to me, the NTP Project, or NTF about it. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Sorry for the delay, I'm *still* not back to my usual workplace ... On 01/21/2015 11:39 AM, Mike Cook wrote: I couldn’t find a definition of a monotonous function. Does it exist? As David already suggested, I learnt my math in Germany - and switched to CS before taking a shot at a PhD, which would have required me to tear into actual current research, which would have been written in English. So yes, (streng) monoton should have been translated as (strictly) monotonic, not (strictly) monotonous. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) The function can be non-linear. See below. Yes. In particular, implementing a leap second by decelerating your all minutes have 60 seconds clock results in a conversion function that is monotonic and continuous, but not linear. In the case of having it run at half its normal speed for two seconds, it would qualify as piecewise linear - and not have a defined derivative at the switchover points. For the first version, let us assume that the codomain and its metric have leap seconds incorporated in the same way TAI's codomain integrates leap days. In other words, the metric knows that the distance between 31-Mar-2015 23:59:00 and 01-Apr-2015 00:00:00 is 60 seconds but the one between 30-Jun-2015 23:59:00 and 01-Jul-2015 00:00:00 is 61 seconds. The first result would, of course, be that it's now the metric that fails to be fully defined, as (most of) the future leap seconds are not yet known. This does not prevent the metric from being fully defined. The definition of UTC includes the definition of when a leap second will be inserted without limit to time. 1.1 The magnitude of DUT1 should not exceed 0.8 s. 1.2 The departure of UTC from UT1 should not exceed 0.9 s (see Note 1). 1.3 The deviation of (UTC plus DUT1) should not exceed 0.1 s. There must be a field of maths which includes that notion of « fuzziness ». Yes, but traditional functional analysis isn't it. :-} (Statistics or Limitation Theory come to mind, but I don't have a specific concept on the top of my mind.) The definition of continuous involves looking at arbitrarily small intervals around the points in question. A metric saying that the distance between two points in the future cannot be guaranteed to ever get smaller than the uncertainty means that no such intervals exist, and the definition of continuous falls flat on its face. Variant 2b. It is also conceivable to have a mechanical watch with 61 second divisions, a couple of buttons on the side to push for +/- leap seconds and cams which show/hide the relevant tick marks and speed the second hand from 58 through 0 accordingly at the rate of one SI second I doubt we'll ever see such a *mechanic* watch being made. An *analog* (with hands, and supposedly step motors and electronics driving them, or faking hands with an LCD display or somesuch) or outright digital one, sure. Yes, the conversion to the timescale defined by that watch's second hand's movement would be monotonic, continuous, piecewise linear, invertible, etc.. It still needs additional input (the +/- buttons) to remain true, and entirely separate data (historic list of leap seconds, preferably with checkmarks that the buttons *were* pressed) to accurately compute the time that passed between two readings, though. Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions. Well, if you want to put it that way, yes. Though unavailability of leap second info within whatever system they're designing (say, a mechanic wrist watch worn by an average human) is a pretty *solid* reason to claim inability to do so. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Anyone wanting to check whether they are being fed spurious leap-second information may like to try my Leap Trace program, available as a Windows GUI and command-line program, and as a Perl script for other OS. http://www.satsignal.eu/software/net.htm#NTPLeapTrace -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Friday, January 23, 2015 at 3:55:02 AM UTC-5, Marco Marongiu wrote: On 21/01/15 15:31, Mike S wrote: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. Two days ago I've been interviewed by the Italian national radio broadcaster about the leap second. It was between 11:30-12:00 Rome time. Closing the interview the host asked me I guess you would be happy if the leap second was suppressed, you'd have quite less problems to handle, wouldn't you?!. And I replied I'd actually be happier if programmers did their job properly, for example not assuming that a minute always lasts 60 seconds, no matter what. Funny that 3 hours later, on the other side of the planet, you have written the same thing... It's a +1 from me, too. I guess it was clear ;-) Ciao -- bronto That was a cute response, but entirely misses the point of the problem with leap seconds. One can program in a leap second only if one knows it is coming. (Though I cannot program the leap second into my vintage 1855 Bond marine chronometer!) What shall you program about the end of June, 2016, or December, 2020? What will be the interval of time between now and then? If you imagine the Earth is a UTC clock, and a transit telescope pointing to the Sun represents the hour hand, we would like to be pointing at the Sun again 24 hrs later. But because the Earth is (now) a poor clock, sometimes it makes it all the way around in a day, and sometimes it does not. In 2015, the Earth is taking per day on average 1.0092 milliseconds more than 24 hours to make a complete rotation. And keep in mind that the estimated accuracy of the value of TAI-UTC 30 days out is three times that daily value, or 3.2 ms. That's the best we can do at present. By eliminating the artifice of leap seconds we no longer need historical tables to compute for example the interval of time between two points moving forward. Astronomers are there already in the use of TT (Terestrial Time) in the computation of ephemerides, which avoids the discontinuity of leap seconds. [Future inhabitants of Mars will have a completely different determination of leap seconds]. The US will soon be considering a means for dissemination of delta T via NTP, which further paves the way for practical elimination of leap seconds. The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, and the Swiss, who found support for both sides, has declared itself neutral (of course!) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/23/2015 2:03 PM, schmidt.r...@gmail.com wrote: What shall you program about the end of June, 2016, or December, 2020? What will be the interval of time between now and then? Depends. What are you doing which requires 1 second accuracy a year or 5 from now? Does it need to happen at a specific time, or a specific interval in the future? Even with all the problems POSIX has with time, cron would still make it happened at a specific time, except possibly during a very short period when a leap second actually occurs. And if you need it at a specific interval in the future, the problem's still not particularly difficult. Many programs need to handle things which are indeterminate in the future. Are you really unable to figure out how to do it, or are you trying to make a problem which doesn't really exist? Note, that if you need 1 second accuracy a year or 5 out, then unless you have an atomic clock you will need some external time input to stay in sync. There's no reason that external time input can't also provide upcoming leap second info well in advance. Either an Internet connection or GPS connection will provide that easily. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca writes: General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. As Mike points out, you've subtracted things in a way that doesn't really make sense to make this argument. Warner Losch has a good way of describing this as variable radix. For example, we don't describe the calendar as discontinuous, because months have 28, 29, 30 or 31 days. If you subtract Feb 27th from Mar 3rd, you need to know if it is a leap leap year, rather than say the answer is 7 days by assume all months have 31 days because most months do. My personal way of viewing the topology of the space labels, is that some second labels have multiple possible successor labels, and the leap seconds look like little loops around which UTC may or may not pass. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 21/01/15 15:31, Mike S wrote: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. Two days ago I've been interviewed by the Italian national radio broadcaster about the leap second. It was between 11:30-12:00 Rome time. Closing the interview the host asked me I guess you would be happy if the leap second was suppressed, you'd have quite less problems to handle, wouldn't you?!. And I replied I'd actually be happier if programmers did their job properly, for example not assuming that a minute always lasts 60 seconds, no matter what. Funny that 3 hours later, on the other side of the planet, you have written the same thing... It's a +1 from me, too. I guess it was clear ;-) Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 21/01/15 10:39, Mike Cook wrote: I couldn’t find a definition of a monotonous function. It's an obvious mis-choice of words by someone whose name suggests they aren't native English speaker. It clearly is intended to mean monotonic. See https://en.wikipedia.org/wiki/Monotonic_function for a definition. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S schrieb: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. +1 Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/22/2015 1:04 PM, William Unruh wrote: General relativity assures us that time exists and is measured by a metric... still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. But Jul 1 0:0:0(TAI) is not the same time as Jul 1 0:0:0(UTC), so you're subtracting an apple from an orange, and claiming you got a lemon. It's nonsensical. That for all purposes is a discontinuous function of the time as defined by General relativity. You're in way over your head. And, you're wrong. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S writes: Both TAI and UTC are continuous, and could in a non-standard way, be represented by real numbers (Time, below), where they wouldn't differ. TAI and UTC only differ in how they're labelled, as you say. It's POSIX which isn't monotonic or continuous, it repeats leap seconds. How they handle leap seconds: Time UTC TAI POSIX n+023:59:5800:00:33n+0 n+123:59:5900:00:34n+1 n+223:59:6000:00:35n+2 n+2.9 23:59:60.9 00:00:35.9 n+2.9 n+300:00:0000:00:36n+2 n+3.9 00:00:00.9 00:00:36.9 n+2.9 n+400:00:0100:00:37n+3 The only problem with this approach is that with this approach under POSIX, time is discontiguous - one cannot cleanly map from POSIX to UTC or TAI. This is some of the fun stuff NTFs General Timestamp API gets to deal with. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-22 11:04, William Unruh wrote: On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote: William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. Consider some labeling of the time. Jun 30 23:59:00 and Jul 1 00:01 let us say. Now when we look at TAI, that second one is one second one is 120 seconds ( as measured by that metric) later than the first. For UTC it is 121 seconds later than the first. As one hunts in toward midnight, say Jun 30 23:59:58 vs Jul 1 00:00:02 say, that interval is still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. UTC is a function which is linear and continuous for all times which are not the leap second, but is discontinous at the leap second. The limit of the function as delta t goes to zero of the two scales is not the same. Limit as delta t goes to zero t_relativity (UTC Jun 30 23:59:59.999... -Delta t) is not equal to Limit as delta t goes to zero t_relativity (UTC Jul 1 00:00:00:.0 +Delta t) while it is for TAI. The fact that UTC gives a name ( 23:59:60) to that extra second does not alter the above fact. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. That one says a function is discontinuous at some value of x and how much it is discontinous, does not alter the fact that it is discontinous. TAI, TT, UTC, UT, UT0, UT1, UT2 are empirical time scales based on measurements not functions, with some scales having fairly simple relations, and UTC stepping by leap seconds. The relative values on these scales are only available accurately when they are published about a month after the time, with estimates available later each day from some labs, based only on those individual labs' standards, which may need corrected later in the month. So none of these simplified arithmetical approaches are anything more than working approximations to the nearest jiffy, and they are not really useful unless you are working in astronomy or physics related fields. POSIX allows you to do useful calculations on civil times based on mean solar seconds, but there are no useful sources for synchronizing or calibrating POSIX time, as all time sources use scales based on SI seconds. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote: William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. David. General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. Consider some labeling of the time. Jun 30 23:59:00 and Jul 1 00:01 let us say. Now when we look at TAI, that second one is one second one is 120 seconds ( as measured by that metric) later than the first. For UTC it is 121 seconds later than the first. As one hunts in toward midnight, say Jun 30 23:59:58 vs Jul 1 00:00:02 say, that interval is still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. UTC is a function which is linear and continuous for all times which are not the leap second, but is discontinous at the leap second. The limit of the function as delta t goes to zero of the two scales is not the same. Limit as delta t goes to zero t_relativity(UTC Jun 30 23:59:59.... -Delta t) is not equal to Limit as delta t goes to zero t_relativity( UTC Jul 1 00:00:00:.0 +Delta t) while it is for TAI. The fact that UTC gives a name ( 23:59:60) to that extra second does not alter the above fact. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. That one says a function is discontinuous at some value of x and how much it is discontinous, does not alter the fact that it is discontinous. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/22/2015 5:45 AM, David Malone wrote: That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. Both TAI and UTC are continuous, and could in a non-standard way, be represented by real numbers (Time, below), where they wouldn't differ. TAI and UTC only differ in how they're labelled, as you say. It's POSIX which isn't monotonic or continuous, it repeats leap seconds. How they handle leap seconds: Time UTC TAI POSIX n+023:59:5800:00:33n+0 n+123:59:5900:00:34n+1 n+223:59:6000:00:35n+2 n+2.9 23:59:60.9 00:00:35.9 n+2.9 n+300:00:0000:00:36n+2 n+3.9 00:00:00.9 00:00:36.9 n+2.9 n+400:00:0100:00:37n+3 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/19/2015 08:42 AM, William Unruh wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: [...] You two *both* need to get your terminology (and its definitions) right. [...] Wow, IMO this is *very* good summary of the problem, and explanation of the reasons for it. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Programmers universally compute the number of days between two dates by determining the seconds of the two dates (by using a function such as getTimeInMillis() for each date), computing the difference in seconds between the two dates, and dividing the difference by 86,400. I proved this to myself by performing the following experiment with three of Java's date classes, GregorianCalendar, Date, and ZonedDateTime. In pseudocode: For year = 1997 to 2015 Date1 = year, month =1, day =1, hour = minute = second =0 Date2 = year+1, month =1, day =1, hour = minute = second =0 Duration = Date2 - Date1 (in seconds) Print Date1, Date2, Duration Date1 = 1997, month =1, day =1, hour = minute = second =0 Date2 = Date1 + 31_536_000 * 18 + 4 * 86_400 //Add 18 yrs (in secs) + 4 days for leap years Print Date1, Date2 For each of Java's date classes, the Duration was equal to 31,536,000 seconds (= 365 * 86,400) for all years except leap years, when the duration was 31,622,400 (=31,536,000 + 86,400) for 366 days. In the second part, Date1 = Jan 1, 1997 and Date2, which was equal to Date1 plus 18 years of 31,536,000 seconds per year + 4 leap days, equaled Jan 1, 2015. But we know that the duration in seconds of 1997, 1998, 2005, 2008, and 2012 was actually 31,536,001 seconds because each of these years had a leap second added. So, why does it work? Java, at least, is pretty upfront about why it works. Java describes ZonedDateTime (and its various cousins Instant, LocalDateTime, and OffsetDateTime) as implementing a proleptic calendar, where in this case proleptic means what the data and time would have been in times past if they had been using our calendar system. In addition, the Java documentation implies that the new date/time classes (ZonedDateTime, Instant, LocalDateTime, and OffsetDateTime) cannot be used for astronomical calculations. Why? Because they won't be correct. Jan 1, 2015 minus 18 years of 31,536,000 seconds per year - 4 leap days * 86,400 seconds will not produce the time a computer would have indicated on Jan 1, 1997; instead, there will be 5 seconds difference for the 5 leap seconds introduced in that interval. Oracle's justification for their approach is: Given the complexity of accurate timekeeping ..., (the) Java API defines its own time-scale, the Java Time-Scale. The Java Time-Scale divides each calendar day into exactly 86400 subdivisions, known as seconds. These seconds may differ from the SI second. It closely matches the de facto international civil time scale, the definition of which changes from time to time. The Java Time-Scale has slightly different definitions for different segments of the time-line, each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new segment of the Java Time-Scale must be defined for it. Each segment must meet these requirements: .the Java Time-Scale shall closely match the underlying international civil time scale; .the Java Time-Scale shall exactly match the international civil time scale at noon each day; .the Java Time-Scale shall have a precisely-defined relationship to the international civil time scale. (Source: Oracle documentation for the java.time.Instant class.) In other words, the only aspect of time that matters to Java is that the clock, in the present, be perfectly accurate each day at noon. Thus the time Java displays and uses will be accurate, and up to spec, if and only if the user's clock is accurate. BTW, proleptic can be defined as: The representation or assumption of a future (past?) act or development as if presently existing or accomplished. (http://www.merriam-webster.com/dictionary/prolepsis, parentheses added) Proleptic calendar, a calendar that is applied to dates before its introduction. (http://en.wikipedia.org/wiki/Proleptic) Hope this helps. Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/20/2015 10:58 AM, Martin Burnicki wrote: Wow, IMO this is *very* good summary of the problem, and explanation of the reasons for it. Thanks, but after pondering the topic another night, I found my treatise to still be faulty. :-} Let me try to amend: --- The smaller point first, I suggested that imagining TAI and UTC in the form of an integer counter would help understanding their properties. That was me going overboard, I'm afraid. You *can* try to imagine timescales that way, but in doing so, you'll reduce almost all of them to an instrument keeping count of the physical time ticking by, differing only by the offset from one to the other. How these timescales treat leap seconds *is* a distinguishing feature, and it is directly related to the bare counter's conversion into a date+time representation. As a corrolary, that means that - contradicting what I wrote before - TAI *does* have a notion of days and years by means of having a date+time representation, and since that one doesn't recognize leap seconds, they're *all* 86400, 31536000 (non-leap year), and 31622400 (leap year) seconds long, regardless of leap seconds. --- Back to mathematics. (You might want to run now. ;-) The problem I have with people calling a timescale monotonous or continuous is that those are mathematical terms, and they're defined for *functions*. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) So, what *function* might people be thinking of when they assert those properties to apply (or not) to timescales? The ultimate basis of timekeeping is that physics gives us a concept of time, in particular, a notion of measuring that time as it passes by, by means of a measurable physical unit, the SI second. With that unit and equipment (and barring relativistic effects for the moment), we can complement a set (of events = measurements) with a metric (that tells us how much time passed between any two measurements). What we have got so far is for time what statements like the pencil is half a meter to the right of the ruler are for space: Precise, but local, in need of being put into relation with a global reference frame to be useful. This reference frame needs to be defined, and *that* are agreed-upon timescales like TAI or UTC. And in order to translate our local measurement into such a timescale, we need a *conversion function*. (Which we may later hide from sight by syncing a clock that *knows* the timescale so that we can read the conversion's result from it directly, but that's irrelevant here.) So, what people mean by saying that a *timescale* is monotonous or continuous is that the function converting the readings of a measurement device (or, as the experts call it, clock) into said timescale has these properties. I don't remember much protest against claims that TAI has those properties (but fails to stay well-synced to celestial bodies). Now what about other timescales? Let's take a step back from leap *seconds* and think about leap *days* for a moment. TAI does take *those* into account, the result being that some years have a length of 365 days and others 366 days. Why isn't it an obstacle to labelling TAI as continuous that some years have a 29th of February intervening between the 28th and the 1st of May, and the others don't, apparently skipping an entire day? The answer is that the blame for this behaviour is on the codomain, not the conversion function. The set of date+time values and the metric on it are *defined* in such a way that the distance between 28-Feb-2015 21:30:00 and 01-Mar-2015 22:30:00 is 25 hours, but the distance between 28-Feb-2016 21:30:00 and 01-Mar-2016 22:30:00 is 49 hours. The conversion function now maps 25 hours of clock ticks onto the first timeframe but 49 hours onto the second - and comes out of the ordeal smelling of roses, continuity, and even linearity. Now let's apply that to the UTC timescale, which, unlike TAI, recognizes leap seconds (and sets them apart). I shall define three different versions of what the codomain for the SI-UTC conversion function arguably *could* be, and obtain three different results what properties the matching version of the function consequently has. And *that*, I posit, is why people have so very different views on what the properties of the UTC timescale are. For the first version, let us assume that the codomain and its metric have leap seconds incorporated in the same way TAI's codomain integrates leap days. In other words, the metric knows that the distance between 31-Mar-2015 23:59:00 and 01-Apr-2015 00:00:00 is 60 seconds but the one between 30-Jun-2015 23:59:00 and 01-Jul-2015 00:00:00 is 61 seconds. The first result would, of course, be that it's now the metric that fails to be fully
Re: [ntp:questions] Leap second to be introduced in June
On 1/20/2015 6:14 PM, Jochen Bern wrote: So, what*function* might people be thinking of when they assert those properties to apply (or not) to timescales? TAI = UTC(x) and UTC = TAI(x). And that's part of the problem. There seems to be the thought that if you do that across a leap second, and use a UTC time series (or timestamps, if that makes it more clear), but use a TAI-like scale, there will be discontinuities on the graph, where points (23:59:60) can't be plotted (or the other way, where points make stepwise jumps). But of course, that's wrong, because both scales increase linearly, and there is no discontinuity in either. Both account for every bit of time - linearly, continuously, and monotonically (UTC+x = time+x, if you will). Time+1 in one simply maps to time+1 in the other. The only change is to what that value is called, not the value itself. The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. (Also, in English, it's monotonic, not monotonous. Monotonous means uninteresting or boring, which this likely is) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Le 21 janv. 2015 à 07:18, Terje Mathisen terje.mathi...@tmsw.no a écrit : Mike S wrote: The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. Right, POSIX is neither UTC nor TAI: It is mostly a calendar device! POSIX is really measuring day numbers, but using a counter which is scaled by 86400. This means that on any day with a leap second, it is not really using SI seconds as the time base. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. Since there is no way to know about leap seconds several years into the future, forward POSIX timestamps must always be considered as absolute references. They should never be used for time intervals, even if that is the (by far) most common use today. :-( And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S wrote: The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. Right, POSIX is neither UTC nor TAI: It is mostly a calendar device! POSIX is really measuring day numbers, but using a counter which is scaled by 86400. This means that on any day with a leap second, it is not really using SI seconds as the time base. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. Since there is no way to know about leap seconds several years into the future, forward POSIX timestamps must always be considered as absolute references. They should never be used for time intervals, even if that is the (by far) most common use today. :-( Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. Now there's a non-sequitur. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. Maybe the confusion arises from considering UTC dates as time interval quantities, which they are not, rather than timescale readings. TAI days have 86400s, UTC days may have 86401 seconds ; so it happens that when TAI reads 00h00:00, UTC reads 23:59:60. That is what makes computing time intervals more complicated in UTC than in TAI but neither TAI nor UTC is defined by the number of seconds elapsed since an epoch. -- François Meyer ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 19/01/15 12:15, Mike S wrote: You clearly misunderstood TF.460, because you still have it wrong. There is no discontinuity, the two scales merely count time differently. This is how the time of the next leap second will be enumerated in each: You are relying on an appendix that deals with representation of dates. The main part of the standard is worded in terms of their being missing seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
[And this is why I wonder why leap seconds are discussed here.] On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote: You clearly misunderstood TF.460 You're using the wrong reference. Try this one from 2007: http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf which provides the CCTF rationale for making discontinuous UTC continuous. You can skip to the last page if you like but you shouldn't. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote: You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. That doesn't make any sense. When the ITU decides *not* do to something it's equally informative as when they decide to do something. Just to be clear you're saying everyone, including the CCTF (previously cited) and the ITU, that says UTC is discontinuous is wrong? For those wonder that internal letter from CCTF to BIPM notes that The UTC system as defined today is a *stepped* atomic time scale [emphasis mine] which is quoting the ITU and can also be found at http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx which discusses why the ITU continues to leave UTC stepped. UTC is a discontinuous time scale composed from segments that are linear transformations of atomic time, the discontinuities being arranged so that UTC approximated UT2 https://en.wikipedia.org/wiki/UT2 until the end of 1971, and UT1 https://en.wikipedia.org/wiki/UT1 thereafter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 8:05 AM, David Woolley wrote: You are relying on an appendix that deals with representation of dates. The main part of the standard is worded in terms of their being missing seconds. How proving that you're unable to provide a quote to back up what is, quite simply, a blatant lie. The word missing appears nowhere in ITU-R TF.460-6. There are no appendices in the standard. Finally, in ITU documents, annexes are normative. 1.8.2.2 annex: An annex to a Recommendation contains material (e.g. technical detail or explanation) which is necessary to its overall completeness and comprehensibility and is therefore considered an integral part of the Recommendation... 1.8.2.3 appendix: An appendix to a Recommendation contains material which is supplementary to and associated with the subject matter of the Recommendation but is not essential to its completeness or comprehensibility... - ITU-T A.1 (10/2008) I've already quoted the relevant part. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 10:22 AM, Paul wrote: On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote: You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. That doesn't make any sense. When the ITU decides *not* do to something it's equally informative as when they decide to do something. Again, you need to up your understanding of standards terminology. For those wonder that internal letter from CCTF to BIPM notes that The UTC system as defined today is a *stepped* atomic time scale [emphasis mine] which is quoting the ITU and can also be found at http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx which discusses why the ITU continues to leave UTC stepped. non-sequitur. They're comparing UTC with TAI. From a TAI perspective, UTC steps backwards. From a UTC perspective, TAI steps forward, going further out of sync with Sol. However, mathematically both are continuous functions. The stepping is a meta-result of the difference in how they enumerate time. UTC is continuous and monotonic. https://en.wikipedia.org/wiki/UT2 FTFY. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 9:04 AM, Paul wrote: [And this is why I wonder why leap seconds are discussed here.] On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote: You clearly misunderstood TF.460 You're using the wrong reference. Huh? You plainly don't understand the relationships or how standards work. UTC is defined by the ITU, of which the BIPM is a member, among others. The ITU then makes the BIPM and IERS responsible for the practical realization of UTC. You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 2:42 AM, William Unruh wrote: I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. You clearly misunderstood TF.460, because you still have it wrong. There is no discontinuity, the two scales merely count time differently. This is how the time of the next leap second will be enumerated in each: UTC TAI 2015/Jun/30/23:59:58 2015/Jul/1/00:00:33 (nb:35 second delta) 2015/Jun/30/23:59:59 2015/Jul/1/00:00:34 2015/Jun/30/23:59:60 2015/Jul/1/00:00:35 2015/Jul/01/00:00:00 2015/Jul/1/00:00:36 2015/Jul/01/00:00:01 2015/Jul/1/00:00:37 (nb:36 second delta) Now, why don't you think a bit, then tell us where you think the discontinuity is in UTC? Hint: if you think there is a discontinuity, keep thinking. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. You are constantly confusing the officially defined UTC time with the implementation in computer operating systems seconds since 1-1-1970 UTC. That implementation neglects the presence of leap seconds. Therefore it has to introduce discontinuity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com wrote: Again, you need to up your understanding of standards terminology. No, if you're going to use jargon you should provide the meanings you're using. Since you clearly have your own version of reality it will help the rest of us. non-sequitur. They're comparing UTC with TAI. From a TAI perspective, UTC steps backwards. From a UTC perspective, TAI steps forward, going further out of sync with Sol. However, mathematically both are continuous functions. I can't believe you actually typed that. I apologize to the list for feeding the troll. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 11:58 AM, Paul wrote: On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com mailto:mi...@flatsurface.com wrote: Again, you need to up your understanding of standards terminology. No, if you're going to use jargon you should provide the meanings you're using. Since you clearly have your own version of reality it will help the rest of us. This is well accepted terminology. If you wish to discuss formal standards, you should be familiar with it. https://en.wikipedia.org/wiki/Normative#Standards_documents I can't believe you actually typed that. I'm sorry to have confused you by bringing up math. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 11:56 AM, William Unruh wrote: On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. Just, Wow. That's completely wrong. TAI does not as far as I know, have a concept of days. It has seconds. If you want to convert those seconds into things like days, months, etc, that is up to you. No, the canonical form of TAI is ydmhms... So, if we count utc seconds we have 1435733999 1435734000 1435734000 1435734001 ... Those appear to be POSIX times. They're certainly neither UTC nor TAI. You keep saying UTC when you're talking about POSIX, which naively tries to keep both epoch (time since...) and wall (UTC) time, and fails miserably since the two are mutually exclusive. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. Maybe the confusion arises from considering UTC dates as time interval quantities, which they are not, rather than timescale readings. TAI days have 86400s, UTC days may have 86401 seconds ; so it happens that when TAI reads 00h00:00, UTC reads 23:59:60. TAI does not as far as I know, have a concept of days. It has seconds. If you want to convert those seconds into things like days, months, etc, that is up to you. So, if we count utc seconds we have 1435733999 1435734000 1435734000 1435734001 ... That is what I mean. That is what makes computing time intervals more complicated in UTC than in TAI but neither TAI nor UTC is defined by the number of seconds elapsed since an epoch. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/19/2015 08:42 AM, William Unruh wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 31536000 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 31536001 SI seconds in that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. You two *both* need to get your terminology (and its definitions) right. First off, there's an actual timescale UTC (which includes leap seconds, and represents them as the famous 23:59:60) and a timescale that current unixoid (and other) computers use internally that is often referred to as UTC (let me call it time_t from here on). A year with a leap second has 31536001 seconds in UTC (and a great many other timescales/-zones, as long as two consecutive turns of the year have the same UTC offset). time_t claims that the year had 31536000 seconds (if you ask it in the first place). The ultimate reason for this (historic) difference is that while the definition of UTC includes leap seconds and even defines a notation for it, it isn't *self-contained* because of leap seconds being decided on and announced only half a year in advance. Since there was (and is) no universal mechanism to distribute leap second tables to computers, time_t was designed as a self-contained approximation to UTC - at the price of it being neither monotonic nor continuous (relative to physical time, and assuming the traditional step one second back approach) over actual leaps. I do not know whether there is an agreed notion of turn of the year for TAI in the first place (as it deliberately does set itself apart from astronomic events and, thus, years), so I can't really answer how many seconds a TAI year has. Definition and representation of TAI *suggest* a year of 31536000 seconds to me, but note that in this case, the turn of the year is expressedly permitted to wander (all over the calendar, if need be) as leap seconds happen and *are included* in the TAI timescale. Now for the *conversion functions*, where terms like continuous regain their usual mathematical meaning in the first place. Converting either TAI or UTC to time_t is, as mentioned above, neither monotonic nor continuous. Converting from time_t back to TAI or UTC is ambiguous and, thus, not even a function. Both statements above are true because time_t numbers the leap second the exact same as one of the neighboring seconds. Converting between TAI and UTC - imagine them as simple counters for the moment, devoid of representational concepts like hours - is monotonic and continuous, because both timescales include the leap second. Actually it's a *linear* function. Converting between *representations* of TAI and UTC, as in, HH:MM:SS, suffers from the fact that UTC special cases the leap seconds (and we *still* need the table of historic leap seconds to do it). Only *now* we get the apparent(*) result that UTC = TAI - n seconds with an n changing (increasing) in discrete steps over time. Note that the above conversion function is, in fact, incomplete because it fails to produce UTC's special value of 23:59:60 for the leap second itself. A more correct definition would be UTC(TAI) = ( TAI - n ) modulo 24h format for times leading up to a specific leap second, 23:59:60 plus the fractional seconds from TAI during the leap second itself, and ( TAI - (n+1) ) modulo 24h format for times following that leap second. As you can see, the suspected one second jump of the conversion between UTC and TAI has been filled with a unique value that is supposedly sorted between the 23:59:59 and 00:00:00 values of UTC. This repairs the alleged failure of the conversion functions to be monotonic and and continuous. Now let's return to the *incomplete* conversion functions and treat them like they were the whole story - which they actually *are* if only we consider time_t instead of UTC: time_t(TAI) = ( TAI - n ) modulo 24h format until some point TAI=t in time ( TAI - (n+1) ) modulo 24h
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18 16:04, William Unruh wrote: UTC always has 86400 seconds per year. ITYM POSIX time always has 86.4ks/day - by that definition POSIX keeps legal civil time using mean solar seconds, not SI seconds or leap seconds. Any correspondence between POSIX time, SI seconds, UTC, or TAI, is an artifact of the implementation. As with implementations of local legal civil times with DST adjustments, there can be discontinuities where times are duplicated or missing. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18, Mike S mi...@flatsurface.com wrote: On 1/14/2015 3:50 AM, Rob wrote: No, it is the inadvertent decision to use UTC as a monotonic clock that causes the trouble. UTC is monotonic. It is POSIX time which has discontinuities when it tries to represent UTC. TAI is monotonic and continuous. UTC thus cannot be. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18, Mike S mi...@flatsurface.com wrote: On 1/13/2015 11:46 PM, William Unruh wrote: That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . UTC jumps neither forward nor backwards. UTC simply allows minutes of 59, 60 or 61 seconds. There is NO discontinuity. The canonical form of UTC (and TAI) is ymdhms. UTC always has 86400 seconds per year. TF.460 describes very clearly how UTC is enumerated. A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en B International atomic time (TAI) The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971). Note: It is in the form of a continuous scale. C Coordinated universal time (UTC) UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds. The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leapseconds) to ensure approximate agreement with UT1. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. The issue you're describing is an issue with POSIX time, which doesn't handle leap seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. Now there's a non-sequitur. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/18/2015 7:15 PM, Mike S wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in that year That clearly should read 86401 seconds in the day of the leap second. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/14/2015 3:50 AM, Rob wrote: No, it is the inadvertent decision to use UTC as a monotonic clock that causes the trouble. UTC is monotonic. It is POSIX time which has discontinuities when it tries to represent UTC. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen wrote: OK, so exactly as encoded in the right zone info, there is no leap second until the table is updated/patched. And yet there is no expiration date in the TZDB's leap second file (which is also used for the right time zones), so you don't know if there is no upcoming leap second, or if the table has just not been updated. AFAIK there's some code in the git version of TZDB, though, so this may be available in future releases of TZDB. The remaining questions is how clients (glibc using a right zone, or PHK's new NTP client software) can determine this is available, and use it. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-16, Chris Adams cmad...@cmadams.net wrote: Once upon a time, Phil W Lee p...@lee-family.me.uk said: For the tiny number of programs which really need UTC (not TAI), it would just be a different number, but the only thing I know of which really needs UTC rather than TAI would be programs to assist with astronomy or astral navigation. I think one problem with OS clocks in TAI is that counting it correctly requires active/on-going maintenance at unknownable intervals for all systems that use any form of timestamps (including for example anything that uses network file systems). Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. If those are supposed to be UTC times then the number of utc seconds has not changed. The number of TAI seconds has ( and if you counted each second as it occured, it will also be diffeent than if a leapsecond had not been inserted). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/16/2015 05:41 AM, Chris Adams wrote: I think one problem with OS clocks in TAI is that counting it correctly requires active/on-going maintenance at unknownable intervals for all systems that use any form of timestamps (including for example anything that uses network file systems). Actually, no, it's the very *reason* to try and use TAI for the baseline that a stable oscillator and a simple counter suffice to do *that* correctly, even (to an extent) all the way through the lifetime of the hardware and its users and in absence of external sync/data sources. The problem arises the moment you want to convert to UTC (or *any* timescale trying to approximate Earth's rotation), and it is conceptually unavoidable because the planet is neither a precise oscillator, nor does it have USB ports to provide our devices with true data directly. (And because the long-term development of the Earth-Moon system leads to Earth's rotation getting gravitationally locked to the Moon like the Moon's already is to Earth, at which point a day on Earth will be as long as what, 40 or 50 of our current days?) While I'm ranting, and because you mentioned the problems of distributing what essentially is the (current) leap seconds table: We all know that the current NTP protocol leans toward UTC, and doesn't address any leap seconds except the one that might be at hand right now. In recent posts to this list, I've read about plans for an NTPng that allows for different timescales, but still suggests that the leap second table be distributed, where necessary, through other, general-purpose protocols like FTP and HTTP. I'm running platforms consisting of hardware that ranges from servers (with a general-purpose OS) to switches to simplistic devices like UPSes or environment sensors. I see the latter's firmware doing SNTP (why would you ever need to configure *two* servers, or a custom interval??) and claiming it's proper NTP in the admin UI. I remember them not having any trace of DST support for Germany until after an EU-coordinated DST came into existence. On the other hand, I see server OSes which *claim* that timezones can be chosen at will and thus should be entirely irrelevant to system administration - but actually *still* have one designated one, e.g., to use in their crontabs. And, of course, I'm the one who would need to convince the CISO that device X needs to talk not just NTP but *HTTP* (oh my God, ever heard of drive-by downloads?!?) to the outside. Read my lips: Unless NTPng *includes* features like delivery of the leap second table and announcement of a preferred timezone (which information one would inject into the platform's outside-facing NTP servers by manual config, of course), so that developers of whatever firmware see that the data's right in the reply packets they already have in RAM, syncing time across entire platforms *WILL* remain a problem because there *ALWAYS WILL* be lots of broken clients getting into the way of a solution. Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. As others already mentioned, that's a problem of wanting to express those timestamps in a timescale (UTC) that is already incompatible to such proper (predictive) representation before a single computer ever came into play. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern writes: ... We all know that the current NTP protocol leans toward UTC, and doesn't address any leap seconds except the one that might be at hand right now. In recent posts to this list, I've read about plans for an NTPng that allows for different timescales, but still suggests that the leap second table be distributed, where necessary, through other, general-purpose protocols like FTP and HTTP. I'm thinking that NTPv5 will use something similar to the GTSAPI timestamps, and each side will be able to select both the timescale it is using (including the version of that timescale) and also the behavioral model by which it disciplines its clock. There will be much to discuss :) -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 15/01/15 07:56, Terje Mathisen wrote: Did we have a leap second last June? Or did you intend to check for 2015? Oops. I did get it right in the dry run, but not in the run I actually used: david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015 86400 seconds' Wed Jul 1 00:00:00 UTC 2015 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Once upon a time, Phil W Lee p...@lee-family.me.uk said: For the tiny number of programs which really need UTC (not TAI), it would just be a different number, but the only thing I know of which really needs UTC rather than TAI would be programs to assist with astronomy or astral navigation. I think one problem with OS clocks in TAI is that counting it correctly requires active/on-going maintenance at unknownable intervals for all systems that use any form of timestamps (including for example anything that uses network file systems). Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. -- Chris Adams cmad...@cmadams.net ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Woolley wrote: On 15/01/15 07:56, Terje Mathisen wrote: Did we have a leap second last June? Or did you intend to check for 2015? Oops. I did get it right in the dry run, but not in the run I actually used: david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015 86400 seconds' Wed Jul 1 00:00:00 UTC 2015 OK, so exactly as encoded in the right zone info, there is no leap second until the table is updated/patched. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
cmad...@cmadams.net (Chris Adams) wrote: Once upon a time, Phil W Lee p...@lee-family.me.uk said: For the tiny number of programs which really need UTC (not TAI), it would just be a different number, but the only thing I know of which really needs UTC rather than TAI would be programs to assist with astronomy or astral navigation. I think one problem with OS clocks in TAI is that counting it correctly requires active/on-going maintenance at unknownable intervals for all systems that use any form of timestamps (including for example anything that uses network file systems). Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. Adn this is _exactly_ why it is always a bad idea to use (UTC) seconds for those future timestamps: If you actually mean that something has to happen N seconds from now, that future timestamp has to be in TAI, since using UTC would obviously blow up across any leap second, right? If you instead meant a calendar event, then you need a different timescale which is either Julian Day Number (JDN) or YMD, followed by either HMS or an offset into the day, followed by the applicable time zone. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen writes: cmad...@cmadams.net (Chris Adams) wrote: Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. The General Timestamp API handles this case, as those timestamps track the version number of the timescale. If you specify noon at (some future date), an absolute timestamp, and between now and then some leap seconds are added, they'll be added here, too. And this is _exactly_ why it is always a bad idea to use (UTC) seconds for those future timestamps: If you actually mean that something has to happen N seconds from now, that future timestamp has to be in TAI, since using UTC would obviously blow up across any leap second, right? If one used a relative/difference timestamp for this, then we're in the same boat and we might need some sort of trigger or signal to indicate that a leap event has happened. We're often in a similar boat though, if the clock steps during the interval this relative/difference timestamp covers. This should arguably be an option for cron jobs and timer events. H -- If you instead meant a calendar event, then you need a different timescale which is either Julian Day Number (JDN) or YMD, followed by either HMS or an offset into the day, followed by the applicable time zone. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Woolley wrote: On 14/01/15 16:37, Terje Mathisen wrote: The calls I'm thinking of are those you make to convert an OS-supplied time_t (file) system timestamp to YMDHMS etc. Those calls have no need to be in the kernel, and they are not in Unix/Linux systems. The standard GetSystemTime* windows calls are also located in usermode libraries afaik. The key issue is that those are documented OS interfaces, not if they entail a user/kernel transition or not. I.e. even Windows (which uses a seconds-based timestamp with 100 ns resolution) has calls exactly like that. Those are the calls that would need to be updated in order to work in (TAI * 1e7). There is no need to update them on Debian Wheezy, and probably most Linux and modern Unix systems. david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86399 seconds' Sat Jun 30 23:59:59 UTC 2012 david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86400 seconds' Sat Jun 30 23:59:60 UTC 2012 david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86401 seconds' Sun Jul 1 00:00:00 UTC 2012 I haven't double checked that this is not a trick in the user interface code, and they don't work for future time, until the leap second has been declared and distributed (in the tzdata files): david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2014 86400 seconds' Tue Jul 1 00:00:00 UTC 2014 Did we have a leap second last June? Or did you intend to check for 2015? The inability to record future civil times in an efficient format is one of the disadvantages of TAI. Exactly right, which is why I stated that they need to be in a different format, like YMDHMS (+zone). Using Julian day number + fractional day measured in seconds+ns would make the required code complexity more or less identical to what we use today for seconds + ns. Re storage needs: time_t has been updated to 64-bit on more or less all *ix variants by now, adding in a ns field (which could go all the way to 19 during a leap second) needs 32 more bits for a total of 96. If we instead split at the day number then we could use 48-bit JDN plus a 48-bit fraction, the end result would be more or less the same range and resolution as the current 64:32 split. The key idea is that we should do all calendar-type calculations based on JDN instead of a make-believe UTC 86400 seconds/day. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 14/01/15 16:37, Terje Mathisen wrote: The calls I'm thinking of are those you make to convert an OS-supplied time_t (file) system timestamp to YMDHMS etc. Those calls have no need to be in the kernel, and they are not in Unix/Linux systems. I.e. even Windows (which uses a seconds-based timestamp with 100 ns resolution) has calls exactly like that. Those are the calls that would need to be updated in order to work in (TAI * 1e7). There is no need to update them on Debian Wheezy, and probably most Linux and modern Unix systems. david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86399 seconds' Sat Jun 30 23:59:59 UTC 2012 david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86400 seconds' Sat Jun 30 23:59:60 UTC 2012 david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2012 86401 seconds' Sun Jul 1 00:00:00 UTC 2012 I haven't double checked that this is not a trick in the user interface code, and they don't work for future time, until the leap second has been declared and distributed (in the tzdata files): david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2014 86400 seconds' Tue Jul 1 00:00:00 UTC 2014 The inability to record future civil times in an efficient format is one of the disadvantages of TAI. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. I've been pondering this some more. Isn't the consequence that, for the purposes of the NTP protocol, Googleish and non-Googleish systems are *fundamentally incompatible* on the day of the leap? As in, when ntpd looks across that divide, there'll be an apparent offset in the tenths-of-seconds range for the better part of a day, which is long enough that ntpd *will* take corrective action (in a default config, a step) on the client side, and thus completely hose the client OSes' attempt at dealing with the leap second according to its native procedure? Shouldn't it be a *requirement* that, however an OS chooses to implement a leap second, it must keep the timeframe in which its local clock is (likely to be) off the true timescale short enough to not confuse timesyncing protocols (with the obvious exception of discrete hard syncs, a.k.a. SNTP)? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen terje.mathi...@tmsw.no wrote: By _far_ the largest majority of all system time calls are asking for the _current_ time, right? Are there (common) systems that have kernel calls for other than the current time? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. I've been pondering this some more. Isn't the consequence that, for the purposes of the NTP protocol, Googleish and non-Googleish systems are *fundamentally incompatible* on the day of the leap? As in, when ntpd looks across that divide, there'll be an apparent offset in the tenths-of-seconds range for the better part of a day, which is long enough that ntpd *will* take corrective action (in a default config, a step) on the client side, and thus completely hose the client OSes' attempt at dealing with the leap second according to its native procedure? Shouldn't it be a *requirement* that, however an OS chooses to implement a leap second, it must keep the timeframe in which its local clock is (likely to be) off the true timescale short enough to not confuse timesyncing protocols (with the obvious exception of discrete hard syncs, a.k.a. SNTP)? What Google did was to localize all the required leap handling code to their internal Stratum 2 servers, and only them: All lower-level servers and clients will never observe any leap event at all, this works because they made sure that the smearing take so long that the maximum frequency offset is well below the 500 ppm ntpd limit. I.e. with a full day of smearing (86400 seconds) and a cosine adjustment curve (making sure that the derivatives are smooth, i.e. no frequency steps!), the maximum frequency offset will be pi / (86400*2) or about 1.82e-5 which is the same as 18.2 ppm. For clients the key is that even with a maximal polling interval (normally 1024 seconds), you don't want this offset to be able to drop out of sync: 18.2 ppm * 1024 seconds * 5 polling periods = 93 ms, i.e. still well within the 128 ms window, but due to the gradual cosine window application of the adjustment, all clients will have started to adjust they frequency well before they got close to this limit. Terje Regards, J. Bern -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. I've been pondering this some more. Isn't the consequence that, for the purposes of the NTP protocol, Googleish and non-Googleish systems are *fundamentally incompatible* on the day of the leap? Oh, absolutely! Nobody should ever be allowed to observe/compare time stamps from google and non-google systems taken at any point during the smear period. Since Google is lying, they must be responsible for making sure that no such timing info ever leaks out. Terje As in, when ntpd looks across that divide, there'll be an apparent offset in the tenths-of-seconds range for the better part of a day, which is long enough that ntpd *will* take corrective action (in a default config, a step) on the client side, and thus completely hose the client OSes' attempt at dealing with the leap second according to its native procedure? Shouldn't it be a *requirement* that, however an OS chooses to implement a leap second, it must keep the timeframe in which its local clock is (likely to be) off the true timescale short enough to not confuse timesyncing protocols (with the obvious exception of discrete hard syncs, a.k.a. SNTP)? Regards, J. Bern -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Paul wrote: On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen terje.mathi...@tmsw.no wrote: By _far_ the largest majority of all system time calls are asking for the _current_ time, right? Are there (common) systems that have kernel calls for other than the current time? The calls I'm thinking of are those you make to convert an OS-supplied time_t (file) system timestamp to YMDHMS etc. I.e. even Windows (which uses a seconds-based timestamp with 100 ns resolution) has calls exactly like that. Those are the calls that would need to be updated in order to work in (TAI * 1e7). Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-14, Erwan David er...@rail.eu.org wrote: Harlan Stenn st...@ntp.org disait le 01/13/15 que : Martin Burnicki writes: Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach because it means that during this 24-hour period the reported time is off by both frequency *and* offset. WHat problem withsaying that one minute is between 58 and 62 seconds long (up to 2 leap seconds can be added or removed), and having timers able to handle 25:59:60 as a valid date ? The problem is NOT the 60 sec display. That is simply a translation from the system time, which is in seconds since. to something readable by humans. The problem is system seconds. System seconds are in UTC seconds, and that is discontinuous. Thus on Jun 30 23:59:59 system seconds reads 1435733999 One second later utc reads 1435734000 .9 seconds later, it reads 1435734000.9 . 0.1 sec later it reads 1435734000.0 Ie there are now two times at which utc seconds read 1435734000, It is discontinuous. HOw does one handle this is the problem. Now Mill's answer is to stop the clock for that second, but if the clock is read during that time, the readings are incremented by some tiny amount. Others is to smear out that time. The other one is to use tai seconds which are not discontinuous but require translation to utc seconds evertime they are used. UTC is still the world standard time. That is does not comply with naive expectations as to how computer time should run is for computer people to worry about :-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . And it is that which is the problem, not the common name Thus one has 1435733999 then a second later 1435734000 then .9 seconds later 1435734000.9 and .1 seconds later 1435734000.0 It is that discontinuity in the utc seconds that causes the trouble. No, it is the inadvertent decision to use UTC as a monotonic clock that causes the trouble. When you look at the translation from UTC to local time there is a similar issue, twice a year at the start and end of DST. However, it does not cause real trouble because the UTC time ticks continuously and only the offset used in the translation changes. Similarly, when the internal computer clock would use TAI and that is then first translated to UTC using a leap second table and then to local time using a timezone/DST table, there would be no issue. Software that needs a mononotonic time would use the raw TAI clock, software that needs UTC would use the TAI-UTC translated clock, and end-user software would use the TAI-UTC-localtime translated clock. It is justifyable that UTC was used, given that there would be much too much overhead in the conversions using the above method at the time this decision was made, and the whole leap seconds thing was quite new then anyway. Also, a computer clock was not as accurate and not as critical a resource back then. But still it was this decision that now causes the problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh wrote:
Now you could have the computer run in TAI and then do the translation
in userland software. But of course since most things expect utc
seconds, every call to the clock would require you figuring out what the
offset from utc to tai is, and subtract that number, making time system calls
much slower.
I used to think this was true, but in reality it isn't:
By _far_ the largest majority of all system time calls are asking for
the _current_ time, right?
This time is already interpolated, using something like the RDTSC
counter to estimate the offset from the last hardware tick when the
baseline clock register/location was updated, so we are talking about
something like 20-50 clock cycles:
Adding one more instruction to this code which simply subtracts the
current offset between TAI and UTC would normally cost a single
additional cycle, if we also add some guard code to detect the case
where we were currently inside a leap second this would add a single
branch which for all practical purposes would be perfectly predicted:
First we get the interpolated clock value in TAI + ns:
clock = os_clock_value; // ( Assume TAI sec plus ns storage)
tdelta = (uint32_t) ((rdtsc - os_clock_tsc) * nanoseconds_per_tsc);
tdelta += clock.nano;
if (tdelta = 10) {
clock.tai++;
tdelta -= 10;
}
clock.nano = tdelta;
converting to UTC is trivial (the OS makes sure that the offset value is
correct):
clock.utc = clock.tai - tai_utc_offset;
then we add code to check for a leap second in progress:
if (clock.tai == current_leap_second) {
// Here we effectively stop the UTC clock, just incrementing
// the ns value once per call
clock.ns = os_clock_ns++;
}
Library calls to convert TAI times in the past to/from YMDHMS will of
course require some more code, and questions about future times _will_
be wrong, so you have to store future timestamps in the format which is
most applicable. I.e. a future meeting assignment should be stored in
YMDHMS-ZONE format, while a time at a given numer of seconds from now
needs to be stored in TAI.
I suspect that you can write pretty fast code to handle the TAI-UTC
conversions without needing any huge tables, just the list of leap
seconds up to now:
Trivial code would simply scan the table, possibly from the current end
since recent timestamps are more common than old, or you could use some
form of table lookup, i.e. make a table that contains the delta count
for each possible insertion point:
Take the UTC value, subtract 1972-04-01 then divide by the average
number of seconds in half a year: This gives a small integer, currently
in the 0 to 85 range, which is used to lookup a byte indexing the
closest relevant leap second.
Comparing against this value controls which tai-utc offset count to use.
Anyway, it looks doable in 20+ clock cycles if it is a heavily used
function (otherwise the timing doesn't matter) so that the lookup tables
are cached.
Terje
--
- Terje.Mathisen at tmsw.no
almost all programming can be viewed as an exercise in caching
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-14, Phil W Lee p...@lee-family.me.uk wrote: brian utterback brian.utterb...@oracle.com considered Mon, 12 Jan 2015 04:29:21 GMT the perfect time to write: On 1/11/2015 4:56 PM, Rob wrote: Michael Moroney moro...@world.std.spaamtrap.com wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? That depends on what kind of system it is. Carefully designed systems will do the right thing. Define the right thing. To eloaborate, there is no right thing. There are a whole bunch of things that are right for some people and not for others. That is the very reason that there isn't a right thing, because if there was one right thing all the vendors would have fixed their operating systems to do it. As I understood it, there is a right thing (have a second spanning 23:59:60 to 00:00:00) but almost no software (or even the time libraries used in any of the common languages) groks it, so different systems use different fudges to work around it. That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . And it is that which is the problem, not the common name Thus one has 1435733999 then a second later 1435734000 then .9 seconds later 1435734000.9 and .1 seconds later 1435734000.0 It is that discontinuity in the utc seconds that causes the trouble. Mill's solution is to simply stop the clock during that extra second, so, 1.9 sec after 1435733999 it will be 1435734000.01 and .1 sec later it will be 1435734000.02. Whatever you do you have to loose that second. (Ie he stops time except every time the clock is queried it makes sure that it is later than the time before by a minimal amount. ) HOw you display it in normal language is of course up to you. Now you could have the computer run in TAI and then do the translation in userland software. But of course since most things expect utc seconds, every call to the clock would require you figuring out what the offset from utc to tai is, and subtract that number, making time system calls much slower. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn st...@ntp.org disait le 01/13/15 que : Martin Burnicki writes: Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach because it means that during this 24-hour period the reported time is off by both frequency *and* offset. WHat problem withsaying that one minute is between 58 and 62 seconds long (up to 2 leap seconds can be added or removed), and having timers able to handle 25:59:60 as a valid date ? -- Les simplifications c'est trop compliqué ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Erwan David writes: Harlan Stenn st...@ntp.org disait le 01/13/15 que : Martin Burnicki writes: Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach because it means that during this 24-hour period the reported time is off by both frequency *and* offset. WHat problem withsaying that one minute is between 58 and 62 seconds long (up to 2 leap seconds can be added or removed), and having timers able to handle 25:59:60 as a valid date ? Where have you seen that 2 leap seconds can be added or removed? I've only ever seen 1. And if you have support for a timescale that handles 23:59:60 as a valid time on a day with a leapsecond, that's just fine. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no properly implements, or right thing. Perhaps you're unaware that POSIX isn't the One True Operating System specification. Properly implements means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. Agreed. It is often overlooked that leap seconds were implemented from 1972 and POSIX only saw the light of day in 1988. So POSIX is just plain wrong here IMHO. Of course I am aware that POSIX isn't the one true operating system specification. But it certainly is a specification. And for a very large number of people in the world, POSIX conformity is more important than the UTC specification. I agree that POSIX was wrong, but it is what it is. What is the right thing to do if you have two conflicting standards? I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. It means that any sort of timing done during this time period will be off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so. Even for benchmarking runs an error of this magnitude will be down in the noise, the remaining problems are for stuff like telescope control. For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
[Context is google-smear.] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. How often do people working with log files from 2 systems care about fractions of a second? -- These are my opinions. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Hal Murray writes: [Context is google-smear.] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. How often do people working with log files from 2 systems care about fractions of a second? The General Timestamp API timestamps include a timescale, and this includes a way to put a timestamp into a canonical form. That meeans that one can do arithmetic, compare, and convert timestamps that use arbitrary timescales. This would include timestamps using the Google leap smear, TAI, or UTC (at least). H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn wrote: Marco Marongiu writes: On 12/01/15 06:10, William Unruh wrote: I also admit I do not know how windows impliments leap seconds. I don't have a reference, but I remember that at the time of the latest leap second I read that Windows will half the clock speed at 23:59:59 so that it reaches 00:00:00 at the right time. It pays the price of being wrong for two seconds in order to save the system from a discontinuity. But again, I read it in 2012 somewhere I don't have a reference of, and things may have changed since then. The last I saw the unix kernel implements the leap second over 1 second of time, and the Windows kernel does this over 2 seconds' time. I recall seeing some whitepapers about this but I won't be able to look for a while... A whitepaper and presentation of my observations until 2013 can be found here: http://www.meinbergglobal.com/english/info/#whitepaper See Technical Aspects of Leap Second Propagation and Evaluation Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen wrote: Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no properly implements, or right thing. Perhaps you're unaware that POSIX isn't the One True Operating System specification. Properly implements means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. Agreed. It is often overlooked that leap seconds were implemented from 1972 and POSIX only saw the light of day in 1988. So POSIX is just plain wrong here IMHO. Of course I am aware that POSIX isn't the one true operating system specification. But it certainly is a specification. And for a very large number of people in the world, POSIX conformity is more important than the UTC specification. I agree that POSIX was wrong, but it is what it is. What is the right thing to do if you have two conflicting standards? I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. It means that any sort of timing done during this time period will be off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so. Even for benchmarking runs an error of this magnitude will be down in the noise, the remaining problems are for stuff like telescope control. For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. Agreed, and it would be good to know the smear interval, so that different systems can smear in the same way. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 13/01/2015 08:58, Hal Murray wrote: [] How often do people working with log files from 2 systems care about fractions of a second? I am comparing log files with a user in another country, where we are looking at errors in satellite data. As there can be many messages per second, using NTP which gets Windows systems down to the 20 ms level or better allows much easier correlation of events. The use of different smearing methods across a leap second would introduce undesirable uncertainties in correlation the events (as used to happen before the second station added NTP). Just one example. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Marco Marongiu wrote: On 12/01/15 11:48, Martin Burnicki wrote: Fortunately Dave Hart had some time to have a closer look at this, and fix it for 4.2.6, so unless something has been broken again in the mean time it should be fixed in 4.2.6 and later, and should work correctly. Let me understand: you mean that in 4.2.6 ntpd will slew down the clock by two seconds on systems where you can't notify the kernel? No. This is *only* in the Windows-specific code of ntpd. Summary: 1.) If the OS kernel supports it then ntpd just passes the leap second warning down to the kernel, and the kernel handles it depending on how it has been implemented in the OS type and version. 2.) If the OS kernel doesn't support this then ... 2a.) non-Windows versions 4.2.6 and newer step the OS time back by 1 second at the leap second event time (don't know from top of my head if at the beginning or end of the leap second, would have to check the source code). Ntpd versions prior to 4.2.6 would simply do nothing to handle the leap second. They would just observe a sudden 1 second offset after the leap second, and step the time as usual after some minutes. 2b.) Windows versions after our xmas edition from December 2005 slew the Windows system time over 2 seconds to account for the leap second. Specifically, this is in the official stable NTP code since NTP v4.2.4. If so, does it also mean that it would do the same when you disable the kernel discipline by adding a disable kernel in ntp.conf? If I remember correctly then this code depends on a preprocessor symbol, which means it's compiled with or without support for the kernel API. Not sure what happens if it's compiled for kernel PLL but kernel PLL is disabled at runtime. I'll try to figure this out, though. I'm planning to do some testing soon to verify this. If you shared the results of your testing when you're done, that would be great ;-) Yes, of course. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Taylor writes: On 13/01/2015 08:58, Hal Murray wrote: [] How often do people working with log files from 2 systems care about fractions of a second? I have spoken with enterprise users who have to correlate logging timestamps between 50-200 (or more) systems in cloud deployments and have a *horrible* time with that under current schemes. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Martin Burnicki writes: Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach because it means that during this 24-hour period the reported time is off by both frequency *and* offset. It means that any sort of timing done during this time period will be off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so. GTSAPI timestamps will properly account for this. Even for benchmarking runs an error of this magnitude will be down in the noise, the remaining problems are for stuff like telescope control. For most folks I agree with you. There will be cases where it's not true and I'd expect to see an increasing number of these cases moving forward. For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( GTSAPI timestamps will, I believe and expect, solve this issue. I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. Agreed, and it would be good to know the smear interval, so that different systems can smear in the same way. That's really an NTPv5 problem, as we've expected everybody to play by the same rules as far as NTP goes, and there are a number of ways this is not true, and I expect the number of cases to increase. NTP needs to know the rules its peers/servers are playing by to avoid instability: - leap smear - TAI or UTC? - expected offset to correct time not yet applied - correction algorithm and specs -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Harlan Stenn writes: David Taylor writes: On 13/01/2015 08:58, Hal Murray wrote: [] How often do people working with log files from 2 systems care about fractions of a second? I have spoken with enterprise users who have to correlate logging timestamps between 50-200 (or more) systems in cloud deployments and have a *horrible* time with that under current schemes. Here's a better example: https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 12/01/15 06:10, William Unruh wrote: I also admit I do not know how windows impliments leap seconds. I don't have a reference, but I remember that at the time of the latest leap second I read that Windows will half the clock speed at 23:59:59 so that it reaches 00:00:00 at the right time. It pays the price of being wrong for two seconds in order to save the system from a discontinuity. But again, I read it in 2012 somewhere I don't have a reference of, and things may have changed since then. Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/11/2015 11:32 PM, brian utterback wrote: On 1/11/2015 9:44 PM, Mike S wrote: On 1/11/2015 7:16 PM, William Unruh wrote: If that public source is responsible it will pass on to your system the fact that there is a leapsecond, and your system will stop for a second at the last second of June. A system which properly implements leap seconds will do no such thing. It will properly account for a minute with 61 seconds, and will tick from 23:59:59 to 23:59:60 then to 00:00:00. There is no stopping, or any other discontinuity. Not true. That would violate POSIX. There is no properly implements, or right thing. Perhaps you're unaware that POSIX isn't the One True Operating System specification. Properly implements means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
