[LEAPSECS] Cutting our losses: MST without UTC

[Michael Sokolov]

Hello leap second debaters,

As I have stated here many times previously, I am utterly disgusted by
what the ITU is considering doing to UTC.  As I have also stated here
many times previously, I will not sit back and allow the computer
systems under my care to be at the mercy of whatever the ITU decides to
do to UTC.

For many years now I have been thinking about an actual implementable
technical mechanism by way of which those who feel like I do can insulate
themselves and their computer systems from the whim of the ITU by
disconnecting from their UTC and using an alternate realisation of GMT.

Well, I have finally written the first draft of the formal specification
for this mechanism:

http://ifctfvax.Harhan.ORG/timekeeping/draft-utrspec.txt
http://ifctfvax.Harhan.ORG/timekeeping/draft-utrdef.txt

Basically it is an alternate timescale in which the utrdef.txt file
maintained and published by me takes the place of IERS Bulletin C.  For
as long as UTC leap seconds continue such that |DUT1| < 1 s, I will
adjust UTR at exactly the same times when Daniel Gambis adjusts UTC, and
the two timescales will remain in agreement.  However, We the People
reserve the right to steer UTR independent of UTC should the latter be
deleteriously redefined.

The latter part needs a little clarification.  Even though the master
copy of utrdef.txt resides on my server and I have the power to modify
it in any way whatever, it would be utterly hypocritical of me to do it
in the same unilateral manner in which the ITU is reigning over UTC.

Instead the UTR specification linked to above (subclauses 4.3 and 4.4)
calls for an open membership Internet mailing list to be created to
which any person or entity with an interest in the UTR timescale (or for
that manner any other realisation of GMT that is politically independent
of ITU/UTC) is welcome to subscribe.  That mailing list would be used to
discuss:

* Practical hardware and software implementations of UTR and other
  non-UTC timescales seeking to provide mean solar time;

* Scheduling of future rubberization instances in UTR (which take the
  place of leap seconds);

* Revisions to the UTR specification itself, which is currently only a
  draft for review.

Particularly with respect to the last two points, my vision is to
maintain the UTR timescale (in terms of scheduling rubberization
instances in utrdef.txt and amending the spec itself) by consensus of
the non-UTC mean solar time user community, rather than by unilateral
edict.

I know I am not the only person who is sickened and disgusted by what
the ITU is doing to UTC.  There have been occasional discussions on this
mailing list in which others have suggested taking matters into our own
hands and getting our own mean solar time in the event of UTC becoming
unusable.  If you are one of those people who would like to protest the
deleterious redefinition of UTC by using a non-UTC realisation of GMT, I
encourage you to read my draft UTR specification and the associated data
file linked to above, and if you like the general idea, let's work
together.

I think we are going to need a new mailing list separate from this one.
I feel that those of us who do need mean solar time should be able to
discuss the practical and technical aspects of how we can get it in the
absence of usable UTC without being constantly subjected to abuse and
ridicule from those who argue that MST is rubbish, and I feel that
trying to discuss it on this list would get us too much of the latter.

Tom, how would you feel about setting up a new Mean Solar Time Users
mailing list on leapsecond.com or leapsecond.org?  I'm asking TVB
rather than doing it myself for two reasons:

1. I don't have a good platform for hosting public mailing lists at the
   present moment;

2. Because I have stepped up to maintain UTR, having me own the mailing
   list as well would be a conflict of interest, or at least a perceived
   one.  I would like the list to be open to discussions of *all* forms
   of non-UTC mean solar time, of which my UTR is only one possible
   realisation.

MS