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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
