Re: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
On 2015-03-04 07:28 AM, Steffen Nurpmeso wrote: Tom Van Baak t...@leapsecond.com wrote: |http://gpsworld.com/beidou-numbering-presents-leap-second-issue/ Ok, but if engineers don't even get enough time from the business people to read manuals before they code the software then all bets are off. From a coders point of view 0-6 seems to be more logical than 1-7. (I personally, e.g., get more complex awk(1) coding almost always wrong in the first place because of base 1 not 0.) Me too. I remember reading somewhere that Off-by-one errors are by far the most prevalent type of bug, no matter the language. There are lots of variations of it : Off-by-one error http://en.wikipedia.org/wiki/Off-by-one_error One not mentioned, and I see as closely related, is getting the *sign* inverted. I've found that particularly easy to do in timekeeping code, for example, applying the Leap Seconds or the initial 10s Leap Second offset in the wrong direction at some point in the code. Everything can look just fine until you finally compare it to some known reference to discover you are off by 10 or the number of Leap Seconds, or something. Programmers like zero-based because its more mathematically consistent, but people generally don't like to label the first thing zero. This inconsistency is all over the place in society, and been a point of contention in calendars and timekeeping for centuries. Programmers have to be careful, duh. And timekeeping systems present a particularly difficult testing challenge. Its doable, but you've got to roll up your sleeves and do it. Those business people that might allocate resources for the effort would hopefully recognize its not as easy as looks. Meantime, the manual is not easy to read, what with the specifications scattered all over the place. Its really not rocket science when you get to the bottom of it but it takes a long time to understand it. -Brooks --steffen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] a Japanese leap smear?
It looks like Kyushu Telecommunication network is considering its own version of the leap smear http://www.slideshare.net/apnic/the-leap-second-is-coming-by-tomonori-takada-apricot-2015 -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
On Wed 2015-03-04T07:42:46 +, michael.deckers via LEAPSECS hath writ: On 2015-03-04 02:23, Steve Allen wrote on the Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967) A.R. Robins had been talking with Sadler and Smith and with that information in hand he wrote that atomic time was identical to UT2 at 1958-01-01 T 20:00:00 Z Well, there is not only personal recollections: RECOMMENDATION S 4 (1970) of the 5th Session of the Consultative Committee for the Definition of the Second: 4. The origin of International Atomic Time is defined in conformance with the recommendations of the International Astronomical Union (13th General Assembly, Prague, 1967) that is, this scale was in approximate agreement with 0 hours UT2 January 1, 1958. A resolution does not change what had been done by the folks running the broadcasts over a decade earlier, nor does it repair the deficiencies in what they had done over that entire interval. A.R. Robins talked with H.M. Smith. Smith had been there making the UK time broadcasts happen. If Smith said that the UK versions of the atomic time scale and the UT2 time scale were aligned at 1958-01-01T20 then that is likely the way the calculations to do that alignment were performed, and likely based on the hour of the day that the ionospheric conditions were most conducive to allowing the best comparison with other transmitters. It is instructive to read BIH Bulletin Horaire for the actual history;, to see the ways that the radio broadcasters attempted, succeeded, and failed at their mandate of maintaining continuously operating transmitters based on continuously operating chronometers; to see the issues with Anna Stoyko's initial, painstaking efforts to reconstruct the history of received radio time signals into the first atomic time scale; to see the number of times that the broadcasters changed their strategies and the number of times that the BIH changed their algorithms and recomputed what past issues should have said the time was. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On 2015-03-04 02:12 AM, michael.deckers via LEAPSECS wrote: On 2015-03-03 21:05, Martin Burnicki wrote about negative leap seconds: In the 7 year interval where no leap second was required/scheduled I heard several people saying we might have needed a negative leap second. Fortunately, this is not a matter of speculation. An easy way to see the trend of UT1 - UTC is to look at DUT1 (published in Bulletin D). DUT1 is an approximation to UT1 - UTC and has always stepped down (except, of course, at positive leap seconds), ever since the earliest Bulletin D available on the web (1991-06-20). Before a negative leap seconds would be scheduled, we would see DUT1 stepping up several times in a row, so there _is_ some advance warning. We can't predict the future. It's fascinating to read about the many factors affecting Earth's rotation. It seems the largest one is the one we know least about - the Earth's core. I wonder what DUT1 would have looked like around the time of the Chicxulub impactor. Negative Leap Seconds have been a feature of the specification since the beginning. It gives a little more margin to accommodate the unknown, and it's not an onerous complication. I hope we concentrate on helping get implementations to conform to the UTC specs as they stand rather than look for justifications to over simplify the problem. -Brooks Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
Tom Van Baak t...@leapsecond.com wrote: |http://gpsworld.com/beidou-numbering-presents-leap-second-issue/ Ok, but if engineers don't even get enough time from the business people to read manuals before they code the software then all bets are off. From a coders point of view 0-6 seems to be more logical than 1-7. (I personally, e.g., get more complex awk(1) coding almost always wrong in the first place because of base 1 not 0.) --steffen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote: Joseph Gwinn wrote: On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote: Hi folks, I've been asked off list to make the slides of my presentation at FOSDEM 2015 in Brussels available and post the download link on this list. So here it is: https://fosdem.org/2015/schedule/event/technical_aspects_of_leap_second_propagation_and_evaluation/ See the Attachment link. Very interesting; thanks for posting this. I have a few questions and comments: 1. Slide titled Known Bugs (2): Has support for negative leap seconds been restored in NTP v4? It wasn't clear. I have to admit that I wrote this before 4.2.8 had been released. Support for negative leap second has been in older NTP versions, but had been removed in 4.2.6. Now in 4.2.8 the leap second code has been reworked and cleaned up, and a very quick look at the source code seems to indicate that this might work again. At least there's code which passes the announcement flag to the kernel, if kernel support is enabled. I think I'll give it a try soon. I'd expect that a negative leap second might work if an appropriate announcement is received from a refclock or upstream NTP server, but it will be interesting to find out if this works with a NIST-style leap second file where the TAI offset decreases at a given date. Hell - lots of code can't handle a positive leap second, so what hope is there? 2. Slide titled Possibilities for Future Improvements (2): In the wish list for a kernel call to ask if the kernel runs UTC or TAI, a couple of issues come to mind. First, many systems set the GPS receiver to emit GPS System Time via NTP (and IRIG), so a GPS System Time option may be needed. Yes. Though I would prefer using TAI instead of raw GPS time if a linear time scale is required. What if you use a different GNSS receiver, e.g. for Galileo, or the Chinese Beidou? GPS time (or whatever) is fine in closed projects/environments, but IMO a UTC and TAI are the global time scales, while GPS is specific to the U.S. While TAI would be ideal for the reasons given, the problem is that TAI is not yet widely supported enough. Second, we often have the GPS (or PTP 1588) receiver to emit GPS System Time, but never share this with downstream servers, who are configured for UTC (but strangely the leap seconds never come). The difference between UTC and GPS System Time is handled in applications code. The reason for this approach is so that the bulk of the system is free from step discontinuities, and only the interfaces need deal with UTC. I agree, but as I've tried to point out above I think a better project design would have been to use TAI instead of GPS time. PTP works natively with TAI, and you can easily convert between he two scales. Of course it's easy to convert GPS to TAI, and vice versa, but you have to take care that more types of conversions are required and implemented correctly. Right now, GPS System Time is the best solution. In ten years, I bet the answer will be TAI. Thanks for your feedback! Quite welcome. Joe Gwinn Martin -- Martin Burnicki MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309-14 Fax: +49 (0)5281 9309-30 Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Web: http://www.meinberg.de ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On Wed 2015-03-04T08:54:00 -0500, Joseph Gwinn hath writ: On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote: I think I'll give it a try soon. I'd expect that a negative leap second might work if an appropriate announcement is received from a refclock or upstream NTP server, but it will be interesting to find out if this works with a NIST-style leap second file where the TAI offset decreases at a given date. Hell - lots of code can't handle a positive leap second, so what hope is there? There's a lot of hope for negative leap seconds to be inconsequential to a lot of code. An overloaded operating system which is timesharing may suspend a process for a long time, so when that process wakes up it may find that it has missed a second. A virtual machine running on a cloud server farm in Oregon may be saved to disk, shipped across the continent to North Carolina, and restarted over a second later -- or kept on disk and replicated and restarted even later, multiple times. What happens with a negative leap second is a lot like what happens to non-real-time processes and machines as a routine part of operation. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
