Re: [AVTCORE] Leap seconds

[Marshall Eubanks <[e-mail]>]

On Tue, Sep 20, 2011 at 7:17 PM, Kevin Gross <[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.

Regards
Marshall



> Kevin Gross
>
>
> On Tue, Sep 20, 2011 at 4:21 PM, Colin Perkins <[e-mail]> wrote:
>
>> I guess I'm confused. RTP was intended to use NTP *format* timestamps, but
>> intentionally said nothing about synchronisation to any particular time
>> source. I don't think it's valid to assume that the NTP format timestamps
>> conveyed in RTP are synchronised to UTC, TAI, or anything else, *unless you
>> have some explicit signalling to state that*.
>>
>> Colin
>>
>>