Re: [AVTCORE] Leap seconds

So far, there has not needed to be a negative leap second. I have  thought
for some time that if the outer core favored us with a negative leap second,
leap seconds would be abandoned. However...

On Wed, Sep 14, 2011 at 1:48 PM, Allison, Art <AAllison@nab.org> wrote:

> As I understand it the UTC clock will monotonically increase after  January
> 2017 (no more leap seconds).
>

With either positive or negative leap seconds, a proper UTC clock will
only monotonically increase now, just as the calendar only monotonically
increases even given leap days.

> What happens at 03:14:07 UTC<http://en.wikipedia.org/wiki/Coordinated_Universal_Time>on Tuesday, 19 January 2038 (32
> bit count overflow) will need to be addressed by someone, - your guess if
> any equipment being built today will be in service then. ****
>
> See
> http://www.agi.com/downloads/resources/white-papers/Debate-Over-UTC-and-Leap-Seconds.pdf
> for more information.****
>
> **
>

That is a pending recommendation. It has not been approved. It comes up for
approval at RA-12 *Geneva, in Switzerland, 16 January-20 January 2012.*
*
*
*Regards*
*Marshall*

> **
>
> ** **
>
> *Art Allison*
> Senior Director Advanced Engineering, Science and Technology
> National Association of Broadcasters
> 1771 N Street NW
> Washington, DC 20036
> Phone  202 429 5418
> Fax  202 775 4981
> *www.nab.org*
> *Advocacy  Education  Innovation* ****
>
> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf Of *Kevin
> Gross
> *Sent:* Wednesday, September 14, 2011 1:22 PM
> *To:* avt@ietf.org
> *Subject:* [AVTCORE] Leap seconds****
>
> ** **
>
> I am working on a means of using an IEEE 1588 timebase for RTP streaming. I
> am aware of IEEE 1733 and will use that if necessary. First I am exploring
> using existing NTP mapping function in RTCP sender reports. While
> researching how to translate a 1588 timestamp to its NTP equivalent, I was
> reminded of the wrinkle leap seconds put into things.****
>
> ** **
>
> The RTCP sender report maps RTP timestamps to NTP timestamps. RTP
> timestamps are monotonically increasing. The RTP timestamps are based on UTC
> and have an occasional wobble due to leap seconds. During the leap second,
> there is an ambiguous mapping between RTP and NTP/UTC. I find no
> recommendations in RFC 3550 for dealing with this.****
>
> ** **
>
> -- ****
>
> Kevin Gross****
>
> AVA Networks****
>
> +1-303-447-0517****
>
> ** **
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>