[LEAPSECS] it's WP7A week in Geneva

[M. Warner Losh]

In message: <AB352DD8-FFDB-4CCF-A582-C7DB12163C5F at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:

: M. Warner Losh wrote:

: 

: > Rob Seaman <seaman at noao.edu> writes:

: >

: >> First, discover the requirements.  Second, figure out how to meet  

: >> them.

: >

: > While the requirements are "known" up front, the problems in meeting  

: > them are much more non-trivial than people like Rob have said they  

: > should be.

: 

: As Gertrude Stein said, "a requirement is a requirement is a  

: requirement".  Either UTC is required to remain tied to the sun or it  

: isn't.  How much effort is necessary to make this work is separate  

: from the question of whether the requirement must be met.

: 

: I have (tediously, bombastically, endlessly) asserted that civil time  

: IS solar time.  This is a statement of requirements.  Requirements  

: describe the problem space.

: 

: On the other hand, focusing on leap second issues - whether features  

: or bugs - is to grapple with solution space.  One can certainly  

: entertain trading off one solution in favor of another.  One cannot,  

: however, simply decommission a solution unless the requirements that  

: demanded the solution in the first place are somehow removed.


Yes.  And I'll point out that many of the systems that have UTC
specified for them aren't because the folks using them need to have a
time scale that's tied to the sun.  UTC is specified because it is
what everybody else uses, and these folks need to be on the same time
as everybody else.

There are a number of solutions to the current leap-seconds problems
that don't completely decouple UTC from the sun.

There's some that do in the recognition that UTC really is going to be
viable at most a few hundred to a few thousand years anyway due to the
quadratic acceleration of leap second timing.

There's some that don't keep UTC coupled to the sun.

There's some that live in multiple of these spaces.

Life would be a lot simpler, for example, if GPS were to broadcast
every second or 10 an extra 40ish bits of data: last leap second, next
leap second.  Right now it does this every 1200ish seconds, which is
too slow.  As satellite acquisition times have improved, the
engineering balances that dictated a 20ish minute almanac download
need to change as well...

[[
   Life would also be simpler if there were some way to assume devices
   were connected to the Internet for this data too, but many trust
   scenarios and mobile applications make that difficult.  GPS has
   good, strong authentication available and deployed (SAASM), while
   there's no equivalent for ntp that's widely deployed and reliable
   today.  And even if it was, there's many places where you can't get
   internet, or the costs are prohibitively expensive.
]]

Anyway, as with all engineering issues, the practical problems should
be discussed as widely as possible, and the real requirements for the
system should be continually reevaluated to ensure that the system is
meeting the real needs of its users.

Warner