Leapsecs Listserve Moving

[matsakis . demetrios]

Dear Leap-seconders,

For the past seven years, this listserve has served as a forum for a
considerable amount of discussion on UTC, generating some heat but more
light.  I have enjoyed my mostly-silent role as listserve manager,
particularly as most of the real work was done by David Johns (and Ken
Senior before him).

Lately, various technical developments are making it increasingly difficult
for the U.S. Naval Observatory to maintain this listserve. We are fortunate
that Tom Van Baak has agreed to assume the responsibility of hosting it.

You should start submitting your emails to [EMAIL PROTECTED]  All
current subscribers are automatically being transferred to the new list so
the hosting change should be somewhat transparent.  Subscription
information, archives, and other list information is at:
http://six.pairlist.net/mailman/listinfo/leapsecs.

We will verify that the new list is working and then on Friday we will close
down the old list at rom.usno.navy.mil. If you did not get this message, or
do not shortly receive the welcome message on the new list, please let Tom
and me know.  Tom's email is [EMAIL PROTECTED] and mine is
[EMAIL PROTECTED]

I will remain a member of this list, and look forward to following the
continued discussion.

Demetrios Matsakis

Re: Introduction of long term scheduling

[matsakis . demetrios]

As many have pointed out on this forum, these various timescales do have
very specific meanings which often fade at levels coarser than a few
nanoseconds (modulo 1 second), and which at times are misapplied at the
1-second and higher level.

GPS Time is technically an "implicit ensemble mean".  You can say it exists
inside the Kalman Filter at the GPS Master Control Station as a linear
combination of corrected clock states.  But there is no need for the control
computer to actually compute it as a specific number, and that's why it is
implicit.  Every GPS clock is a realization of GPS Time once the receiver
applies the broadcast corrections.   GPS Time is steered to UTC(USNO), and
generally stays within a few nanoseconds of it, modulo 1 second.  UTC(USNO)
approximates UTC, and so it goes.

The most beautiful reference to GPS Time is "The Theory of the GPS Composite
Clock" by Brown, in the Proceedings of the Institute of Navigation's 1991
ION-GPS meeting.  But others, including me, routinely publish plots of it.

--Original Message-
From: Leap Seconds Issues [mailto:[EMAIL PROTECTED] On Behalf Of
Ashley Yakeley
Sent: Tuesday, January 09, 2007 2:22 AM
To: LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: [LEAPSECS] Introduction of long term scheduling

On Jan 8, 2007, at 22:57, Steve Allen wrote:

> GPS is not (TAI - 19)

What is GPS time, anyway? I had assumed someone had simply defined GPS to be
TAI - 19, and made the goal of the satellites to approximate GPS time, i.e.
that GPS and TAI are the same (up to isomorphism in some "category of
measurements"). But apparently not?
Are the satellite clocks allowed to drift, or do they get corrected?

--
Ashley Yakeley

Re: listserve restored

[matsakis . demetrios]

Our listserve had to be restarted today.  I don't know if any emails were
lost.

If your contribution has not appeared, please resend it.

Re: what time is it, legally?

[matsakis . demetrios]

My few-month old mac gives me a message saying "This attachment is a type
not yet supported"  I also get this problem on my XP at home but not on the
one at my office.  A newphew of mine forwarded me the reason once, and it is
related to shortcuts in the email bit-pattern.  I forget which software is
at fault.

I want to apologize for any and all technological failures of this
listserve.  To avoid such failures in the future, Tom Van Baak has agreed to
take over its management and he is now working on the technical issues
involving the migration.

Demetrios Matsakis

-Original Message-
From: Leap Seconds Issues
To: LEAPSECS@ROM.USNO.NAVY.MIL
Sent: 12/12/2006 7:14 PM
Subject: Re: [LEAPSECS] what time is it, legally?

I'm given to wonder how much of the friction on this mailing list is
simply due to the shortcomings in the technology that implements it.
I've appended a message I sent in August with four plots attached.
Can someone tell me whether it is readable now or was successfully
delivered back then?  I rummaged around on the list archive and on
archives accessibly via google and find no copy of this message that
survived the communications medium.

On Dec 12, 2006, at 2:17 PM, Tom Van Baak wrote:

> Is there a technical definition of the "mean" in "mean solar
> time" that would help guide the discussion?

See the appended message.  There appears to be a natural excursion of
several minutes – even in the absence of first order lunar effects
– in accumulated "leap" offset over the course of several
centuries.  Undoubtedly an expert could wax poetic on this subject
should one care to speak up.  Perhaps this natural variability could
be used to start to wrestle with the issue.

> One could argue that adding 50 or 100 leap milliseconds a
> few times a year (as was done in the 60's) to preserve the
> mean is just as valid as adding a couple of leap seconds
> every few years (as is done now) is just as valid as adding
> a couple leap hours every few thousand years (as has been
> proposed).

I'm with you for the first two, but not the third.  An approximation
that is as large as the width of a timezone is equivalent to
eliminating timezones.

> I'm not arguing for one over the other but it seems to me
> all three models achieve a mean.

See my previous message.  (Assuming it was delivered.)

> None of them prevent secular drift.

Secular means you never zero it out.  Pretending that we can get away
with that is where the ALHP fails.

Rob
--


Begin forwarded message:

> From: Rob Seaman <[EMAIL PROTECTED]>
> Date: August 5, 2006 6:47:29 PM MST
> To: Leap Seconds Issues 
> Subject: Re: trading amplitude for scheduling
>
> John Cowan wrote:
>
>> Rob Seaman scripsit:
>>
>>> Third result - even in the absence of lunar braking, leap jumps
>>> (or equivalent clock adjustments) would remain necessary.
>>
>> Why is that?
>>
>> If the SI second were properly tuned to the mean solar day, and the
>> secular slowing were eliminated, there would be no need to mess
>> about with
>> the civil time scale, because the random accelerations and
>> decelerations
>> would cancel out in the long run.  Of course, we'd have to
>> tolerate larger
>> differences between clock time and terrestrial time, but we'd
>> expect that.
>
> Excellent discussion.  The answer depends on how much larger the
> clock differences are, and on the meaning of the word "tolerate".
> As Tom Van Baak said:
>
>> My understanding is that, in addition to astronomical
>> effects (lunar/solar tides), no small number of geological
>> and climatological phenomena also contribute to the
>> instability of the mean solar day. That all the random
>> accelerations exactly cancel all the random decelerations
>> in any finite time, short- or long-term, is very unlikely.
>
> Which is to say that "proper tuning" may not even have a
> definition.  It certainly is non-trivial.
>
> Consider the historical trend (from http://www.ucolick.org/~sla/
> leapsecs/dutc.html):
>
?
> Detrend the data by removing the 1.7 ms/cy secular effect:
>
?
> (I read the LOD from the plot every century - should repeat with
> the original data, but results should be acceptably accurate.  I'm
> sure somebody would be happy as a clam to point out any errors I
> may have made :-)
>
> There are positive and negative excursions from "normal" that
> persist for centuries.  For the purpose of civil timekeeping, we
> don't care what geophysics causes these excursions, or even whether
> the rather evident sinusoid is real or not, but just that the
> residual ~ +/- 5 ms length-of-day variations exist.
>
> Leap seconds represent the accumulation of these daily residuals:
>
?
> A very small daily residual becomes +/- 9 minute descrepancy
> between TAI and UTC over millennial time periods.  So even in the
> absence of the secular trend, the natural geophysical irascibility
> of the planet is very evident.  Leap seconds - both positive and
> negative, of course - would be needed to resync the clocks.

2006 WP-7A meeting summary

[matsakis . demetrios]

FYI – this was written for
distribution to all interested parties. 

 








WP 7A meeting in Geneva August 28, 2006.doc
Description: MS-Word document

Re: building consensus

[matsakis . demetrios]

The answer to the intial query depends upon what you mean by active.

Ron Beard, Chair of the ITU's Special Rapporteur Group is on the list.
Also Dennis McCarthy, who is Chair of the IAU's Working Group on the Leap
Second.
I am less active, particucularly lately, but have been known to forward some
emails around.

We intentionally try to be silent in this forum.

-Original Message-
From: Leap Seconds Issues
To: LEAPSECS@ROM.USNO.NAVY.MIL
Sent: 06/01/2006 1:37 PM
Subject: Re: [LEAPSECS] building consensus

In message: <[EMAIL PROTECTED]>
Rob Seaman <[EMAIL PROTECTED]> writes:
: Warner Losh objects:
:
: >> There are several doughty people here who happen to have that
: >> opinion, but they abide with us mortals outside the time lords'
: >> hushed inner sanctum.
: >
: > I have spent much time explaining why leap seconds cause real
: > problems in real applications, only to be insulted like this.
:
: Sincere apologies for my awkward statement.  Dictionary.com defines
: "doughty" as "marked by stouthearted courage; brave".  I wasn't
: questioning the knowledge or passion of folks holding views that
: differ from my own.  Rather I was attempting to question whether
: anybody actively participating on this list - holding whatever view -
: is also participating in ITU discussions.
:
: I see that Mr. Cowan has also parsed my admittedly opaque remarks.

Yes.  I'm sorry I was so easily offended.  Please accept my appologies
for my hasty words.

Warner

FW: [LEAPSECS] ABC leapsec article

[matsakis . demetrios]

There is a nifty google feature that will scour the internet for news
articles on any subject, and send you weeky, daily, or immediate
notifications.

Browse on http://www.google.com/alerts

Beware- If you ask for 'leap second' you will get more than you want!

Ask for "leap second", and you will get emails like what is below.

***

From: Google Alerts
To: [EMAIL PROTECTED]
Sent: 11/09/2005 6:08 PM
Subject: Google Alert - "leap second"


Google Alert for: "leap second"


No   more leap
second?
Heise Online - Hannover,Germany
... Telecommunications Union ITU is meeting this Wednesday and Thursday
in Geneva to discuss, among other things, the future of the leap second,
which is added ...





  _

 This once a day Google Alert is brought to you by Google.

Remove   another alert.
Manage   your alerts.

ITU Meeting last year

[matsakis . demetrios]

This is a very brief description of what happened at last October's ITU
meeting in Geneva.

A resolution was proposed to redefine UTC by replacing leap seconds by leap
hours, effective at a specific date which I believe was something like 2020.


This proposal was not passed, but remains under active consideration.
Presumably something like it will be considered next year.  My quick
computation indicates that, should this proposal be adopted, it would take
about a century for UT1-UTC to diverge by one minute, and many centuries
before a leap-hour would be called for.

I did not attend the meeting, and this is all I know.  I was told the ITU
web pages had essentially this same information in them, but could not find
anything there with their search engine.

FW: [IGSMAIL-4679]: upcoming UTC anomaly

[matsakis . demetrios]

-Original Message-
From: Jim Ray [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2003 3:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [IGSMAIL-4679]: upcoming UTC anomaly



**
IGS Electronic Mail  04 Nov 00:20:13 PST 2003  Message Number 4679

**

Author: Jim Ray

FYI, here is my synthesis of reports from a variety of sources
floating around the Internet.

At the end of 27 Nov 2003, exactly 256 weeks will have elapsed since
the last UTC leap second, at the end of 31 Dec 1998.  Because the GPS
week number counter in the UTC subframe data message is only 8 bits
(maximum value of 256), it will reset.  Receivers that do not account
for the truncated GPS week values when determining UTC from GPS time
may report an invalid UTC date.

According to Motorola, their VP Oncore, UT Oncore, GT Oncore, and M12
Oncore receivers (which are widely used for timing applications) will
report the day as 29 Nov instead of 28 Nov for the first second after
the end of 27 Nov 2003.  Afterwards, the correct date will be reported.
See the Motorola announcement at:
  http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf

It is not clear yet which other receivers might be affected.  JPO is
in the process of organizing tests.  My impression, though, is that
the core functions of geodetic receivers are unlikely to notice this
anomaly since they operate in GPS time, which will be unaffected.
Users who rely on the UTC output from any receiver should take heed,
however.

It is highly ironic that this event occurs in the midst of discussions
to change UTC on account of overly frequent leap seconds.

FW: Colloquium on the UTC Timescale, 28-29 May 2003, Turin

[matsakis . demetrios]

-Original Message-
From: Elisabetta Melli [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 5:36 AM
Subject: Colloquium on the UTC Timescale, 28-29 May 2003, Turin


International Telecommunication Union - Special Rapporteur Group 7A
is pleased to organize, in co-operation with Istituto Elettrotecnico
Nazionale Galileo Ferraris,
the Colloquium on the UTC Timescale, which will be held in Turin (Italy) on
28-29 May 2003.

For information about the Meeting, please explore the web site, which will
be regularly updated:
open http://www.ien.it/events/index_i.shtml, then click on
International Telecommunication Union "Colloquium on UTC Timescale",
28-29 maggio 2003, Torino (Italy)

or contact

Dr. William Klepczynski
for additional and technical information,
E-mail:  [EMAIL PROTECTED]
Phone:  +1-410-798-8457
Fax:  +1-410-798-8567

Elisabetta Melli, IEN Galileo Ferraris
as Local Organizing Contact (LOC):
E-mail: [EMAIL PROTECTED]
Phone +39-011-3919 524
Fax  +39-011-34 63 84

Looking forward to meet you in Turin.

Elisabetta Melli
**

Front-running Options for Redefinition of UTC

[matsakis . demetrios]

At the March 20, 2003 meeting of the Timing Subcommittee of the Civil GPS
Interface Committee, Ron Beard gave an update on the ITU/R Special
Rapporteur Group.  The viewgraphs should shortly be publicly available below
http://www.navcen.uscg.gov/cgsic/meetings/default.htm

Of course, the ITU/R Special Rapporteur Group has not come to a decision on
what to recommend, and recommending no change at all is a distinct
possibility.  However, it was indicated that _if_ they decide to recommend a
change then the option they would probably recommend is to replace leap
seconds by leap hours.  It was noted that this could be accommodated by
skipping a daylight time switch.  Any leap-hour would occur many centuries
from now; according to Nelson et al.'s Figure 7 (Metrologia, 2001,
38,509-529), we should only accumulate 140 seconds by 2100.

Presumably all these things will be better clarified at the coming
conference, which will shortly be listed on the USNO web pages but is
already listed as IERS Message No. 40 on http://www.iers.org/news/.

IERS Survey

[matsakis . demetrios]

The summary of a survey conducted by the International Earth Rotation
Service on leap seconds and the redefinition of UTC can be found at
http://hpiers.obspm.fr/eop-pc/earthor/utc/questionnaire/results.htm

Demetrios Matsakis

Re: NASA GMT vs UTC

[matsakis . demetrios]

We received both solicited and unsolicited input from NASA people in both
Washington DC and Pasadena (JPL) in undertaking the 1999 survey that was
charted by URSI commission J.  As stated in our report, we made no effort to
distinguish between URSI members and non-URSI members.

NASA individuals, project managers, or highly-placed officials might chose
to make their requirements known on this issue through the IAU, IERS, URSI,
etc.  If appropriate, they may wish to contact the ITU's Special
Rapporteur's Group directly.

Demetrios Matsakis

-Original Message-
From: Rob Seaman
To: [EMAIL PROTECTED]
Sent: 02/16/2003 10:08 AM
Subject: Re: [LEAPSECS] NASA GMT vs UTC


Are the shadowy folks pushing the dystopian "no new leap seconds"
agenda going to claim that NASA has no standing on this issue?

> That brings up another question - has a leap second ever occurred
> during a NASA mission and did it have any effect on timing?

Re: Forthcoming Meeting of ITU-R SRG Colloquium on UTC Time Scale

[matsakis . demetrios]

My understanding of the consensus for the front-running change option, if
indeed there is to be a change, is that it would be to insert no new leap
seconds after N years, where N is something between five and ten. However
let me make it clear that I am not an organizer of this conference, am not a
member of the ITU Special Rapporteur's Group, and am not planning on being
the US Naval Observatory's attendee at the conference.

If you can't attend the meeting I strongly recommend you make your issues
known through whatever relevant international body best represents you.

My personal official positions with regards to UTC definition are two: I am
chair of the URSI working group and a fairly inactive member of the IAU
working group.  As the manager of this listserv, I of course informally
refer to and summarize the content and flavor of these emails, as
appropriate.  I enjoy doing this, although I admit I was a little concerned
when it appeared possible that one exchange might lead to derogatory
comments between contributors.  Fortunately, that stayed under control
without my having to do anything.

Demetrios

> -Original Message-
> From: Steve Allen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 12, 2003 5:00 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [LEAPSECS] Forthcoming Meeting of ITU-R SRG Colloquium on
> UTC Time Scale
>
>
> On Tue 2003-02-11T16:43:30 -0500,
> [EMAIL PROTECTED] hath writ:
>
> > The SRG has held several coordination and
> > technical exchange meetings to generate,
> > analyze and discuss alternative approaches to
> > reduce or eliminate the operational impact of
> > the leap second. The work to date has
> > produced a consensual opinion that the SRG
> > wants to present and discuss with interested
> > and representative parties.
>
> Is it possible for any of this "consensual opinion" to be revealed in
> advance of the meeting, or must it really be kept a secret until then?
>
> > It does not include a call for papers, but the organizers
> will be soliciting
> > them.  They hope to be able to announce the invited
> speakers and session
> > structure shortly.  The organizers are especially interested in
> > contributions that can quantify the software costs and
> savings associated
> > with any change, particularly the possibility of inserting
> now new leap
> > seconds after N years.
>
> In the absence of a motivating factor (such as knowing that the
> "consensual opinion" will cost them lots of money in the short term)
> it is fantasy to expect that many observatory directors can be
> convinced to send someone to Italy to make a presentation on this.
>
> --
> Steve Allen  UCO/Lick Observatory   Santa Cruz, CA 95064
> [EMAIL PROTECTED]  Voice: +1 831 459 3046
http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93

Forthcoming Meeting of ITU-R SRG Colloquium on UTC Time Scale

[matsakis . demetrios]

Attached is another formal announcement for the coming conference in Turin,
Italy.

It does not include a call for papers, but the organizers will be soliciting
them.  They hope to be able to announce the invited speakers and session
structure shortly.  The organizers are especially interested in
contributions that can quantify the software costs and savings associated
with any change, particularly the possibility of inserting now new leap
seconds after N years.

Below the asterisks there follows an ascii conversion of the attached Word
document.

Demetrios Matsakis

*

Press Release
Preliminary Announcement: Colloquium on the UTC Timescale 28-30 May 2003
Torino (Italy)
Istituto Elettrotecnico Nazionale
"Galileo Ferraris"
Conference Hall
Strada delle Cacce, 91
Torino (Italy)

A Colloquium on the UTC Timescale will be
held at Istituto Elettrotecnico Nazionale Galileo Ferraris
(IEN) in Torino, Italy from 28-30 May 2003.
The purpose of the colloquium is to discuss the
future of the UTC timescale.

As a result of issues raised by sector members of
the ITU-R (International Telecommunication
Union - Radiocommunications) and a letter from
the Director of the Bureau International des Poids
et Mesures (BIPM) to the Secretary General of the
ITU, a new question, ITU-R 236/7 (2000) "The
Future of the UTC Timescale", was generated by
ITU-R Study Group 7 (Science Services) Working
Party 7A (Standard Frequency and Time Signal
Services). The question considers the future
definition and use of Coordinated Universal Time
(UTC) in the ITU-R Recommendations.

Any major change to the UTC timescale as
defined in the current recommendations has a
potentially significant impact on synchronization
of communications networks and navigation
systems and time distribution performance.
Accordingly, Study Group 7 Working Party
7A has established a Special Rapporteur
Group (SRG) to specifically address the future
of the leap second and related issues.
The SRG has held several coordination and
technical exchange meetings to generate,
analyze and discuss alternative approaches to
reduce or eliminate the operational impact of
the leap second. The work to date has
produced a consensual opinion that the SRG
wants to present and discuss with interested
and representative parties.
In support of that purpose the SRG has
organized a concluding Colloquium for
deliberating and drafting a recommendation
to the ITU-R.

Invited presentations will be made by
distinguished representatives in the areas of
International Timekeeping, Navigation,
Earth Rotation, Telecommunications and
Internet Timing. These areas could be
impacted by changes in the UTC Time Scale.
In addition, contributed presentations will be
sought to insure that additional viewpoints
would be expressed.

Additional information can be obtained from
Ron Beard, Chairperson of the SRG
([EMAIL PROTECTED]) and Bill Klepczynski,
Secretary of the SRG ([EMAIL PROTECTED]).

*
General information
Technical Program
Ron Beard, Chairperson of the SRG
E-mail: [EMAIL PROTECTED]
Bill Klepczynski, Secretary of the SRG
E-mail: [EMAIL PROTECTED]
Local Organizing Contact Person
Elisabetta Melli
Istituto Elettrotecnico Nazionale "Galileo Ferraris"
Strada delle Cacce, 91 - 10135 Torino
E-mail: [EMAIL PROTECTED]




ITU-UTC_leaflet.PDF
Description: Adobe PDF document

Re: Draft Questionnaire

[matsakis . demetrios]

This was a useful comment, and I will amend my questionnaire so as to
explicitly ask for an estimate of the effects on any _users_ of URSI systems
as well as on the systems themselves.  Adding this also may bring extra
responses to question 9, which solicits any comment the responder would like
to add.

P.S. I have received so little feedback I was afraid my email hadn't gotten
out.  Please blast away!


> -Original Message-
> From: Seeds, Glen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 17, 2003 5:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [LEAPSECS] Draft Questionnaire
>
>
> The way in which this questionnaire is designed does not collect the
> information that is the basis of a large portion of the
> resistance to this
> proposal: that UTC will no longer reasonably track local time
> in any usable
> way, and this will inconvenience huge numbers of application users (as
> opposed to vendors).
>
> The costs of this are not readily quantifiable, and are not
> tied to specific
> applications. The current UTC mechanism provides for a
> reasonable mapping
> between TAI and local time. The proposal destroys that, and
> therefore brings
> back the problem that UTC was introduced to solve. UTC will become an
> emasculated artifact of history, serving only to clutter the
> universe and
> avoid a switch from UTA to TAI of a number of existing
> applications that
> should have used TAI in the first place.
>
>  /glen
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: January 14, 2003 6:16 PM
> To: [EMAIL PROTECTED]
> Subject: [LEAPSECS] Draft Questionnaire
>
>
> As many of you know, I am the Chair of a Working Group (WG)
> on UTC for the
> International Union of Radio Scientists (URSI).  Several years ago I
> distributed a questionnaire as the chair of a similar
> committee of URSI
> Commission J.
>
> My WG is considering sending the following questionnaire to
> URSI-members.
> The intent is to find out what the true costs would be if UTC
> is redefined
> so that there are no new leap seconds after N years, and what
> the costs
> would be of continuing with the same UTC definition we have
> now.  I would be
> interested in your comments, given the scope of the
> questionnaire and my
> limited charter.
>
> To my knowledge, very few of you are URSI members and
> therefore you will not
> be asked this question by my WG.  However I predict that any
> information
> along the lines of the questionnaire would be received with
> interest by the
> points of contact in any of the other relevant international
> bodies to which
> you may belong.
>
> Demetrios Matsakis
>
> **
> **
> 
> 1.  Name and Position
>
> 2.  Contact information
>
> 3.  URSI Commissions of which you are a member
>
> 4.  If it were decided to change the definition of UTC so
> that no leap
> seconds would be inserted after a specified date, 5 years in
> the future,
> would any extra effort be required to adjust any system you work on?
>
> 5.  If your answer to question 4 is yes, for each system
> affected please
> provide the information in 5a through 5h.   If these estimates are be
> difficult to formulate, you may wish to indicate the range of answers.
> Please feel free to contact a member of the Working Group to
> discuss the
> level of detail to provide so as to best help us represent
> your needs to
> URSI.
>
> a. Name of system
>
> b. Brief description of system
>
> c. Hours of extra labor that would be required and for what
> general purpose,
> such as a software review.
>
> d.  Extra equipment that must be purchased, and
> approximate cost to
> purchase
>
> e.  Extra equipment that must be developed, and approximate cost.
>
> f.  Installation cost of extra equipment
>
> g.  Risks involved in modifying the system.
>
> h.  Costs in terms of system performance or final product once the
> adjustments are correctly made
>
> 6.  If the decision were made to insert no new leap seconds
> as of today,
> please indicate which of your responses to questions and 4
> and 5 would be
> different.
>
> 7. Is there an implementation date that would significantly
> decrease the
> costs indicated in your response to question 5?  If so,
> please provide the
> data and associated costs.
>
> 8.  Please provide the approximate cost to your systems
> of incorporating
> the next leap second, should one be called for in the year 2003.
>
> a.  Hours of labor
> b.  Equipment purchase
> c.  Probability that leap second will not be correctly
> adjusted for
> d.  Costs in terms of final product or system performance
> if the leap
> second is not correctly included
> e.  Costs in terms of final product or system performance
> even if the
> leap second is correctly allowed for.
>
> 9. Please use this space to make any comments or provide any
> information you
> feel appropriate.
>
>

Draft Questionnaire

[matsakis . demetrios]

As many of you know, I am the Chair of a Working Group (WG) on UTC for the
International Union of Radio Scientists (URSI).  Several years ago I
distributed a questionnaire as the chair of a similar committee of URSI
Commission J.

My WG is considering sending the following questionnaire to URSI-members.
The intent is to find out what the true costs would be if UTC is redefined
so that there are no new leap seconds after N years, and what the costs
would be of continuing with the same UTC definition we have now.  I would be
interested in your comments, given the scope of the questionnaire and my
limited charter.

To my knowledge, very few of you are URSI members and therefore you will not
be asked this question by my WG.  However I predict that any information
along the lines of the questionnaire would be received with interest by the
points of contact in any of the other relevant international bodies to which
you may belong.

Demetrios Matsakis



1.  Name and Position

2.  Contact information

3.  URSI Commissions of which you are a member

4.  If it were decided to change the definition of UTC so that no leap
seconds would be inserted after a specified date, 5 years in the future,
would any extra effort be required to adjust any system you work on?

5.  If your answer to question 4 is yes, for each system affected please
provide the information in 5a through 5h.   If these estimates are be
difficult to formulate, you may wish to indicate the range of answers.
Please feel free to contact a member of the Working Group to discuss the
level of detail to provide so as to best help us represent your needs to
URSI.

a. Name of system

b. Brief description of system

c. Hours of extra labor that would be required and for what general purpose,
such as a software review.

d.  Extra equipment that must be purchased, and approximate cost to
purchase

e.  Extra equipment that must be developed, and approximate cost.

f.  Installation cost of extra equipment

g.  Risks involved in modifying the system.

h.  Costs in terms of system performance or final product once the
adjustments are correctly made

6.  If the decision were made to insert no new leap seconds as of today,
please indicate which of your responses to questions and 4 and 5 would be
different.

7. Is there an implementation date that would significantly decrease the
costs indicated in your response to question 5?  If so, please provide the
data and associated costs.

8.  Please provide the approximate cost to your systems of incorporating
the next leap second, should one be called for in the year 2003.

a.  Hours of labor
b.  Equipment purchase
c.  Probability that leap second will not be correctly adjusted for
d.  Costs in terms of final product or system performance if the leap
second is not correctly included
e.  Costs in terms of final product or system performance even if the
leap second is correctly allowed for.

9. Please use this space to make any comments or provide any information you
feel appropriate.

10. It is possible that we would like to publicly identify your system(s) as
relevant to the decision.  In that case, do we have your permission to fully
quote your reply?

[LEAPSECS] Official Announcement of Conference on UTC Timescale

[matsakis . demetrios]

This email has two 
attachments, giving the official meeting announcement and the meeting's draft 
agenda in Word format.

 
Immediate below this message are plain-ascii versions 
of the two attachments, separated by asterisks.
 
The two sections of text after those, again separated 
by asterisks,  are "copy and paste" versions of the same two 
attachments.  These have special characters that could confuse some 
email-reading software.
 
I 
would encourage those of you who feel strongly on this issue to attend the 
meeting. 
- 
Demetrios Matsakis
P.S. Our listserv system 
has once again exhibited a mysterious flaw in which contributory emails are not 
received.  The solution was to restart the server.  If you have 
attempted to email anything to leapsecs in the last few weeks, please 
resend.  If you continue to experience troubles, please contact me directly 
at [EMAIL PROTECTED].
 
**
Press Release
A Colloquium on the UTC Timescale will be held at Istituto 
Elettrotecnico Nazionale G. 
Ferraris (IEN) in Torino, Italy from 28-30 May 2003. The purpose 
of the colloquium is to 
discuss the future of the UTC timescale.
As a result of issues raised by sector members of the ITU-R and 
a letter from the Director of the 
Bureau International des Poids et Mesures (BIPM) to the 
Secretary General of the ITU, a new 
question, ITU-R 236/7 (2000) "The Future of the UTC Timescale", 
was generated by ITU-R 
Study Group 7 (Science Services) Working Party 7A (Standard 
Frequency and Time Signal 
Services). The question considers the future definition and use 
of Coordinated Universal Time 
(UTC) in the ITU-R Recommendations.
Any major change to the UTC timescale as defined in the current 
recommendations has a 
potentially significant impact on synchronization of 
communications networks and navigation 
systems and time distribution performance. Accordingly, Study 
Group 7 Working Party 7A has 
established a Special Rapporteur Group (SRG) to specifically 
address the future of the leap 
second and related issues.
The SRG has held several coordination and technical exchange 
meetings to generate, analyze 
and discuss alternative approaches to reduce or eliminate the 
operational impact of the leap 
second. The work to date has produced a consensual opinion that 
the SRG wants to present and 
discuss with interested and representative parties. In support 
of that purpose the SRG has 
organized a concluding Colloquium for deliberating and drafting 
a recommendation to the ITU-
R. 
Invited presentations will be made by distinguished 
representatives in the areas of International 
Timekeeping, Navigation, Earth Rotation, Telecommunications and 
Internet Timing. These 
areas could be impacted by changes in the UTC Time Scale. In 
addition, contributed 
presentations will be sought to insure that additional 
viewpoints would be expressed.
Additional information can be obtained from Ron Beard, 
Chairperson of the SRG 
([EMAIL PROTECTED]) and Bill Klepczynski, Secretary of 
the SRG 
([EMAIL PROTECTED]).
Press Release January 3, 2003 Press Release
***
ITU-R Special Rapporteur Group (SRG) 
Colloquium on the UTC Time Scale
Istituto Elettrotecnico Nazionale G Ferraris (IEN)
Torino, Italy
28-30 May 2003
Introduction/Purpose
As a result of issues raised by sector members and a letter from the Director 
of the Bureau 
International des Poids et Mesures (BIPM) to the Secretary General of the 
ITU, a new question, 
ITU-R 236/7 (2000) "The Future of the UTC Timescale", was generated by ITU-R 
Study Group 
7 (Science Services) Working Party 7A (Standard Frequency and Time Signal 
Services). The 
question considers the future definition and use of Coordinated Universal 
Time (UTC) in the 
ITU-R Recommendations.
Any major change to the UTC timescale as defined in the current 
recommendations has a 
potentially significant impact on network synchronization and time 
distribution performance. 
Accordingly, Study Group 7 Working Party 7A has established a Special 
Rapporteur Group 
(SRG) to specifically address the future of the leap second and related 
issues.
The SRG has held several coordination and technical exchange meetings to 
generate, analyze 
and discuss alternative approaches to reduce or eliminate the operational 
impact of the leap 
second. The work to date has produced within the SRG a consensual opinion 
that the SRG 
wishes to present and discuss with representative parties of the scientific, 
standards and 
telecommunications agencies and groups. For that purpose the SRG is 
organizing a Colloquium 
for deliberating recommendations to the ITU-R. 
Invited presentations will be made by distinguished representatives in areas 
that could be 
impacted by changes i