[LEAPSECS] Bloomberg announced its smear
brooks at edlmax.com
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:
>>> 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.
>> 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
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
* 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
Worth consideration, I think.
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
> This email has been checked for viruses by Avast antivirus software.
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS