[LEAPSECS] Bloomberg announced its smear

Sat Sep 24 15:14:38 EDT 2016

Hi Tom, Stephen and Stephen;

Adding to Stephen Scott's comments...

On 2016-09-24 11:39 AM, Stephen Scott wrote:
> Hello Tom, Stephen;
>
>
> On 2016-09-24 08:26, Tom Van Baak wrote:
>> Stephen,
>>
>>> As I've been saying for years, what we need (desperately) is a
>>> standard for smearing, aka 86400 subdivision days.
> That's sort of where we were before there were leap seconds. The 
> second used for UTC clocks was shifted slightly from the second SI.
>> But that's part of the charm in smearing -- that there's no one way 
>> to do it, and you're free to modify it as you wish.
> That's called anarchy.
>>
>>> My preference is UTC-SLS, but I don't really care so long as it is 
>>> an agreed standard.
>> UTC-SLS has always been a good example why an inflexible academic 
>> standard is a bad idea.
>>
>>> I know that many find smearing offensive, but its timet o move on and
>>> get the standard written.
>>>
>>> Stephen
>> Smearing is fine. It's a practical solution to an intractable 
>> problem. But forcing everyone to implement it the exact same way 
>> misses the point. You can't create a standard for your favorite set 
>> of time applications and then try to force it upon everyone else's 
>> time applications.
> Smearing is fine if you don't depend on a second being a second.
> I work in the broadcast industry where time synchronization is 
> critical. Television is fundamentally developed as a synchronous 
> process from glass to glass. Radio and TV broadcasts are a major means 
> of disseminating time.
The challenge here is that the broadcast industry needs fixed-epoch 
deterministic local timescales to accomplish media (video and audio) 
timekeeping. The broadcast industry also faces the requirement of 
handling many media-related frequencies,  including audio sample rates 
those related to the NTSC frame rate of 30000/1001. That 1.001 second 
denominator is a nasty number to cope with.

>
> The problem is not the leap second. The problem is that every local 
> authority is free to incorporate the leap second when and how they 
> wish and even then end users deviate from that is that is not 
> convenient. There is no international standard or even a convention 
> that could be followed. The lack of these standards is what is 
> promoting Smear Type 1, Smear Type 2, Smear Type 3, etc.
Fundamentally, the early implementations of POSIX and the many systems 
based on its heritage cannot represent "23:59:60" and so most systems 
are *indeterminate* at (or near) the Leap Second. Related factors and 
implementations have created mismatched, and, in some cases buggy, 
systems.  Smear is introduced to "hide" the Leap Second from the 
downstream systems to avoid, or mitigate, the difficulties, including 
system failures. The smear introduces yet another longer period of 
indeterminate timestamps.

Meantime, the very many definitions of local time (time zones) and 
Daylight rules are hugely complex and somewhat unpredictable and 
uncontrollable. And with at least two major sources for zone zone 
information in the field, Tz Database and Microsoft, more complexity and 
mismatched information is introduced in the challenge.

The difficulty of the local time topic overwhelms the the challenge of 
Leap Seconds, both in terms of political and technical agreement and in 
the magnitude of the likely errors and inaccuracies. "Fixing Leap 
Seconds" is necessary but insufficient to solve the local time problems.

So here we are;

* Leap Seconds are with us in the international time and dissemination 
standards and master clocks for at least another decade, probably much 
longer.

* A bazillion systems and devices are in the field that cannot reliably 
or accurately handle Leap Seconds

* The three (at least) smear systems are up and running, helping 
mitigate system failure of down-stream systems within their own realm, 
but are mismatched.

* Microsoft has taken another approach to Leap Seconds with Azure, 
incompatible with the smears.

* IANA has taken responsibility for Tz Database, but its not standardized.

* Microsoft has their own (proprietary) time zone mechanisms, only 
partly compatible with Tz Database.

In the medium term, I think it would be helpful if the smear systems 
were the same. At least you could determine which time-points were part 
of the smear and thus indeterminate. As it stands you have to assume the 
broadest span (24 hours around midnight) and that no timestamp in that 
range can be trusted. But somebody else could use yet another 
formulation, and then its even more unreliable. Some standardized 
guidance document could help.

In the long run, the industry, and society in general, is going to have 
to come to grips with the issues. This will ultimately require a set of 
standards running all the way from the BIPM, IERS, and ITU 
specifications, through the master clocks and time dissemination 
protocols, to receiving systems and file system timestamps. That will 
take many years. But if it doesn't happen the electric civilization is 
going to encounter increasing difficulties.

Where to start? Leap Seconds must be "fixed" to provide a reliable 
reference timescale because it is the basis of "civil time". There are 
some obvious steps that have been discussed here and elsewhere for 
years, but some consensus needs to be found.

Meantime IANA Tz Database has proven to be a pretty good source of local 
time. With more formalization it could develop into a more reliable 
source of zone data.

>
> IMO the Microsoft Azure approach of shifting the UTC timescale forward 
> or backward so that the leap second is incorporated at the end of the 
> day in every local time zone. The timescale will have the exact same 
> mathematical progression for all UTC offset time zones. Also the leap 
> second will not be incorporated at a human activity critical time 
> points such as the opening of a financial trading center.

I find this approach compelling for several reasons.

Common practice introduces Leap Seconds in the local YMDhms 
representation simultaneous with introduction at UTC. This produces a 
discontinuity in the YMDhms count sometime in the middle of the day 
(between midnight and midnight) in local time. This introduces a lot of 
complexity into system implementations, and, combined with the 
complexity and vague definitions of local time, makes the exercise error 
prone. This is a contributing cause of "fear of Leap Seconds"

Introducing Leap Seconds on each local timescale at midnight (the second 
before midnight, the end of the day):

* Integral second increments avoids need for timebase frequency smear, 
making determinate accuracy possible.
* Never presents receiving systems with midday discontinuities.
* Creates a set of *identical* local timescales (at "normal" time, that 
is, without Daylight applied). As Mr Scott says "The timescale will have 
the exact same mathematical progression for all UTC offset time zones."
* Forms a symmetrical array of local timescales
* Greatly simplifies implementation because all local timescales at 
normal time are identical. Implementation of one timescale is applicable 
to all local timescales.
* Greatly simplifies duration calculations along each local timescale.
* Greatly simplifies duration calculations and conversions amongst local 
timescales.

Worth consideration, I think.

-Brooks

>>
>> /tvb
>>
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>