After nine years of this discussion, the most flabbergasted I've been
is when I realized that asserting proper system engineering principles
riled the mailing list more than my most extreme flights of rhetorical
fancy. So Pete has identified a system requirement, and Warner
(rather too heavily excerpted below), has done a nice job at writing a
problem statement.
A fundamental aspect of system engineering is to separate the
definition of the problem from the specification of a satisfactory
solution. Each problem has many possible solutions. Say again: each
problem has many possible solutions.
To constrain the solution parameter space, we have to discover the
requirements implicit in the problem statement in front of us. This
process is rarely straightforward since the problem can only be
understood in its full context (typically expressed as use cases).
For timekeeping, this context is vast indeed. There is a very strong
benefit to writing down a set of requirements, however; the discussion
can focus on the proper description of the problem before entertaining
trade-offs among the many possible solutions.
Once a consensus is reached about the requirements for a project, a
technically savvy crowd will have significantly less trouble agreeing
on solutions that implement those requirements.
After those nine years - even following a very ad hoc process - the
problem facing civil timekeeping is much better understood (by this
group, anyway). After nine years, however, all we still understand
about the one-and-only notion ever proposed for WP7A deliberation is
that they (whoever "they" are) think they've found a sly, zero effort,
way to avoid the problem entirely. This doesn't comprise a "solution"
at all.
This is what my grandfather called a "lazy man's load" - piling up too
many items into a single precarious heap, rather than making the two
trips - with manageable loads - that are really required.
Civil timekeeping comprises two parts - two lists of requirements.
There is the Earth orientation part that Pete is discussing, and there
is the interval time part that Warner is referring to. It isn't
surprising that it is a challenge to find a single set of requirements
that satisfies both. It will ultimately prove much easier to do so -
and to entertain solutions implementing those requirements - if we
don't spurn the tools of system engineering.
Rob Seaman
NOAO
--
On Nov 9, 2008, at 2:15 AM, Peter Bunclark wrote:
So a User requirement might be:
The rythms of life, including the orbits of the earth and the moon,
the rotation of the earth, and convenient sub-divisions of the
rotation
down to nearly the limit of human perception, shall be expressed in
a single monotonic calendar.
On Nov 8, 2008, at 8:48 PM, M. Warner Losh wrote:
Since most of the world
runs on time_t, leapseconds necessarily introduce a time step (or a
time error for the misguided folks that try to paper over the leap
second by running time slower on leap day...).
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
