Re: [AVTCORE] Leap seconds

["Frederick, Ron" <[e-mail]>]

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.
--
Ron Frederick
[e-mail]<mailto:[e-mail]>