In message: <ab352dd8-ffdb-4ccf-a582-c7db12163...@noao.edu> Rob Seaman <sea...@noao.edu> writes: : M. Warner Losh wrote: : : > Rob Seaman <sea...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs