Re: [AVTCORE] Leap seconds

[David Singer <[e-mail]>]

On Sep 21, 2011, at 13:56 , Marshall Eubanks wrote:

> 
> 
> On Wed, Sep 21, 2011 at 4:07 PM, Frederick, Ron <[e-mail]> wrote:
> On Sep 21, 2011, at 10:13 AM, Marshall Eubanks wrote:
> On Tue, Sep 20, 2011 at 7:17 PM, Kevin Gross <[e-mail]<mailto:[e-mail]>> wrote:
> Well, that would fix things. By my reading, RFC 3550 is not clear on this however. I'm not sure trying to figure out the original intent of the RFC will help us resolve things because nowhere in the text do I see any indications that the RFC authors gave consideration to the NTP leap second issue.
> 
> The RFC does say "Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900." (emphasis on timestamp format mine) Since it doesn't say anything about leap seconds, you could interpret it as Dave Singer and Colin Perkins have to mean actual seconds elapsed.
> 
> But a couple sentences later there's, "Running NTP may be useful for synchronizing streams transmitted from separate hosts." Again, no mention of leap-seconds but here, since we're talking about actual NTP (as opposed to "NTP timestamp format"), wouldn't you be inclined to assume that leap seconds are included in timestamps in this suggested implementation?
> 
> I have already determined that TAI time is best for my application. If anyone knows of any existing signaling mechanism I can use to communicate this to receivers (e.g. specific SDP a= records), I would welcome suggestions.
> 
> 
> Yes, I don't know why leap seconds aren't treated as are the time zones and DST (i.e., instead of keeping UTC and displaying UTC + Z, you would keep TAI and display TAI + L  + Z). I urged that many years ago, but got absolutely no traction.
> 
> It sounds like what we would really want is to have RTP's timestamp is in NTP format with a timebase of 1 January 1900 0h TAI instead of UTC (which are actually the same time, since that date predates any added leap seconds). The challenge I see, though, is that operating system functions which applications are likely to use to get wallclock time are likely to return UTC, not TAI, and short of hardcoding a schedule of leap-seconds in the applications it will be difficult to convert back. Even then, if the system really does "freeze" the time it returns for a second during a leap second, there's no way to recover the correct TAI time and strange results will be seen when an SR is generated during that second.
> --
> 
> The 800 kg elephant in the room is of course the suspicion that different implementations do different things during that second.
> 
> I know back when I was doing VLBI ops the policy was, "don't schedule  an observation over a leap second."  Media doesn't always 
> have that luxury.

Yes, I agree.

I think the easy fix is to clarify in RTP that the time in RTP sender reports always increments by one second for every second that elapses, such that subtracting any pair of these gives a true count of the number of seconds in between the two events.  This is consistent with the permission that one can use any clock as the source of these timestamps; NTP sync is not required.

Then a footnote to the effect that care should be taken with leap seconds if either these timestamps are derived from a 'civil time' clock that provides a timestamp in calendar format, or if the timestamps are converted to calendar format, e.g. for display purposes.


David Singer
Multimedia and Software Standards, Apple Inc.