Almost overlooked this one! That would never do... Clive D.W. Feather wrote:
> Rob Seaman said: > >> Requirements are discovered, not imposed. > > This from the person who insists that a priori civil time must synchronize > with the sun? Rather, it is ITU-R Study Group 7 that has insisted on a single a priori position since the issue was first raised. Feel free to skip the sermon below. <sermon> I do say that time-of-day is a requirement (or perhaps even a definition), and that this is a facet of civil timekeeping that may/must be discovered and is not imposed. It is part of the inherent description of the problem space. But how one thing synchronizes with another is part of any proposed solution. There is plenty of freedom for different classes of accommodation whose strengths and weaknesses can be evaluated in a trade-off study. The draft revision to TF.460-6 asserts that no synchronization must occur at all. If this is true, why not propose some round number like 100,000 SI-seconds per day? Rather, diurnal rhythms based on the synodic day occur in vast numbers throughout our society and its technology. These imply technical requirements. If they are neglected they will inevitably pop up somewhere else. Hence the timezone roulette talking point. It isn't raised on a whim; it keeps coming up because it must. That's the nature of a spurned requirement. Time-of-day is more fundamental to the problem description than timezones. I am confident, however, that a trade-off study would reject dislodging the timezone system from UTC. But the only way we would get to that point would be by undermining time-of-day first. This is why I have asserted that timezone roulette is a strawman argument. It is raised to undermine another facet of the problem space. Characterize the problem before exploring solutions. Why is this a radical position? </sermon> Rob Seaman National Optical Astronomy Observatory _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
