[LEAPSECS] Future time

[Warner Losh]

On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:


> 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;


To pick a pedantic nit: It is continuous. No "other than". UTC is a continuous time scale. It has a non-uniform radix that is expressed at the leap seconds when its rules for labeling seconds changes slightly to label the leap second 23:59:60. The timescale has a discontinuity when there's a phase jump. UTC does not have phase jumps, even if it chooses a non-traditional time to label some of its seconds once every year and a half or two.


> -    is currently the basis for most local timescales;


Most local timezones.... I don't believe they are actually timescales, in the technical sense.


> -    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.

...


> 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.


The leap second is, by definition, inserted in the local time zone at the same instant that it is inserted into UTC.


> 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.


Timezones are a matter for local government. However, since they are specified as being a fixed offset from UTC (or something that everybody fudges to be the same as UTC), this is the thing that mandates when the leap second is. In the horror show of the bizarre that's been paraded before this group, no examples have been presented where the leap is inserted at any time other than after 23:59:59 UTC, even if that's in the middle of the localtime day.


> 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.


Leap seconds aren't disruptive to television broadcasts because they aren't required to be aligned to anything. Frequency is more important than what some standard labels the a particular second.


> 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.


PTP has no leap seconds.


> 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.


It happens when it happens in UTC universally on this planet.


> 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.


Leap seconds are evil and must die, leaving alignment to the sun to local governments. Others may have a contrary opinion.


> Summary

> Time implementations that have evolved over time are no longer good enough.


How exactly are they no longer "good enough?" They are certainly stunningly adequate for most users.


> 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.


GPS handles these needs to three orders of magnitude better than you request.


> 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.


All timezones add the leap second at the same instant as UTC. Done.


> -    Promote a standard for instantiating leap second corrections in local time zones.


This is already common practice.


> -    Promote standards for the communication of all UTC time corrections including leap seconds and standard / daylight saving time shifts.


The de-facto standard here are the Olson databases...