On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:

This idea pushes extra complexity into every implementation of low
level kernel-space software, firmware, and hardware.  That's nice as a
policy for full employment of programmers, but it's hard to justify by
any other metric.  Instead those low level places should be as simple
as possible, and that means making the underlying precision time
scale, and thus any broadcast distributions of a precision time scale,
as simple as possible.

The complexity for translating precision time in seconds (for
machines) to calendar time in days (for humans) belongs in the
less-critical and easier-testable outer layers of software which do
user-space presentation, internationalization, and GUI which can be
broadly shared between many hardware implementations.

--
Steve Allen                    sla@ucolick.org              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street              Voice: +1 831 459 3046        Lng -122.06015
Santa Cruz, CA 95064          http://www.ucolick.org/~sla/  Hgt +250 m

Hi Tom:

I like this idea.  I addresses the lesson from Y2K that something done often works much better than something done only
occasionally.
That's way you see the firetruck at the local store, because it's used all the time and so is more likely to work when
needed.

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------

Steve Allen wrote:

Hi Steve,

Wow, that's most succinct two paragraph argument I've read for why we shouldn't have leap seconds at all. Where were you the past decade when this level of passion and clarity in the ITU debate was needed ;-)

/tvb

I was inclined to agree, cynically reasoning that many implementations
would argue that the leapseconds would average out in most applications and
they could ignore them.

But actually, it would be good for programmers to properly separate the
concepts of elapsed time and clock-time. If elapsed time were handled by
kernels and clock-time handled by a user-mode UTC or calendar process, that
would be a cleaner solution with overhead only where needed (or where the
OS is big enough for it to be a trivial element).

As a side issue, what would be the impact of having frequent
leap-milliseconds instead of infrequent leap-seconds ?

On Thu, Jul 21, 2016 at 8:53 PM, Steve Allen sla@ucolick.org wrote:

The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.

Jim Palfreyman

On 22 July 2016 at 06:01, Brooke Clarke brooke@pacific.net wrote:

Hi Tom,

Nope, LSEM avoids the zero leap second situation. That's the idea: to always have a leap second. Either an add or a delete, at the end of every month. The beauty is that it wouldn't violate how UTC is already defined. Leap seconds would become a monthly normal instead of a rare event; that is, a regular pain in the ass instead of an exceptional pain in the ass [1].

Note that UTC would continue to stay within a second of UT1, so no problems there either. If you think about it, LSEM, like any fast dithering system, would actually create a better average value of UT1 than the existing slow step system. But that's not a goal; just a PWM side-effect.

There's more info in the original LSEM proposal and its long thread in the archives:

http://six.pairlist.net/pipermail/leapsecs/2010-November/001813.html

add to your list: airplanes, high-speed trains, telesurgery, self-driving cars, MRI machines ...

Yes, and that's the key question. And it's only getting worse. LSEM is not a random idea or a quick fix. As long as UTC has leap seconds (debatable) or as long as technology continues to depend on ever more precise time (likely) we have to make the handling of leap seconds as robust as the handling of, say, midnight rollover.

I realize it's probably too late in history to deploy. There's no right answer. LSEM is food for thought. Lots of people are and have been trying to avoid the long-term train wreck that the current definition and implementation of UTC will lead to. If you have time, read 15 years of our postings over on the leap second mailing list.

I think at this point, we should move the thread over to LEAPSECS alone, and give time-nuts a break. The cross-posting is getting confusing.

Thanks,
/tvb

[1] astronomical society specification ;-)

----- Original Message -----
From: "Tom Holmes" tholmes@woh.rr.com
To: "'Discussion of precise time and frequency measurement'" time-nuts@febo.com
Cc: "'Leap Second Discussion List'" leapsecs@leapsecond.com
Sent: Thursday, July 21, 2016 12:03 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnightUTC December 31 this year

If UTC time was adjusted every month would stick with one full second? Or
some smaller quantity?

On Thursday, 21 July 2016, Brooke Clarke brooke@pacific.net wrote:

How does this make those things more complex, though? Those things are
already required to deal with both knowing about and adjusting the time
for leap seconds (both adding and removing, though adding is the only
direction that's ever been tested) ... increasing the frequency of the
announcements doesn't really add complexity there, except in places where
the code was already deficient (e.g. doesn't currently handle removing a
leap second, which is a bug).

If you wanted to do precise measurement of time between two dates, you'd
have to know about the number of leap seconds in between, but a) that's
easily done at a higher level than the kernel, and b) we already have to
do that to deal with existing leap seconds, just adding more datapoints to
the math doesn't actually make that more complex.

Am I missing something obvious where this would add complexity that isn't
already there?

-j

But would it really solve your problems, Jim?  The problem is essentially that periodically, there are two different clock times that represent the same moment in time.  For telescopes, stock markets, spread spectrum, time-based encryption, etc that's a big problem.  Would it not be better to separate out those entities that are more dependent on precision sequence than on clock time and accept that they are just going to be different?  Yeah, the talking heads on CNBC and Bloomberg would gravely announce that today's stock market was opening a second later, but so what?  At least there wouldn't be any more questions about exactly when transaction X occurred.

Bob
 -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Jim Palfreyman <jim77742@gmail.com>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Thursday, July 21, 2016 4:38 PM
Subject: Re: [time-nuts] LSEM (Leap Second Every Month)

The idea is the same as my local telco and their main exchanges.

Every month they walk up to the main circuit breaker and cut the power to
the entire building. All the UPSs and diesel generators get tested in anger.

This leap second solution is the best I've heard so far.

Personally I now hate leap seconds because it ruins many hours of my
observations at the radio telescope - but if this was implemented it would
force the software problems to be fixed.

Jim Palfreyman

On 22 July 2016 at 06:01, Brooke Clarke brooke@pacific.net wrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

On 7/21/2016 2:53 PM, Steve Allen wrote:

Why?  That would only seem to be true if the leap second decision is
already made there.  Most systems I'm aware do this in presentation
level firmware.

I think I understand what you are saying, but I'm pretty sure I
disagree.  The vast majority of complexity (and risk) of most software
and testing comes from exceptions and making sure all combinations are
tested. In this case the exception is simplified.  You still need to
detect end of month, but you have regular logic to implement. As a
practical matter this should be easier to code as a fixed time of
execution operation.

I agree for the most part.  Complexity should be driven as high in the
layer stack as practical.  What about this proposal requires changes
from the place it is already done in a particular system?

--
mailto:oz@ozindfw.net
Oz
POB 93167
Southlake, TX 76092 (Near DFW Airport)