Tony Finch wrote: > There is no solution to the problem,
What sort of attitude is that? :-) > if you define the problem as satisfying the requirements No, no, no. "Define" is a poor choice of words for how problems are characterized. Rarely is a situation such that humans get to simply decree the shape of some set of issues. The problem boundaries are often not even known at the start of the project. In particular, requirements are discovered through a complex iterative process with input from use cases, stakeholders, standards, etc. > that civil time is tightly coupled to UT, there are always 86400 seconds in a > day, and seconds are SI seconds realised on the geoid. Those are two facets of the situation. There are many more. > We've tried relaxing two of these requirements and neither result was very > satisfactory. "Relaxing" is one verb that might be used in the search for satisfactory solutions. There are others like "replace", "rebuild", "redesign from scratch". The thing about requirements is that whatever the verb, all requirements must be met. That's what it means to be "required". Exactly how they are met is a ripe area for cleverness. Our common problem here is civil timekeeping. There are numerous other problems in timekeeping, and a world-girdling civil society has many problems. We're looking for the essential aspects that characterize (or "define", if you'd like) civil timekeeping in particular. Two of these as you say (more consensus :-) are adherence to two standards, the SI-second and the synodic day. Well, the first is a standard - the second is simply a fact of life of living on planet Earth. That is the problem that we share in common. Note: one single problem. The thing about system engineering is that one problem has multiple solutions. We're not looking for some unique resolution to our troubles. We're seeking among many possible solution strategies for a satisfactory resolution. Problems are as much about the stakeholders (humans) as they are about the stakes. The engineering process is pretty simple, but apparently devilishly difficult for humans. 1) Characterize the problem. 2) Evaluate possible solutions. The reason we're having trouble with #2 is that #1 isn't finished. That said, the time has been well spent fending away the ITU's monomaniacal non-solution time and again over the past decade. As a result we have peered and poked into numerous nooks and crannies. This experience can serve us well at building consensus on how to move forward. The problem has solutions, not the other way around. The ITU can't mandate their choice of solution and expect the problem to lie down and whimper at their feet. Rob _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
