Tony Finch wrote: > Rob Seaman wrote: > >> I was describing aspects of the problem space and neither discussed, nor >> asked advice on, the various solutions we may have implemented. > > That's fine, but if someone mentions a problem as if it has not yet been > solved then it's rather tempting to state the solution. However if you really > insist on discussing situations I can explain how they are handled.
Thanks for demonstrating my point in much greater detail, and it's telling that you imply that discussing situations is somehow a secondary activity. Rather, before speculating on solutions the problem has to be characterized. Often the process is iterative. But typical human behavior (likely dating back to the veldt) is to jump to the last step and be done with the whole thing. We can see how well that tactic has worked for Study Group 7. Organizations (such as observatories, for instance) have much experience with this particular issue and with strategies for handling it. Similarly, after a dozen years the ITU-R has finally chided SG-7 for failing to consult with stakeholders. > UTC is bad because it is incompatible with ancient notation and it is > unpredictable; The ways that UTC is good or bad are many and interrelated. Oversimplifying the problem space will make viable solutions vanish into the wainscoting. > the correct solution is to use either TAI or UT1 as appropriate. That is, the civil timekeeping problem space includes use cases pertaining to both. Leaving either one out of the analysis makes a coherent solution impossible. Folks don't like being lectured and I'm sure I seem boorish, but after 12 years a simple description of the concept of engineering requirements appears to remain controversial. There are no correct solutions; systems engineering seeks satisfactory solutions. A single problem - a coherently described problem space - may permit many different solutions that meet requirements (perhaps allowing a few liens in the mix). Trade-off studies against the familiar dimensions of cost, schedule and performance - and the risks (brittle higher order moments) of each of these - are necessary to identify the "best" option(s). But best here isn't some sort of Platonic ideal, rather just an efficient solution reached through satisficing. > Displaying the time correctly for multiple locations has been solved for > decades. Problems don't stay solved. Ubiquitous videoconferencing has changed the nature of meetings. Each solution has a context. Rob _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
