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.

Reply via email to