I would support a leap minute. It will still be far enough in the future that I will not have to deal with it :)
But then we would lose that wonderful subject of conversation and we would lose the practice of doing it somewhat regularly. I can see that the lack of practice could easily make it into a bigger problem. Didier KO4BB Wojciech Owczarek <wojci...@owczarek.co.uk> wrote: >Magnus, > >I have little experience with radio-based public time dissemination >services, but some with GPS/NTP/PTP, so here's some info - hope it's of >some value to you. > >For US and European exchanges, the leap second time happens outside >trading >hours, so maybe that's why we've heard little (horror) stories. This is >definitely not an easy thing to deal with during trading, unless your >messaging protocol actually has specific leap second extensions - which >I'm >not aware of any of the ones I know having. > >This is how the Linux kernel running UTC does it (assuming it's been >told >by NTP/PTP/GPS/user and the respective leap second kernel flag was set >- >and for example, a broken IRIG-B box somewhere hadn't forgotten to tell >some of your NTP servers about this and your quorum blocked it): > >- If we're removing a second, Linux system clock will change from >23:59:58.999999999 straight to 00:00:00.000000000 >- If we're inserting a second, Linux system clock will run the last >second >second twice: 23:59:59.999999999 will change again to >23:59:59.000000000 > >(that's the kernel internal / UTC time, time formatting functions will >output the :60 value at insertion time). > >This approach can potentially be problematic for some applications, >especially the insertion, which is essentially a step backwards, so >some >institutions / vendors propose an alternative approach, which is the >leap >second smear - I think Google was advocating that one: this is where >you >gradually add/take the extra time throughout the whole leap second day >(which would be an approx. 11.6 ppm offset if you started from midnight >- >so you'd have to model this carefully to bring it back to normal soon >after >the leap second midnight). > >Those alternative methods of time insertion may be fine if they're used >only internally within an organisation that doesn't provide timestamped >data to other organisations, without also providing time services to >them - >or basically, all is well as long as interconnected parties use the >same >method of dealing with this. > >*personal opinion* > >While the leap second is a somewhat inconvenient phenomenon, while it's >still there, it's there and we have to deal with it. I think that most >of >the problems around it that people talk about are a little bit of FUD >resulting purely from the lack of adequate testing. This is based on my >experience with computer/network kit - this wasn't meant to be an >absolute >statement. > >I'd say let the IERS keep computing it but let's drop it from UTC and >let's >do a one-off leap hour in some 4,000 years :-) > >Regards >Wojciech >_______________________________________________ >time-nuts mailing list -- time-nuts@febo.com >To unsubscribe, go to >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. -- Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
