[LEAPSECS] Local insertion of leap seconds

[Magnus Danielson]

Stephen,

Nice seeing you here!

On 03/01/14 21:45, Stephen Scott wrote:

> Subject: Local insertion of leap seconds

>

> I am new to this group so please excuse if this subject has been

> previously covered.

>

> As I understand the standard ITU-R TF.460-6 the leap second correction

> is instantiated globally as the last second of a UTCZ month.

>

> However I have not been able to determine any practices for

> instantiating the leap second correction at other times to avoid such an

> interruption in the timescale at an inopportune time of day in different

> locations around the world.

>

> In countries west of Greenwich the insertion happens before midnight

> making possible to delay the correction to a later and more appropriate

> time. However in countries east of Greenwich the correction could need

> to have sufficient advance notice.

>

> Can you enlighten my understanding of what practices may exist?

>

> Background for these concerns is compounded by a number of factors.

>

> 1.)Television broadcast automation requires precise timing to avoid

> programs and in particular commercials from being clipped or having gaps.

>

> 2.)Video in North America and some other parts of the world is generated

> on a timescale that is at a frequency of 30/1.001 Hz. This deviation

> from a SI second timescale means that a leap second insertion is

> equivalent to inserting 29.97002997… video frames.

>

> 3.)This rate implies in a non-integer number of video frames in a 24

> hour day and thus a varying phase alignment to a 24 hour clock.


TF.460 specifies exactly when it is inserted into the UTC time-scale, 
and this means you can figure out when it occurs in the TAI time-scale, 
if you need to. If you cook up another time-scale, TF.460 have no chance 
of providing guidance, as you define this new time-scale one will have 
to establish the rules for that time-scale.

The ST 2059-1/2 work establish a new time-scale, local to each station, 
and I have chosen to call this production time in order to assist in 
separating it from both UTC and local time.

If you look at the text I wrote on time-scales, you will see that I made 
sure that I clearly separate UTC, localtime (UTC shifted with time-zone) 
and production-time. The drop-frame frequency error requires re-occurent 
jamming (phase-jumps) to keep production-time fairly in line with 
UTC/local-time, DST-shifts and leap-second insertions also requires 
jamming, as the production time needs to meet the requirement that 
during live transmission, it needs to be "un-jammed", but it can be 
jammed at off-hour, and you will also see that I gave examples to hint 
how jamming should be used to resolve this. Depending on when 
transmissions occurs from a station, the station's locality tends to 
steer when a good time for jamming occurs, and thus can no single common 
jam-time be established.

The production-time requirements forces the TV-production to operate 
it's own time-scale. The unfortunate math of 30/1.001 and non-precise 
drop-frame compensation forces jamming. Personally I would have fixed 
the drop-frame algorithm and used additional bits, in which case it 
would have become precise, but it seems like there was no support for it.

For Europe, running at 25 frames per second, no jamming is needed except 
for leap-seconds and DST-changes.

It seems like my 1-pager explained the issues so that the intentions 
behind the jamming-mechanism is fairly well explained. If needed, I'm 
happy to amend it accordingly, just let me know what issues there is.

Cheers,
Magnus