[LEAPSECS] Standards of time zones -Brooks Harris

[Brooks Harris]

On 2014-01-11 12:35 PM, Tom Van Baak wrote:

>> That's disconcerting.

> Brooks,

>

> Nice that the list has come back to life. Looking back on your original question about UTC documentation, you never mentioned what your actual application is. I think it would be helpful if you could state what your problem or your goal is.


I've been in the video business all my career. In this world, the 
frequencies you deal with are a crazy mix, coupled with requirements of 
pairs of things (like interlaced field/frame video formats) and audio 
sample rates. One nasty frequency that causes no end of headaches is 
30000/1001, the frame rate of NTSC television, the video rate you are 
probably watching in the US, Japan and other large places. That "1001" 
ratio creates all sorts of mathematical and implementation trouble. 
Europe and others run at 25/1, with is easy in some ways, by the odd 
number (25) causes other challenges. Keeping everything in sync and 
displaying is a wild world of interlocking standards.

I've been on technical committees for years. Typically "date-time" is 
not a hot topic - the video (and sound) just roll from some arbitrary 
moment, and any "date" applied is *very loosely* coupled to the media. 
But now, everyone is interested in synchronizing media with date-time. 
In particular, they want to use In particular, using 1588/PTP, and they 
want "local time". Well, guess what? "Media" is way easier (for those of 
us steeped in it) than "date-time".

Partly, the challenge is that time-keeping is "seemingly simple, yet 
deceptively complex". Getting folks to grasp the scale of difficulties 
is a challenge - "just put the date on it!". But even as you're willing 
to tackle it the difficulties mount, partly, as I've said, the 
terminology and standards are fractured. So, I'm reaching out to see if 
there's some way to fix that part.


> There are a lot of ways to handle UTC. In some respects it's easier than the Gregorian calendar.

>

>> 6. Rapid UTC (F. Arias, A. Harmegnies, G. Panfilo, G. Petit, L.

>> Tisserand) describes an effort to improve UTC, so maybe there's work

>> going on to help inform the debate further.

> Rapid UTC is not an issue this list needs to worry about. Essentially it just modernizes the method by which the various UTC(k) labs steer their local or national timescales (at the nanosecond level), a reduction from one month to under a week.


It seems like its related to Rob Seaman's earlier proposal to refine the 
update schedule of Leap Second insertion. Maybe it is, or maybe its one 
place his suggestion should be considered?


>

>> 7. New proposed definition of UTC (F. Arias, W. Lewandowski) states the

>> ''It was decided to postpone the decision until the World

>> Radiocommunication Conference 2015" . There, at least, are two names

>> officially related to the debate.

>>

>> Are those relevant? Is there communication with any of these people?

> Many of us know all those involved. It's a small world and everyone is trying to be helpful.


So maybe, just maybe, the list participants could find an audience 
there, and something could be done to head off the "kill Leap Seconds" 
movement? That's my hope, somehow.

-Brooks


>

> /tvb

>

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>