[LEAPSECS] Celebrating the new year a few seconds late

[Brooks Harris]

On 2019-01-04 9:14 AM, Jonathan E. Hardis wrote:
>
>
>> On Jan 1, 2019, at 1:03 PM, Brooks Harris <brooks at edlmax.com 
>> <mailto:brooks at edlmax.com>> wrote:
>>
>> Back in the days of analog TV (which is still used in some parts of 
>> the world) the broadcast TV signal was one of the most stable time 
>> sources around. This was necessary because the display of the signal 
>> on a CRT TV set depended critically on the timing of the components 
>> of the signal, the horizontal and vertical scan lines of each frame 
>> (actually two interlaced 'fields').
>>
>> There were experiments at NIST in the early days of TV to use the TV 
>> signal as a time dissemination source. It worked well, as coordinated 
>> with the NIST radio time signals. But it didn't turn out to be a 
>> practical solution.
>
> More specifically, the idea was to put a character code (like ASCII) 
> in the VIR (vertical interval reference) portion of the signal that 
> would be the correct time.  There turned out to be little interest in 
> the technology for this purpose, but an alternate application made it 
> big---closed captioning. For this, NIST won an Emmy Award. 
> https://www.nist.gov/node/774286 (Link inactive during lapse in 
> appropriations.)

A "timecode" was very much adopted by the video industry and remains the 
glue that holds professional video operations together. The core 
standard from the Society of Motion Picture and Television Engineers 
(SMPTE) is SMPTE ST 12-1:2014 Time and Control Code. The earliest 
versions of the standard were based on IRIG and appeared in the 1970s. 
This defines two flavors, "longitudinal timecode" (LTC), used as a 
timelink and synchronization protocol over analog wires, and "vertical 
interval timecode" (VITC), placing the timecode in the video signal 
itself. Many other timing related standards in the industry are based on 
it. I wrote an article about it:

Conversion between SMPTE hh:mm:ss:ff Time Code and Frames
http://edlmax.com/SMPTETimeCodeConversion.htm.

I've been on those SMPTE timecode committees for more than 20 years. 
With each revision attempts are made to add new features, like high 
frame rates and date and time. But each try goes down to failure because 
it becomes impossible to safely modify a standard that has become so 
widely adopted and deployed. It is from that experience I suspect no 
changes will be made to the specification of UTC and the Leap Second, 
one of the most widely deployed standards of all time.

-Brooks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190104/7aca0d21/attachment-0001.html>