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.
