Re: [AVTCORE] Leap seconds

[Marshall Eubanks <[e-mail]>]

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.

Regards
Marshall


> Ron Frederick
> [e-mail]<mailto:[e-mail]>
>
>