[LEAPSECS] Future time

[Stephen Scott]

Most recent posts have tried to disect the past. This is about the use 
of time now and in the future.

_*UTC and Leap Seconds*_
The basis of my understanding is that UTC is a timescale that:
-    progresses at a rate of the second (SI) and has done so since 
1972-01-01.
-    is expressed as a count in the form of date, hours, minutes and 
seconds;
-    is continuous other than the discontinuities resulting from leap 
second corrections;
-    is currently the basis for most local timescales;
-    is related to the International Atomic Timescale (TAI) by an 
integer leap second offset;
-    until further notice, is in force and is not expected to be 
revised, at least not before 2015.
My primary interest is not how we got here but how we go into the future.

_*The growing importance of precise time*_
My background, experience and field of interest are primarily in 
timekeeping and signal generation for television production and 
broadcast. In a broad sense television also includes radio and 
distribution of other forms of media.

Precise time is important in television both for the synchronization of 
various program elements (for example audio/video lip-sync) and the 
quality-of-experience (QoE) to the viewer of program segments which must 
flow smoothly from one segment to the next.

Historically television developed as a system that was isochronous 
glass-to-glass. Typically, within a television facility time, and 
synchronization reference signals are generated at a central point and 
distributed within the plant in a star topology. These reference signals 
are generated from stable local oscillators and because discontinuities 
are disruptive to synchronous operations they are corrected to an 
external reference, at a time-of-day that will be the least disruptive. 
With the replacement of some synchronous signal technologies by packet 
switched signals there is a desire to replace or supplement traditional 
reference signal distribution with a system that is based on a global 
time reference that can be used to generate timing reference signals at 
the point of use. The diminished central control over the management of 
discontinuities in the time references places an increasing importance 
on the deterministic nature of these time references.

How much resolution and precision is required? The answer is not 
universal and depends on the application but for example:
-    A leap second shift represents about 30 video frames in North 
America or 25 frames in Europe. Most television operations are based on 
single frame accuracy.
-    Audio can require much higher accuracy when considering spatial 
rendition of multi-channel audio.
-    Video signals are based on very precise frequencies. Recreating 
frequencies requires very accurate and deterministic timestamps.
A peculiarity of the North American television system is the actual 
frame rate is 30/1.001 Hz. This non-integer rate creates an additional 
complication to generating reference signals and an additional 
dependence on the time reference being deterministic. This may require 
microsecond accuracy and 24/7 availability.

_*Instantiation of leap seconds*_
In a prior inquiry about leap seconds I had asked about the application 
of leap seconds to various local tines in the different time zones. I 
have searched for documentation on how the leap seconds are instantiated 
in local time zones around the world. There is a need for a standard. 
This is a reiteration of the request for information.

This question was raised because TF.460-6 specifies the leap second 
adjustment to UTC and the emission of UTC. There does not seem to be any 
guidance for the application of leap seconds to local timescales for the 
timezones UTC+14 to UTC-12. There is the perception by some that the 
leap second should be instantiated globally at the same time as it is 
signaled by UTC. I looked in TF.460-6 but could not locate a definitive 
statement to this effect.

If this is the case then the leap second changes would be instantiated 
just before 9:00 (9 AM) local time in Tokyo (UTC+9) and just before 
19:00 (7 PM) local time in New York (UTC-5). These are just examples but 
in either case it would probably be disruptive to critical time keeping 
systems to have a time shift instantiated at these times. The 
broadcaster typically makes these changes at a time early in the 
morning. I cannot believe that any other industry that has a time 
critical operation does not do something similar.

It's not just for television. The evolving application of packet 
switched technologies (for example Ethernet and the Internet) in 
television, financial, scientific, telecommunications, power generation  
and other industries is creating a growing demand for the availability 
of accurate and precise, but most importantly deterministic time 
references. Several industries have developed IEEE 1588 PTP Profiles 
that address their specific needs.

Notwithstanding the possibility of stopping leap seconds it is more 
important to:
-    have a deterministic procedure for instantiating leap seconds in 
each time zone and;
-    similarly for standard time and daylight saving time shifts which 
understandably are under local governance is lacking a better method for 
dissemination.

I believe there is no particular requirement to eliminate the leap 
second if their insertions are well and deterministically defined and 
communicated. We can't fix what we don't know. Similarly the need to 
define the standard time / daylight saving time shifts, however that is 
beyond the scope of this group.

_*Summary*_
Time implementations that have evolved over time are no longer good 
enough. New and emerging applications are creating more demanding 
specifications for time delivery systems.:
-    Availability via wired and wireless delivery;
-    Microsecond accuracy or better;
-    Consistent results via multiple delivery mechanisms;
-    Stability to permit the generation of stable frequency references.

It's not time that needs to be fixed, it's the standards or the lack 
thereof.

What can this group do to:
-    Document local practices for instantiating leap second corrections 
to UTC.
-    Promote a standard for instantiating leap second corrections in 
local time zones.
-    Promote standards for the communication of all UTC time corrections 
including leap seconds and standard / daylight saving time shifts.

The difficult can be done today, miracles tomorrow, and the impossible 
will take a bit longer and many committee meetings.

REGARDS*
Stephen Scott*



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140118/ec87e597/attachment.htm>