On 2014-01-19 03:53 PM, Zefram wrote:

Your definitions are generally poor.  There is much that you omit or
make horrendously unclear.

There really aren't any definitions yet. Its an informal email. I'd hoped I could make a little progress without completing the entire document. Maybe not.

There's a definite skill to writing usable
technical specifications, and you don't have it.  In the light of this,
it would be unwise for you to tackle your stated primary objective of
new definitions to supplant TAI and UTC.  It is conceivable that you
could develop this skill in time, but not a short time.
That's not fair.

I've got one international standard under my belt as primary author that retains whole swaths unchanged from my strawman proposal. I've contributed significant sections and modifications to standards text for over 15 years.

I've got a 30-odd page document draft of this proposal on my desktop. I've got an exploratory c/c++ implementation of it running which does what's intended and which interacts with POSIX, Windows and SNTP in ways I expect.

Both the implementation and any formal description of it are particularly hard problems given the long and tortured history, the myriad of objectives, and entrenched attitudes.

I appreciate your constructive input.

Thanks.

-Brooks



As for other parts of CCT, you're mixing together too many things under
the CCT banner.  Timezones are a separate concern from time scales
such as UTC.  The calendar is another completely separate concern; none
of the time scales here is especially tied to the Gregorian calendar.
(UTC has a Gregorian-based rule for when leap seconds are permitted,
and significant epochs tend to be on Gregorian year boundaries, but
generally describing days by MJDN works perfectly well.)  Even looking
just at your two time scales, they're logically fairly distinct concerns,
and the definitions have suffered from you tackling both together.
You are treating in the same way things that have relevant differences,
not giving each the individual attention that it needs.  To produce
better results you need to tackle narrower subproblems.

-zefram
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs



_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Reply via email to