I've not been able to follow these discussions. I look forward to the time when there's less pressure on my schedule.
Has anybody put forth the following position: - The various current popular timescales are of significant value. - (a variety of points covering the "backstory", "foundation", and pros/cons of these timescales.) - If something doesn't happen "often enough" it's difficult for people who have to deal with these events to easily accomodate them. As a case in point, I offer full/proper handling of leap years in calendars. I submit this situation was not properly handled until 1) the internet made it easy to copy/paste code, and 2) Y2K got everybody looking at their date code. - So I propose that every N months' time, where N is 1-6, we schedule either an addition or a deletion of a leap second. In doing so, we make it "compelling" for leap seconds to be properly handled, and I submit that the "problem" of handling leap seconds will be resolved satisfactorily within 1-2 years' time. Are there significant additional costs to implementing this approach when compared to the costs of continuing to only address leap seconds as needed? I'm hesitant to have asked that, as it's akin to asking what the costs are to changing UTC so it doesn't have leap seconds. This is all about "how to lie with statistics", except that the scope is much smaller. I'll point out that a side issue is that there are HUGE number of ancient versions of NTP out there and too many folks are being slow to update. Dealing with leap second additions and deletions will be yet another incentive to upgrade this software. -- Harlan Stenn <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
