[time-nuts] UTR timescale draft spec

Magnus Danielson magnus at rubidium.dyndns.org
Sat Aug 6 16:06:49 UTC 2011

On 06/08/11 17:36, Michael Sokolov wrote:
> Magnus Danielson<magnus at rubidium.dyndns.org>  wrote:
>>> The present specification outlines a low cost method for obtaining a
>> "low cost method" is a potential goal, skip statement here.
> IOW, you are suggesting that the line in question read
> "The present specification outlines a method for obtaining a synthetic
> timescale that ..."?
> Having a low implementation cost is part of the raison-d'etre for the
> UTR timescale and its specification, otherwise one could go straight for
> the even more rebellious solution of ignoring all broadcast time
> entirely and going back to the circa-1900 style of timekeeping.
> However, I suppose that the words "low cost" do not need to appear in
> that particular place in that sentence, especially since the title line
> of the spec reads "Specification for a low cost synthetic timescale
> approximating true Earth time".

If you write a specification, keep it clear of debate, that it better 
suited for a background document.

If you as in this particular sentence is introducing the overview 
points, the low-cost aspect should either be a point of its own or 
skipped due to redundancy.

>> GMT is no longer used,
> "GMT is no longer used" is a false predicate.  Although it may no longer
> be used by the snobs in ITU/IAU/etc agencies, it is still very much used
> by the rest of the world.  There exist plenty of legislation and
> standards which call for GMT or generic mean solar time rather than UTC,
> and I furthermore encourage this practice in Clause 5 of my
> specification, because I consider it to be the right thing to do:
> natural timescales are more reliable, enduring and corruption-proof than
> anything man-made.

GMT is no longer a techical scale of its own. UT1 and UT2 is observed 
scaled in the sense that GMT was prior to them. What I proposed was that 
you would use it as a practical handle to the technical scales of UT1 
and UT2.

"... using a GMT type of time-scale such as UT1 or UT2" was about what I 
had in mind.

>> but you may use it as a popular name reference
>> for what is now known as UT1 or UT2 time-scales.
> But UT1 and UT2 are too specific and may be viewed as *possible
> realisation options* for an even more abstract platonic ideal of GMT or
> generic MST.  My goal here is the specify the abstract platonic ideal
> which my timescale seeks to approximate.

OK, key question here. How will your timescale relate to observed time 
to provide a GMTish time-scale?

>> Skip "socially acceptable"
> The intent here was to distinguish between good-faith realisations /
> approximations of GMT (or MST in general) and bad-faith lip-service
> claims to be a suitable replacement for GMT/MST, such as the entire
> bait&  switch scheme of the ITU.  But I do see now that substituting
> the words "good-faith" for "socially acceptable" would be better.

Again, debate and arguments to separate document from specification. You 
seem to miss that this is one of the key points of my criticism.
Remove flaim-baits and keep on the functionality.

>> This has nothing to do with real numbers, so skip that reference.
>> Infact, what you tries to say is that you want a monotonic counting
>> mechanism, which timescales such as UTC does not provide upon leap seconds.
> Well, not quite, there are two separate requirements in here:
> 1: having the timescale read as a real number
> 2: having that real number increase monotonously
> For example, the common POSIX/NTP implementations of pseudo-UTC satisfy
> 1 but not 2.  OTOH, "true" UTC is monotonous, but is not a scalar.
> However, I agree that my middle bullet point in that list needs
> improvement.  I'll work on it some more.

You just got better wordings here. scalar and mononously are the key 
things, then say that.

>> Shall I continue my review or have you got the criticism by now?
> Before we continue, let's set up the Mean Solar Time Users mailing list,

Regardless we should not be too lengthy on this list with this thread.


More information about the time-nuts mailing list