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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
