From Markus.Kuhn at cl.cam.ac.uk  Tue Dec  2 10:43:55 2008
From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn)
Date: Tue, 02 Dec 2008 15:43:55 +0000
Subject: [LEAPSECS] Leap seconds in the news
Message-ID: <20081202154355.9432653EAE@viterbi.cl.cam.ac.uk>

If you keep track of leap seconds in the media or want to see
Dennis McCarthy and the US master clocks on TV:

  http://news.bbc.co.uk/1/hi/magazine/7759281.stm

Markus


From seaman at noao.edu  Tue Dec  9 12:27:50 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 9 Dec 2008 10:27:50 -0700
Subject: [LEAPSECS] comp.risks post in need of response
Message-ID: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>

Anybody want to volunteer to take a wack at setting the nice folks at  
the Risks Digest straight regarding a timekeeping issue?

	http://catless.ncl.ac.uk/Risks/25.47.html#subj12

I'm sure someone from any of our various philosophical encampments  
would do a fine job of telling them why "NominalDiffTime" is a silly  
idea.  If only the claim were true, however:

	"If you don't care about leap seconds, use UTCTime and  
NominalDiffTime for your clock calculations, and you'll be fine."

Certainly nobody who does need to recover accurate UT1 from civil time  
is going to trust this library.

Rob Seaman
NOAO


From imp at bsdimp.com  Tue Dec  9 12:50:17 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 09 Dec 2008 10:50:17 -0700 (MST)
Subject: [LEAPSECS] comp.risks post in need of response
In-Reply-To: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
References: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
Message-ID: <20081209.105017.87762384.imp@bsdimp.com>

In message: <B2C1F790-303D-4E34-BB66-F8E7B4319D00 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Anybody want to volunteer to take a wack at setting the nice folks at  
: the Risks Digest straight regarding a timekeeping issue?
: 
: 	http://catless.ncl.ac.uk/Risks/25.47.html#subj12
: 
: I'm sure someone from any of our various philosophical encampments  
: would do a fine job of telling them why "NominalDiffTime" is a silly  
: idea.  If only the claim were true, however:
: 
: 	"If you don't care about leap seconds, use UTCTime and  
: NominalDiffTime for your clock calculations, and you'll be fine."
: 
: Certainly nobody who does need to recover accurate UT1 from civil time  
: is going to trust this library.

You can't recover UT1 from Civil Time.

Before you crawl my case for that statement, let me explain.

First, if you need to know UT1, you have to get it from somewhere on
the net.  It isn't broadcast in any meaningful way today (.1s isn't
meaningful).

Second, if you are doing real time thing where UT1 is important,
you'll need some source of timing signals to do the real time thing
you need to do.  In that case, you are getting time directly from GPS
or some other form of time exchange.

If you are going to that level of effort, then you already know the
difference in the different time scales.

Warner

From seaman at noao.edu  Tue Dec  9 15:14:40 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 9 Dec 2008 13:14:40 -0700
Subject: [LEAPSECS] comp.risks post in need of response
In-Reply-To: <20081209.105017.87762384.imp@bsdimp.com>
References: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
	<20081209.105017.87762384.imp@bsdimp.com>
Message-ID: <5209FD50-937F-42CA-9B24-B499DB31A559@noao.edu>

Our (familiar) views are rather orthogonal to the comp.risks assertions.
--

On Dec 9, 2008, at 10:50 AM, M. Warner Losh wrote:

> In message: <B2C1F790-303D-4E34-BB66-F8E7B4319D00 at noao.edu>
>            Rob Seaman <seaman at noao.edu> writes:
> : Anybody want to volunteer to take a wack at setting the nice folks  
> at
> : the Risks Digest straight regarding a timekeeping issue?
> :
> : 	http://catless.ncl.ac.uk/Risks/25.47.html#subj12
> :
> : I'm sure someone from any of our various philosophical encampments
> : would do a fine job of telling them why "NominalDiffTime" is a silly
> : idea.  If only the claim were true, however:
> :
> : 	"If you don't care about leap seconds, use UTCTime and
> : NominalDiffTime for your clock calculations, and you'll be fine."
> :
> : Certainly nobody who does need to recover accurate UT1 from civil  
> time
> : is going to trust this library.
>
> You can't recover UT1 from Civil Time.
>
> Before you crawl my case for that statement, let me explain.
>
> First, if you need to know UT1, you have to get it from somewhere on
> the net.  It isn't broadcast in any meaningful way today (.1s isn't
> meaningful).
>
> Second, if you are doing real time thing where UT1 is important,
> you'll need some source of timing signals to do the real time thing
> you need to do.  In that case, you are getting time directly from GPS
> or some other form of time exchange.
>
> If you are going to that level of effort, then you already know the
> difference in the different time scales.
>
> Warner


From cowan at ccil.org  Tue Dec  9 17:22:37 2008
From: cowan at ccil.org (John Cowan)
Date: Tue, 9 Dec 2008 17:22:37 -0500
Subject: [LEAPSECS] comp.risks post in need of response
In-Reply-To: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
References: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
Message-ID: <20081209222237.GI3472@mercury.ccil.org>

Rob Seaman scripsit:

> I'm sure someone from any of our various philosophical encampments  
> would do a fine job of telling them why "NominalDiffTime" is a silly  
> idea.  If only the claim were true, however:
> 
> 	"If you don't care about leap seconds, use UTCTime and  
> NominalDiffTime for your clock calculations, and you'll be fine."

The library does not at all do what you think it does.  It provides two
parallel representations of time.  The first, UniversalTime, is intended
to represent UT-style timescales, and is implemented using a fractional
MJD date with arbitrary precision.  (N.B.: I do not say, with arbitrary
accuracy: in practice, the implementation is hardly likely to be able
to learn the current time in UT1 with accuracy better than 0.9s,
the maximum value of DUT.  Consequently, you'd need a supplementary
source of DUT to get UT1 more accurately than that.)  Corresponding to
UniversalTime as a moment of time, there is DiffTime as a duration of
time, represented with a precision of 1 ps.

The second is intended to represent UTC, and is implemented using a
integral MJD date and a DiffTime representing between 0 and 86401 seconds
inclusive, with a fixed precision of 1 ps.  (Providing both 0 and 86401
is presumably to allow the representation of both 00h00 and 24h00.)
Corresponding to this representation of UTC moments is NominalDiffTime,
a representation of UTC durations ignoring leap seconds: this also
has a fixed precision of 1 ps.  If you had a list of leap seconds,
you could calculate the accurate DiffTime between two UTCTimes as well
as two UniversalTimes, but the underlying system does not, in general,
have such a list, so the library doesn't provide this function.

> Certainly nobody who does need to recover accurate UT1 from civil time  
> is going to trust this library.

But if you have accurate UT1, you can use the library to represent it.

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.ccil.org/~cowan
but it pours?                                   cowan at ccil.org
        --Rufus T. Firefly

From ashley at semantic.org  Tue Dec  9 23:02:45 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Tue, 09 Dec 2008 20:02:45 -0800
Subject: [LEAPSECS] comp.risks post in need of response
In-Reply-To: <20081209222237.GI3472@mercury.ccil.org>
References: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
	<20081209222237.GI3472@mercury.ccil.org>
Message-ID: <1228881765.28254.24.camel@glastonbury>

On Tue, 2008-12-09 at 17:22 -0500, John Cowan wrote:
> The library does not at all do what you think it does.

Thank you, yes, this is all largely correct.

> Corresponding to
> UniversalTime as a moment of time, there is DiffTime as a duration of
> time, represented with a precision of 1 ps.

Just to clarify, DiffTime represents relative clock time, i.e. the
difference between two AbsoluteTimes, and not the difference between two
UniversalTimes.

> The second is intended to represent UTC, and is implemented using a
> integral MJD date and a DiffTime representing between 0 and 86401 seconds
> inclusive, with a fixed precision of 1 ps.

It's supposed to be exclusive of 86401s. But actually the library
doesn't stop you entering any DiffTime at all, and calculations
involving NominalDiffTime will clip any time beyond 86400s.

You can see the other modules in the library here:
http://haskell.org/ghc/docs/latest/html/libraries/time/

I was considering creating a "tz" or "zoneinfo" library, that would be
able to provide the available leap-second table, but I haven't got
around to it.

-- 
Ashley Yakeley


From seaman at noao.edu  Wed Dec 10 10:25:49 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 10 Dec 2008 08:25:49 -0700
Subject: [LEAPSECS] comp.risks post in need of response
In-Reply-To: <1228881765.28254.24.camel@glastonbury>
References: <B2C1F790-303D-4E34-BB66-F8E7B4319D00@noao.edu>
	<20081209222237.GI3472@mercury.ccil.org>
	<1228881765.28254.24.camel@glastonbury>
Message-ID: <74D88E59-7B66-49FD-8729-C7B70ACEA0EB@noao.edu>

John Cowan wrote:

> The library does not at all do what you think it does.

You are right, of course.

My apologies to Ashley Yakeley.

Rob


From dan at tobias.name  Wed Dec 10 23:44:36 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Wed, 10 Dec 2008 23:44:36 -0500
Subject: [LEAPSECS] Stephen Colbert and the Leap Second
Message-ID: <49405464.4657.A397044@dan.tobias.name>

On tonight's Colbert Report, Stephen Colbert rated the upcoming leap 
second as one of the "threats" to itemize, saying that 2008 sucked so 
badly that it's a bad idea to make it any longer, and he's also 
planned every second of the year in a Page A Second planner book, so 
the extra second messes up his schedule.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From phk at phk.freebsd.dk  Fri Dec 12 10:44:26 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Dec 2008 15:44:26 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
Message-ID: <10832.1229096666@critter.freebsd.dk>


As part of some research on a different topic, I came across a
summary of the 1980 plenary meeting of CCITT, where appearantly the
CCITT formally decided to switch from GMT to UTC.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From imp at bsdimp.com  Fri Dec 12 11:18:47 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri, 12 Dec 2008 09:18:47 -0700 (MST)
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <10832.1229096666@critter.freebsd.dk>
References: <10832.1229096666@critter.freebsd.dk>
Message-ID: <20081212.091847.-653353160.imp@bsdimp.com>

In message: <10832.1229096666 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: 
: As part of some research on a different topic, I came across a
: summary of the 1980 plenary meeting of CCITT, where appearantly the
: CCITT formally decided to switch from GMT to UTC.

that would make interesting reading.  Is it available?

Warner

From phk at phk.freebsd.dk  Fri Dec 12 13:24:41 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Dec 2008 18:24:41 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: Your message of "Fri, 12 Dec 2008 09:18:47 MST."
	<20081212.091847.-653353160.imp@bsdimp.com> 
Message-ID: <11893.1229106281@critter.freebsd.dk>

In message <20081212.091847.-653353160.imp at bsdimp.com>, "M. Warner Losh" writes
:
>In message: <10832.1229096666 at critter.freebsd.dk>
>            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>: 
>: As part of some research on a different topic, I came across a
>: summary of the 1980 plenary meeting of CCITT, where appearantly the
>: CCITT formally decided to switch from GMT to UTC.
>
>that would make interesting reading.  Is it available?

I checked and I think this may be referring to CCITT recommendation
B.11:


	Recommendation B.11
	Fascicle I.3 - Rec. B.11
	LEGAL TIME; USE OF THE TERM UTC
	(Geneva, 1980)

	The CCITT,

	considering

	(a)     that according to CCIR Recommendation 460-3 all
		standard-frequency and time-signal emissions should conform
		to Coordinated Universal Time (UTC);
	(b)     that since 1972 UTC has been available as a worldwide
		time reference;
	(c)     that in 1975 the General Conference of Weights and
		Measures (CGPM) recommended the use of UTC as the basis of
		civil time;
	(d)     that other scientific organizations, particularly
		the International Astronomical Union (IAU) and the International
		Union of Radio Science (URSI) have recommended the general
		use of UTC;
	(e)      that UTC enables the time of events to be determined
		with an uncertainty of 1 ?s;
	(f)     that according to CCIR Recommendation 536 and in
		accordance with the Recommendation of the General Conference
		of Weights and Measures the designation UTC is to be used
		in all languages;
	(g)     that the World Administrative Radio Conference
		(Geneva, 1979) has decided that UTC shall be used in
		international radiocommunication activities;
	(h)     that in accordance with Appendix 2 to the Telegraph
		and Telephone Regulations, Geneva, 1973 (relating to
		reciprocal exchange of information through the medium of
		the General Secretariat) Resolution No. 1 of these Regulations
		recommends Administrations inter alia to inform the
		Secretary-General of the legal time they apply.

	unanimously recommends

	that UTC should be used to designate the time in all other
	international telecommunication activities (including
	operational information) and in all service documents of
	the International Telecommunication Union.


None of that is really interesting, except the very late date...

Poul-Henning

PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds,
anybody here who can verify if this is really the original text ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dot at dotat.at  Fri Dec 12 14:09:00 2008
From: dot at dotat.at (Tony Finch)
Date: Fri, 12 Dec 2008 19:09:00 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <11893.1229106281@critter.freebsd.dk>
References: <11893.1229106281@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0812121835130.9624@hermes-1.csi.cam.ac.uk>

On Fri, 12 Dec 2008, Poul-Henning Kamp wrote:
>
> PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds,
> anybody here who can verify if this is really the original text ?

ISO 8601-2004 cites ISO 31-1, and specifies several meanings for "day",
one of which is equivalent to 86400 seconds.

The ISO web site says that ISO 31 has been withdrawn and replaced by ISO
80000 (published in 2006). ISO 31-1 and -2 are replaced by ISO 80000-3.

quote from ISO 8601-2004 ...

2.2 Time units, nominal durations and time intervals

2.2.1 second

base unit of measurement of time in the International System of Units (SI)
as defined by the International Committee of Weights and Measures (CIPM,
i.e. Comite' International des Poids et Mesures)

NOTE 1 See also ISO 31-1.
NOTE 2 It is the base unit for expressing duration.

2.2.2 leap second

intentional time step of one second to adjust UTC to ensure appropriate
agreement with UT1, a time scale based on the rotation of the Earth
[Rec. ITU-R TF.460-5]

NOTE An inserted second is called positive leap second and an omitted
second is called negative leap second. A positive leap second is inserted
between [23:59:59Z] and [24:00:00Z] and can be represented as [23:59:60Z].
Negative leap seconds are achieved by the omission of [23:59:59Z].
Insertion or omission takes place as determined by IERS, normally on 30
June or 31 December, but if necessary on 31 March or 30 September.

2.2.3 minute

unit of time, equal to 60 seconds [ISO 31-1]

2.2.4 hour

unit of time, equal to 60 minutes [ISO 31-1]

2.2.5 day

unit of time unit of time, equal to 24 hours [ISO 31-1]

2.2.6 calendar day

time interval starting at midnight and ending at the next midnight, the
latter being also the starting instant of the next calendar day

NOTE 1 A calendar day is often also referred to as day.

NOTE 2 The duration of a calendar day is 24 hours; except if modified by:
-- the insertion or deletion of leap seconds, by decision of the
International Earth Rotation Service (IERS), or
-- the insertion or deletion of other time intervals, as may be prescribed
by local authorities to alter the time scale of local time.

2.2.7 day

duration duration of a calendar day

NOTE The term "day" applies also to the duration of any time interval
which starts at a certain time of day at a certain calendar day and ends
at the same time of day at the next calendar day.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTHEAST ICELAND: NORTHERLY OR NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 AT
FIRST. VERY ROUGH OR HIGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD.

From phk at phk.freebsd.dk  Fri Dec 12 14:47:31 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 12 Dec 2008 19:47:31 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: Your message of "Fri, 12 Dec 2008 19:09:00 GMT."
	<alpine.LSU.2.00.0812121835130.9624@hermes-1.csi.cam.ac.uk> 
Message-ID: <12347.1229111251@critter.freebsd.dk>

In message <alpine.LSU.2.00.0812121835130.9624 at hermes-1.csi.cam.ac.uk>, Tony Fi
nch writes:

>ISO 8601-2004 cites ISO 31-1, and specifies several meanings for "day",
>one of which is equivalent to 86400 seconds.

Wonderful confusion.

It is insteresting that the militant 86400 second definition of
ISO-31-1 only got superseeded once somebody tried to make UTC
compliant with it :-)

But if nothing else, it underscores how little attention people
have paid to leap seconds...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From tvb at LeapSecond.com  Fri Dec 12 15:03:12 2008
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Fri, 12 Dec 2008 12:03:12 -0800
Subject: [LEAPSECS] Footnote about CCITT and UTC
References: <12347.1229111251@critter.freebsd.dk>
Message-ID: <C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>

> Wonderful confusion.
> 
> It is insteresting that the militant 86400 second definition of
> ISO-31-1 only got superseeded once somebody tried to make UTC
> compliant with it :-)
> 
> But if nothing else, it underscores how little attention people
> have paid to leap seconds...

It's hard to know how much or little attention without a baseline.
Does anyone know much time ISO spends defining leap days,
or does everyone just take them for granted? Is there official
text on the definition.

Another interesting point, based on press clippings alone, it would
seem leap seconds get as much or more press as leap days. It
appears that DST often generates grumbling but never a revolt,
leap seconds a yawn or wink from the general public (except for
those few of us who cringe), and leap days no argument at all
from anyone.

/tvb



From dwmalone at maths.tcd.ie  Fri Dec 12 16:50:58 2008
From: dwmalone at maths.tcd.ie (David Malone)
Date: Fri, 12 Dec 2008 21:50:58 +0000
Subject: [LEAPSECS] Two leap second papers
Message-ID: <200812122150.aa24479@walton.maths.tcd.ie>

These two papers, both from the November issue of The Astronomy
Journal, may be of interest to people here. The articles are not
(yet?) freely available, but I guess many academic libraries would
have access:

	THE PHYSICAL BASIS OF THE LEAP SECOND
	Dennis D. McCarthy et al 2008 The Astronomical Journal 136 1906-1908
	http://www.iop.org/EJ/abstract/1538-3881/136/5/1906

and:

	DOES RELATIVISTIC TIME DILATION CONTRIBUTE TO THE DIVERGENCE OF UNIVERSAL TIME AND EPHEMERIS TIME?
	G??rard Petit et al 2008 The Astronomical Journal 136 1909-1912
	http://www.iop.org/EJ/abstract/1538-3881/136/5/1909

Both are in response to a 2007 paper attributing leap seconds to
general relativistic effects rather than geophysical and tidal
effects.

	David.

From zefram at fysh.org  Fri Dec 12 17:24:09 2008
From: zefram at fysh.org (Zefram)
Date: Fri, 12 Dec 2008 22:24:09 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <11893.1229106281@critter.freebsd.dk>
References: <20081212.091847.-653353160.imp@bsdimp.com>
	<11893.1229106281@critter.freebsd.dk>
Message-ID: <20081212222409.GB2263@fysh.org>

Poul-Henning Kamp wrote:
>PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds,
>anybody here who can verify if this is really the original text ?

Yes.  ISO 31-1:1992(E) lists the following as units of time "which may
be used together with SI units because of their practical importance or
because of their use in specialized fields":

	NAME      INTERNATIONAL
	OF UNIT   SYMBOL FOR UNIT   DEFINITION
	minute    min               1 min = 60 s
	hour      h                 1 h = 60 min = 3 600 s
	day       d                 1 d = 24 h = 86 400 s

This is of course defining a *unit of measurement* called "day", not
a calendar unit.  Likewise the hour and minute.  To be such, they are
necessarily constant quantities.  Calendar units have no such inherent
constraint.

I understand that astronomers similarly define a unit of time called
"year", symbol "a", with value exactly 365.25 d = 31 557 600 s.  (This is
based on the mean Julian year.)  This unit is not mentioned in ISO 31-1.
The standard does mention the tropical year, as a unit of no status
(listed for information only), but of course that's a different quantity
with no such exact definition.  It also lists (for information only)
the light year, giving an approximate value that is sufficiently precise
to show that it is based on the 365.25 d year rather than any other year.

There is a problem with the symbol "d" for day: it means that the
centiday (a very useful unit) clashes with the candela for the symbol
"cd".  SI itself avoids such clashes, and I'm slightly surprised to see
ISO endorse these symbols without comment.

-zefram

From zefram at fysh.org  Fri Dec 12 17:34:04 2008
From: zefram at fysh.org (Zefram)
Date: Fri, 12 Dec 2008 22:34:04 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>
References: <12347.1229111251@critter.freebsd.dk>
	<C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>
Message-ID: <20081212223404.GC2263@fysh.org>

Tom Van Baak wrote:
>Does anyone know much time ISO spends defining leap days,
>or does everyone just take them for granted? Is there official
>text on the definition.

ISO 8601 fully defines the Gregorian calendar, including the complete
leap day rule.  It says relatively little about leap seconds and UTC.
The attitude of the standard is that leap days are an inherent part of the
Gregorian-based date formats, but leap seconds are merely a peculiarity
of one of many possible ways to count time of day.  It's neutral about
whether and when leap seconds may occur: that's an application issue.
The timezone designators are specifically described as being relative
to UTC, but it is more consistent with the rest of the standard to treat
that mention of UTC as actually referring to vague UT.

-zefram

From seaman at noao.edu  Fri Dec 12 19:26:36 2008
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 12 Dec 2008 17:26:36 -0700
Subject: [LEAPSECS] Two leap second papers
In-Reply-To: <200812122150.aa24479@walton.maths.tcd.ie>
References: <200812122150.aa24479@walton.maths.tcd.ie>
Message-ID: <33E3307A-3C78-4B23-912C-EE47A6B27630@noao.edu>

David Malone wrote:

> These two papers, both from the November issue of The Astronomy  
> Journal, may be of interest to people here.

> 	DOES RELATIVISTIC TIME DILATION CONTRIBUTE TO THE DIVERGENCE OF  
> UNIVERSAL TIME AND EPHEMERIS TIME?
> 	G?rard Petit et al 2008 The Astronomical Journal 136 1909-1912
> 	http://www.iop.org/EJ/abstract/1538-3881/136/5/1909
>
> Both are in response to a 2007 paper attributing leap seconds to  
> general relativistic effects rather than geophysical and tidal  
> effects.

This one was posted on my door for a couple of weeks.  I've never read  
a more pointed refutation of a refereed paper.  A wonderful example of  
the self correcting nature of scientific discourse.

The real question is how the original paper made it past the referees  
and the editor in the first place.  It was absolute hooey.

Rob


From dot at dotat.at  Sun Dec 14 15:00:53 2008
From: dot at dotat.at (Tony Finch)
Date: Sun, 14 Dec 2008 20:00:53 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <20081212223404.GC2263@fysh.org>
References: <12347.1229111251@critter.freebsd.dk>
	<C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>
	<20081212223404.GC2263@fysh.org>
Message-ID: <alpine.LSU.2.00.0812141958050.17486@hermes-1.csi.cam.ac.uk>

On Fri, 12 Dec 2008, Zefram wrote:
>
> [ISO 8601 is] neutral about whether and when leap seconds may occur:
> that's an application issue. The timezone designators are specifically
> described as being relative to UTC, but it is more consistent with the
> rest of the standard to treat that mention of UTC as actually referring
> to vague UT.

I can't see anything in ISO 8601-2000 or -2004 that supports "vague UT".
Both versions of the standard are quite specific about times of day being
UTC or at a specific offset from UTC.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
LUNDY FASTNET IRISH SEA: NORTH BACKING WEST OR SOUTHWEST 3 OR 4, BUT 5 TO 7 AT
FIRST IN LUNDY AND FASTNET, OCCASIONALLY 5 LATER IN IRISH SEA. SLIGHT IN IRISH
SEA, OTHERWISE MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN FASTNET. SHOWERS.
MODERATE OR GOOD.

From zefram at fysh.org  Sun Dec 14 16:57:55 2008
From: zefram at fysh.org (Zefram)
Date: Sun, 14 Dec 2008 21:57:55 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <alpine.LSU.2.00.0812141958050.17486@hermes-1.csi.cam.ac.uk>
References: <12347.1229111251@critter.freebsd.dk>
	<C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>
	<20081212223404.GC2263@fysh.org>
	<alpine.LSU.2.00.0812141958050.17486@hermes-1.csi.cam.ac.uk>
Message-ID: <20081214215755.GE2263@fysh.org>

Tony Finch wrote:
>I can't see anything in ISO 8601-2000 or -2004 that supports "vague UT".
>Both versions of the standard are quite specific about times of day being
>UTC or at a specific offset from UTC.

Quoting from ISO 8601:2004(E).  Start with the most fundamental
definition, section 2.1.1:

	*time axis*

	mathematical representation of the succession in time of
	instantaneous events along a unique axis

The time axis, for the purposes of the standard, does not need to
correspond to the physical proper time of any reference frame, nor to
a best-effort realisation of such an axis.  Section 2.1.4:

	*time scale*

	system of ordered marks which can be attributed to instants on
	the time axis, one instant being chosen as the origin

These marks are not required to correspond linearly to physical proper
time.  Indeed, there are no particular restrictions on the marks.
This is made clear in the next part of the same section:

	NOTE 1  A time scale may amongst others be chosen as:

	-- continuous, e.g. international atomic time (TAI) (see IEC
	   60050-713, item 713-05-18);

	-- continuous with discontinuities, e.g. Coordinated Universal
	   Time (UTC) due to leap seconds, standard time due to summer
	   time and winter time;

	...

I don't want to get into the debate about whether a leap second
constitutes a discontinuity, but it's clear that this is a fairly broad
concept of time scale.

Now, look at the scope of the time-of-day formats.  Section 4.2.1:

	This International Standard is based on the 24-hour timekeeping
	system that is now in common use.

This, the primary statement of how the standard approaches time of day,
is about how the time of day is expressed.  It does not indicate any
concern about which time scale defines those hours.  At the end of the
same section:

	NOTE  These expressions apply to both UTC and non-UTC based time
	scales for time of day.

This seems to be the crucial bit that you missed.  It's explicit about
allowing time scales other than UTC, and doesn't restrict the choice
of time scale at all.  UT1, with strict 86400-second days, is obviously
permitted, and I suggest that vague UT per se is also a valid time scale.

Section 4.2.2.1:

	In the representations of local time as defined below no
	provisions have been made to prevent ambiguities in expressions
	that result from discontinuities in the time scale of local time
	(e.g. daylight saving time).

That is, local time is a type of time scale.  A particular local
time may be a time scale with discontinuities, and in particular gross
discontinuities.  This is consistent with the definition in section 2.1.4.
Furthermore, putting these last two together, it is strongly implied
that a local time scale does not need to be based on UTC.  This is made
explicit by the definition in section 2.1.16:

	*local time*

	locally applicable time of day such as standard time of day,
	or a non-UTC based time of day

You're permitted to represent, for example, the mean-solar-time-based
British legal time in ISO 8601.

The parts that are specific about using UTC and offsets therefrom begin
with the definition in section 2.1.14:

	*standard time*

	time scale derived from coordinated universal time, UTC, by a time
	shift established in a given location by the competent authority

This is not defining local time per se, but "standard time", which is
evidently a subtype of local time.  The definition of "local time",
quoted above, is actually referring to this definition to indicate a
permitted type of local time.  (You might have noticed inconsistent
capitalisation of the full name of UTC.  This is as in the standard.)

Section 4.2.5 ("Local time and Coordinated Universal Time (UTC)")
is about representing the difference between local time and UTC.
It doesn't actually use the term "standard time", but clearly for the
difference to be exact the local time must be a standard time as defined
in section 2.1.4.

The other representation that is defined specifically by reference to
UTC is in section 4.2.4 ("UTC of day").  This is about the use of "Z"
to tag a time-of-day as being on the UTC time scale.

So, if we follow the standard as written, I can validly (in ISO
8601) state that the BST (British Summer Time, = GMT + 1h) time is
"22:32:12.123", but I can't write it as "22:32:12.123+01:00" or describe
BST as "+01:00".  The offset from UTC to BST is not exactly one hour,
but some constantly-changing value that is best determined by the IERS.
Likewise, I can write the GMT time, which is the legal time in Britain,
as "21:32:12.123", but not as "21:32:12.123Z", because GMT is not
precisely UTC.  (I'm using "GMT" in the strict sense here, of course.)

Unfortunately ISO 8601 does not supply any way to designate UT1 or any
other flavour of UT except UTC.  Thus, strictly speaking, there is no
way to designate any local time that is based on UT1 rather than UTC.
As we know from previous discussions on this list, there are quite a few
such time scales with current legislative endorsement.  (And a few that
can't decide which they're based on.)

It seems to me that the standard would be rather more useful if "standard
time" were defined more according to its original meaning: a local time
scale defined by an offset from UT, rather than specifically from UTC.
The timezone designation material should correspondingly refer to UT
rather than UTC, and the "Z" should probably follow by designating UT.
All of these would be explicitly vague as to which flavour of UT is
being referred to.

With this change, UTC-based and UT1-based local time scales are both
subtypes of standard time, and both can be described to equivalent
precision using the standard timezone designators.  It is true that
the timezone designators would lose their current notional sub-second
precision, but it seems more important to be able to describe the
grosser features of a local time scale first.  Possibly there should
be an additional type of designator, added to the standard, to identify
flavours of UT.

In the last three paragraphs above I'm playing Fantasy Standards.
But actually in practice the timezone designators *do* get used to
describe relations to UT1 and vague UT, not just UTC.  So the change that
I propose would not only make the standard formally more applicable but
also bring the theory and practice closer together.

-zefram

From seaman at noao.edu  Sun Dec 14 20:44:10 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 14 Dec 2008 18:44:10 -0700
Subject: [LEAPSECS] Fwd: Pete Bunclark
References: <9C943FEC-4DFE-4EFA-AA29-889B8C62B5DD@cacr.caltech.edu>
Message-ID: <BC6F387D-7CA8-47A9-9AB5-B576493EA1EB@noao.edu>

Some sad news.  Peter Bunclark who was active on this list has passed  
away.  Folks on both sides of the Atlantic will remember him fondly.

Rob
--

> From: World Wide Web <webman at ast.cam.ac.uk>
> Date: 11 December 2008 10:47:43 GMT
> Subject: Pete Bunclark
>
> I am very sorry to have to report that Pete Bunclark passed away  
> last night.  As many of you will know, he was diagnosed with motor  
> neurone disease in May and his deterioration since then has been  
> rapid.
>
> Pete has worked at the IoA/RGO since 1979.  In spite of his ill  
> health he was determined to continue working for CASU and the VISTA  
> project and did so until the end.  He has many very close friends  
> here and his jolly sense of humour and camaraderie will be greatly  
> missed.


From dot at dotat.at  Mon Dec 15 07:01:11 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 15 Dec 2008 12:01:11 +0000
Subject: [LEAPSECS] Footnote about CCITT and UTC
In-Reply-To: <20081214215755.GE2263@fysh.org>
References: <12347.1229111251@critter.freebsd.dk>
	<C6F1E0C4598A46A5B133D3CF4EBBE0DE@pc52>
	<20081212223404.GC2263@fysh.org>
	<alpine.LSU.2.00.0812141958050.17486@hermes-1.csi.cam.ac.uk>
	<20081214215755.GE2263@fysh.org>
Message-ID: <alpine.LSU.2.00.0812151155200.9624@hermes-1.csi.cam.ac.uk>

On Sun, 14 Dec 2008, Zefram wrote:
>
> 	NOTE  These expressions apply to both UTC and non-UTC based time
> 	scales for time of day.
>
> This seems to be the crucial bit that you missed.  It's explicit about
> allowing time scales other than UTC, and doesn't restrict the choice
> of time scale at all.  UT1, with strict 86400-second days, is obviously
> permitted, and I suggest that vague UT per se is also a valid time scale.

Ah, yes, thanks for pointing that out, and also

> 	*local time*
>
> 	locally applicable time of day such as standard time of day,
> 	or a non-UTC based time of day
>
> You're permitted to represent, for example, the mean-solar-time-based
> British legal time in ISO 8601.

However...

> Unfortunately ISO 8601 does not supply any way to designate UT1 or any
> other flavour of UT except UTC.  Thus, strictly speaking, there is no
> way to designate any local time that is based on UT1 rather than UTC.

So non-UTC time has only minimal support by the standard.

> It seems to me that the standard would be rather more useful if "standard
> time" were defined more according to its original meaning: a local time
> scale defined by an offset from UT, rather than specifically from UTC.
> The timezone designation material should correspondingly refer to UT
> rather than UTC, and the "Z" should probably follow by designating UT.
> All of these would be explicitly vague as to which flavour of UT is
> being referred to.

Yes, I think this kind of vagueness makes sense in a lot of situations
(with appropriate caveats for applications that require subsecond
precision and agreement between multiple systems). It would work for POSIX
time too.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FORTIES CROMARTY FORTH: SOUTHERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY
ROUGH, BECOMING MODERATE OR ROUGH. FAIR THEN RAIN. MODERATE OR POOR.

From phk at phk.freebsd.dk  Tue Dec 16 11:07:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Dec 2008 16:07:30 +0000
Subject: [LEAPSECS] WP7A status
Message-ID: <46869.1229443650@critter.freebsd.dk>


http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From matsakis.demetrios at usno.navy.mil  Tue Dec 16 12:26:19 2008
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Tue, 16 Dec 2008 12:26:19 -0500
Subject: [LEAPSECS] WP7A status
In-Reply-To: <46869.1229443650@critter.freebsd.dk>
References: <46869.1229443650@critter.freebsd.dk>
Message-ID: <5BE518100A3B5041BFADC26754C50353B2C8CF@echoex.timenet.usno.navy.mil>

There is a mistake in the viewgraphs, which the authors will correct in
any other reports they generate.  This is the reference to URSI.

I was the person who chaired the URSI Commission J working group, and
later chaired the URSI-wide working group on the matter.  Every report
noted that no significant opposition or support for a change came from
within URSI.

The first survey I did, now outdated, reached through the internet to
anyone who chose to respond.  I did receive more negative opinions than
positive ones from the general public.  But the absolute numbers were
small, and none were URSI-related.   Then that commission WG completed
its job, and I chaired an URSI-wide group that did a second survey, 3
years later.  This went only to URSI and the only responses we received
were abstentions. 

On the basis of six years of non-expression of interest from their
constituency, the URSI secretariat made a unanimous decision to not
respond to the ITU-R's Special Rapporteur Group's letter, and my working
group was disbanded.

Historians may note that this provides two rare instances of a committee
being formed, doing its job on time, and then terminating itself.

-----Original Message-----
From: leapsecs-bounces at leapsecond.com
[mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Poul-Henning Kamp
Sent: Tuesday, December 16, 2008 11:08 AM
To: Leap Second Discussion List
Subject: [LEAPSECS] WP7A status


http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20S
ubcommittee/48-LS%2020080916.pdf

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by
incompetence.
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

From phk at phk.freebsd.dk  Tue Dec 16 12:32:42 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Dec 2008 17:32:42 +0000
Subject: [LEAPSECS] WP7A status
In-Reply-To: Your message of "Tue, 16 Dec 2008 12:26:19 EST."
	<5BE518100A3B5041BFADC26754C50353B2C8CF@echoex.timenet.usno.navy.mil> 
Message-ID: <47561.1229448762@critter.freebsd.dk>

In message <5BE518100A3B5041BFADC26754C50353B2C8CF at echoex.timenet.usno.navy.mil>, "Matsakis, Demetrios" writes:

>On the basis of six years of non-expression of interest from their
>constituency, the URSI secretariat made a unanimous decision to not
>respond to the ITU-R's Special Rapporteur Group's letter, and my working
>group was disbanded.

Does that non-response leave the earlier response standing ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From pete.forman at westerngeco.com  Tue Dec 16 12:35:59 2008
From: pete.forman at westerngeco.com (Pete Forman)
Date: Tue, 16 Dec 2008 17:35:59 +0000
Subject: [LEAPSECS] WP7A status
In-Reply-To: <46869.1229443650@critter.freebsd.dk>
References: <46869.1229443650@critter.freebsd.dk>
Message-ID: <7.0.1.0.2.20081216170607.04bc2400@gatwick.westerngeco.slb.com>

At 2008-12-16 16:07 +0000, Poul-Henning Kamp wrote:
>http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf

I cannot get to that web site but the words are in Google's cache.

http://www.google.com/search?q=cache:www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%2520Subcommittee/48-LS%252020080916.pdf

If I'm interpreting them correctly, they are leaning towards
suppressing leap seconds.  They do not spell out what might replace
them so presumably they are to allow abs(DUT1) to become greater than
a second, then some.

This implies to me that some latter day Pope Gregory will decide that
he is fed up with the inaccuracy of his sundial and slap on an
intercalation.  Why is that sort of consequence not mentioned in the
report?

-- 
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman at westerngeco.com    -./\.-   the opinion of Schlumberger or
http://petef.22web.net           -./\.-   WesternGeco.


From sla at ucolick.org  Tue Dec 16 12:36:25 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 16 Dec 2008 09:36:25 -0800
Subject: [LEAPSECS] clinical evidence about time and sun
Message-ID: <20081216173625.GA13462@ucolick.org>

Following the recent op-ed in the New York Times I was looking around
at the sorts of antics that accompany daylight saving time.

The wikipedia page about time in Indiana
http://en.wikipedia.org/wiki/Time_in_Indiana
gives a more subdued version of things than the web2.0 comments in NYT.

But as far as keeping civil activities in step with the sun, there is
now clinical evidence about risks.  The current issue of the Journal
of Clinical Sleep Medicine has a study about the start time of school
for adolescents and its effect on the risk of motor vehicle crashes.

the abstract is at
http://www.aasmnet.org/jcsm/ViewAbstract.aspx?citationid=3721
and for authorized sites the article is
http://www.aasmnet.org/jcsm/Articles/040602.pdf

To disconnect UTC, and thus civil time, from the sun is to have
to contend with all of the parties in these discussions, to
convince them all that the change is irrelevant, or to unilaterally
disregard them.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Tue Dec 16 12:40:48 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Dec 2008 17:40:48 +0000
Subject: [LEAPSECS] WP7A status
In-Reply-To: Your message of "Tue, 16 Dec 2008 17:35:59 GMT."
	<7.0.1.0.2.20081216170607.04bc2400@gatwick.westerngeco.slb.com> 
Message-ID: <47651.1229449248@critter.freebsd.dk>

In message <7.0.1.0.2.20081216170607.04bc2400 at gatwick.westerngeco.slb.com>, Pete Forman writes:

>This implies to me that some latter day Pope Gregory will decide that
>he is fed up with the inaccuracy of his sundial and slap on an
>intercalation.  Why is that sort of consequence not mentioned in the
>report?

I guess the Popes Astronomer has less clout today than in less enlightened
days...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 16 12:47:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 16 Dec 2008 17:47:30 +0000
Subject: [LEAPSECS] clinical evidence about time and sun
In-Reply-To: Your message of "Tue, 16 Dec 2008 09:36:25 PST."
	<20081216173625.GA13462@ucolick.org> 
Message-ID: <47714.1229449650@critter.freebsd.dk>

In message <20081216173625.GA13462 at ucolick.org>, Steve Allen writes:

>To disconnect UTC, and thus civil time, from the sun [...]

Steve,

Civil time is not UTC anywhere that I have heard about.

Even the British had other and better reasons than landscaping in
public parks for holding on to GMT.

Most countries have civil time on the (law-)books as being "UTC +
something", where something is often a function of time and in
a few cases also of (cultural) geography.

There are a few stragling countries like Denmark sticking up for,
at least on paper, mean solar time, but in practice doing the sensible
thing, like everybody else.

Please discontinue use of your "disconnecting civil time from the
sun" red herring, it has nothing to do with reality anywhere on
Earth, and only serves to confuse.

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From pete.forman at westerngeco.com  Tue Dec 16 12:53:58 2008
From: pete.forman at westerngeco.com (Pete Forman)
Date: Tue, 16 Dec 2008 17:53:58 +0000
Subject: [LEAPSECS] WP7A status
References: <"Your message of Tue, 16 Dec 2008 17:35:59 GMT."
	<7.0.1.0.2.20081216170607.04bc2400@gatwick.westerngeco.slb.com>
Message-ID: <7.0.1.0.2.20081216174802.04bc21a8@gatwick.westerngeco.slb.com>

At 2008-12-16 17:40 +0000, Poul-Henning Kamp wrote:
>In message 
><7.0.1.0.2.20081216170607.04bc2400 at gatwick.westerngeco.slb.com>, 
>Pete Forman writes:
>
> >This implies to me that some latter day Pope Gregory will decide that
> >he is fed up with the inaccuracy of his sundial and slap on an
> >intercalation.  Why is that sort of consequence not mentioned in the
> >report?
>
>I guess the Popes Astronomer has less clout today than in less enlightened
>days...

I was using Pope as a euphemism for Secretary General of the ITU.  :-)

-- 
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman at westerngeco.com    -./\.-   the opinion of Schlumberger or
http://petef.22web.net           -./\.-   WesternGeco.


From zefram at fysh.org  Tue Dec 16 13:02:27 2008
From: zefram at fysh.org (Zefram)
Date: Tue, 16 Dec 2008 18:02:27 +0000
Subject: [LEAPSECS] clinical evidence about time and sun
In-Reply-To: <20081216173625.GA13462@ucolick.org>
References: <20081216173625.GA13462@ucolick.org>
Message-ID: <20081216180227.GZ14473@fysh.org>

Steve Allen wrote:
>http://www.aasmnet.org/jcsm/ViewAbstract.aspx?citationid=3721

Interesting results, but unfortunately this only looks at a one-hour
difference at one point in the year.  I'd like to see the same stats
done across the entire year.  In particular, is the road accident rate
dependent on the relationship between *solar noon* and office hours,
or between *sunrise* and office hours?  An answer to that question would
give, at long last, a substantial scientific basis to the debate on DST.

Whether civil time is defined as an offset from solar time or as an
offset from atomic time seems quite orthogonal.

-zefram

From sla at ucolick.org  Tue Dec 16 13:52:59 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 16 Dec 2008 10:52:59 -0800
Subject: [LEAPSECS] WP7A status
In-Reply-To: <46869.1229443650@critter.freebsd.dk>
References: <46869.1229443650@critter.freebsd.dk>
Message-ID: <20081216185259.GA13657@ucolick.org>

On Tue 2008-12-16T16:07:30 +0000, Poul-Henning Kamp hath writ:
> http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf

That was before the meeting in Geneva, before China objected.

It is worth pointing out that during this CGSIC meeting Thomas
Bartholomew offered to provide the draft of the report being
summarized to parties who asked.

I am aware that he provided it to journalists from New Scientist
last week.  I have requested it also, but a total meltdown of
the core e-mail services here prevents me from being sure whether
or not it was sent to me.

Given that it was provided to New Scientist, I suggest that
it may be interesting for members of this list to request
the draft also.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From matsakis.demetrios at usno.navy.mil  Tue Dec 16 16:04:40 2008
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Tue, 16 Dec 2008 16:04:40 -0500
Subject: [LEAPSECS] WP7A status
In-Reply-To: <47561.1229448762@critter.freebsd.dk>
References: Your message of "Tue, 16 Dec 2008 12:26:19
	EST."<5BE518100A3B5041BFADC26754C50353B2C8CF@echoex.timenet.usno.navy.mil>
	<47561.1229448762@critter.freebsd.dk>
Message-ID: <5BE518100A3B5041BFADC26754C50353B2C8D6@echoex.timenet.usno.navy.mil>

I am unaware of URSI having made any official response.  As far as URSI
is concerned, my WG reports are all I know of.

I hope I don't offend anyone by adding that the most vocal scientists I
know of on this subject, in other venues, do not even attend the URSI
General Assemblies.

-----Original Message-----
From: leapsecs-bounces at leapsecond.com
[mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Poul-Henning Kamp
Sent: Tuesday, December 16, 2008 12:33 PM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] WP7A status

In message
<5BE518100A3B5041BFADC26754C50353B2C8CF at echoex.timenet.usno.navy.mil>,
"Matsakis, Demetrios" writes:

>On the basis of six years of non-expression of interest from their 
>constituency, the URSI secretariat made a unanimous decision to not 
>respond to the ITU-R's Special Rapporteur Group's letter, and my 
>working group was disbanded.

Does that non-response leave the earlier response standing ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by
incompetence.
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

From seaman at noao.edu  Wed Dec 17 10:34:22 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 17 Dec 2008 08:34:22 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <46869.1229443650@critter.freebsd.dk>
References: <46869.1229443650@critter.freebsd.dk>
Message-ID: <38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>

On Dec 16, 2008, at 9:07 AM, Poul-Henning Kamp wrote:

> http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf

Thanks for posting this - extremely helpful!

On Dec 16, 2008, at 10:47 AM, Poul-Henning Kamp wrote:

> Please discontinue use of your "disconnecting civil time from the  
> sun" red herring, it has nothing to do with reality anywhere on  
> Earth, and only serves to confuse.

This, however, is an example of an unhelpful statement.  You may (or,  
obviously, may not) agree with statements from others on the list.  If  
not, by all means make a passionate response.  But it is not only  
rude, but counterproductive to try to tell others what they can or  
cannot say.

For instance, I happen to think your notion about perpetually  
revolving the time zone offsets around the planet under completely  
local authority is spectacularly unworkable.  However, you have my  
encouragement (and more to the point, don't need it) to keep trying to  
develop supporting arguments for it.

On the other hand, I won't seek to justify the basis of Steve's  
message because we have done so over and over.

When some say "civil time" they mean the underlying international  
timescale (UTC or not, but currently everywhere some approximation to  
GMT).  When others say civil time they mean local standard time.  One  
is obviously layered on the other (whatever chaos might be introduced  
by standards bodies, and whether or not time zone offsets are a  
function of time), and the particular meaning is almost always clear  
from the context of a particular message.

Rob

From seaman at noao.edu  Wed Dec 17 10:59:20 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 17 Dec 2008 08:59:20 -0700
Subject: [LEAPSECS] WP7A status
In-Reply-To: <20081216185259.GA13657@ucolick.org>
References: <46869.1229443650@critter.freebsd.dk>
	<20081216185259.GA13657@ucolick.org>
Message-ID: <B51DC6AF-ED3C-4818-98F6-59A8DCD4882A@noao.edu>

On Dec 16, 2008, at 11:52 AM, Steve Allen wrote:

> On Tue 2008-12-16T16:07:30 +0000, Poul-Henning Kamp hath writ:
>> http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf
>
> That was before the meeting in Geneva, before China objected.

Ah!  Thanks for the clarification.

> I am aware that he provided it to journalists from New Scientist  
> last week.

Apparently they separately began working on two different articles for  
the online and print editions.  Likely the need to resolve this turf  
battle and the looming holidays have led to some delay.  I don't know  
whether they were trying to publish before the leap second - it seems  
late to write such an article for print.


On Dec 16, 2008, at 2:04 PM, Matsakis, Demetrios wrote:

> I am unaware of URSI having made any official response.  As far as  
> URSI
> is concerned, my WG reports are all I know of.
>
> I hope I don't offend anyone by adding that the most vocal  
> scientists I
> know of on this subject, in other venues, do not even attend the URSI
> General Assemblies.

And most astronomers don't attend the IAU General Assemblies.


On Dec 16, 2008, at 10:32 AM, Poul-Henning Kamp wrote:

> "Matsakis, Demetrios" writes:
>
>> On the basis of six years of non-expression of interest from their
>> constituency, the URSI secretariat made a unanimous decision to not
>> respond to the ITU-R's Special Rapporteur Group's letter, and my  
>> working
>> group was disbanded.
>
> Does that non-response leave the earlier response standing ?

This is similar to the non-response (what the stale report referred to  
misleadingly as a "neutral" response) from the IAU and AAS.  In  
particular, the AAS committee contained one of the main proponents of  
"read my lips - no new leap seconds", and the committee still decided  
to take no position.  As far as the IAU, the three year cadence of  
General Assemblies ensures a very measured pace of response.  Note  
that any coordinated action on leap seconds would have been drowned  
out in 2006 by the hubbub over the demotion of Pluto.  Will there be  
any renewed attempt to raise the issue in Brazil in 2009?

The only inference to draw is that more consultation is clearly  
needed.  I'll renew my frequent call for a holding a well advertised  
and well organized conference on civil timekeeping:

	http://six.pairlist.net/pipermail/leapsecs/2008-November/000484.html

Rob

From cowan at ccil.org  Wed Dec 17 20:01:03 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 17 Dec 2008 20:01:03 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
Message-ID: <20081218010103.GC9007@mercury.ccil.org>

Rob Seaman scripsit:

> For instance, I happen to think your notion about perpetually  
> revolving the time zone offsets around the planet under completely  
> local authority is spectacularly unworkable.  

Why are such changes in timezone unworkable, provided they
don't happen too often?  The median frequency of changes in timezone
(neglecting DST changes) is several per century as it is: see the
Olson data.

-- 
And it was said that ever after, if any                 John Cowan
man looked in that Stone, unless he had a               cowan at ccil.org
great strength of will to turn it to other              http://ccil.org/~cowan
purpose, he saw only two aged hands withering
in flame.   --"The Pyre of Denethor"

From seaman at noao.edu  Wed Dec 17 21:23:16 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 17 Dec 2008 19:23:16 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081218010103.GC9007@mercury.ccil.org>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
Message-ID: <7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>

Because the past remains with us, and the future requires planning.   
By discarding any stationary mapping from local clocks (and calendar)  
to an underlying "universal" timescale, historical provenance and long  
range planning acquire a spatially dependent error term that grows  
with time.  The historical trend (http://www.ucolick.org/~sla/leapsecs/ancient.png 
) won't just vanish with the actions of the ITU, it will pop up again  
somewhere else.

In short, time has duration not just discrete epochs to worry about.

Rob
---
On Dec 17, 2008, at 6:01 PM, John Cowan wrote:

> Rob Seaman scripsit:
>
>> For instance, I happen to think your notion about perpetually
>> revolving the time zone offsets around the planet under completely
>> local authority is spectacularly unworkable.
>
> Why are such changes in timezone unworkable, provided they
> don't happen too often?  The median frequency of changes in timezone
> (neglecting DST changes) is several per century as it is: see the
> Olson data.

From sla at ucolick.org  Wed Dec 17 22:09:54 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 17 Dec 2008 19:09:54 -0800
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
Message-ID: <20081218030954.GA26396@ucolick.org>

On Wed 2008-12-17T19:23:16 -0700, Rob Seaman hath writ:
>  The historical trend
> (http://www.ucolick.org/~sla/leapsecs/ancient.png ) won't just vanish with
> the actions of the ITU, it will pop up again  somewhere else.

I appreciate the link to the LOD plot, and I have faith in the
readership of LEAPSECS, but the sad fact is that the general public
cannot do an integral in their heads, so I prefer now to point at
http://www.ucolick.org/~sla/leapsecs/deltat.html
which shows the full glory of Morrison & Stephenson's work in
the context of historical events.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Thu Dec 18 03:28:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 18 Dec 2008 08:28:30 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: Your message of "Wed, 17 Dec 2008 19:09:54 PST."
	<20081218030954.GA26396@ucolick.org> 
Message-ID: <10573.1229588910@critter.freebsd.dk>

In message <20081218030954.GA26396 at ucolick.org>, Steve Allen writes:

>http://www.ucolick.org/~sla/leapsecs/deltat.html

I belive your LORAN-C TOC is wrong, that should be 01-01-1958 00:00:00 UTC

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From Markus.Kuhn at cl.cam.ac.uk  Thu Dec 18 06:38:49 2008
From: Markus.Kuhn at cl.cam.ac.uk (Markus Kuhn)
Date: Thu, 18 Dec 2008 11:38:49 +0000
Subject: [LEAPSECS] WP7A status
In-Reply-To: Your message of "Tue, 16 Dec 2008 10:52:59 PST."
	<20081216185259.GA13657@ucolick.org> 
Message-ID: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>

Steve Allen wrote on 2008-12-16 18:52 UTC:
> On Tue 2008-12-16T16:07:30 +0000, Poul-Henning Kamp hath writ:
> > http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf
> 
> I am aware that he provided it to journalists from New Scientist last week.

http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-leap-second-grow.html

Markus

-- 
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain


From greg.hennessy at cox.net  Thu Dec 18 06:52:41 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Thu, 18 Dec 2008 06:52:41 -0500
Subject: [LEAPSECS] WP7A status
In-Reply-To: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
Message-ID: <494A3989.1090307@cox.net>


> http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-leap-second-grow.html

The report has a sentence "GPS time is not a reference, it is simply an internal 
time for GPS system synchronization, as GLONASS time is and Galileo time will be."

Is what it takes to be a reference documented any where?



From seaman at noao.edu  Thu Dec 18 11:13:39 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 09:13:39 -0700
Subject: [LEAPSECS] WP7A status
In-Reply-To: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
Message-ID: <D2B988FA-B3C2-4A07-A593-A2324CEA4089@noao.edu>

Not a very impressive article, whatever one's point of view.
--

On Dec 18, 2008, at 4:38 AM, Markus Kuhn wrote:

> Steve Allen wrote on 2008-12-16 18:52 UTC:
>> On Tue 2008-12-16T16:07:30 +0000, Poul-Henning Kamp hath writ:
>>> http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf
>>
>> I am aware that he provided it to journalists from New Scientist  
>> last week.
>
> http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-leap-second-grow.html
>
> Markus
>
> -- 
> Markus Kuhn, Computer Laboratory, University of Cambridge
> http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs


From cowan at ccil.org  Thu Dec 18 11:15:26 2008
From: cowan at ccil.org (John Cowan)
Date: Thu, 18 Dec 2008 11:15:26 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
Message-ID: <20081218161526.GA30950@mercury.ccil.org>

Rob Seaman scripsit:

> Because the past remains with us, and the future requires planning.   

What the past tells us is that prediction is very difficult, *especially*
about the future.  At sea, where no one cares much, the timezone mappings
have remained stable; on land, it's a different story, with multiple
changes for most of the 384 Olson time jurisdictions.

The median number of changes over the century-give-or-take of standard
time (exactly when standard time begins depends on the jurisdiction)
is 3, minimum 1, maximum 17 (!), mean 3.94, standard deviation 2.88.
Even if we ignore all changes before the Unix epoch, we still have 545
changes in 231 jurisdictions.

> By discarding any stationary mapping from local clocks (and calendar)  

You cannot discard what does not exist.

> to an underlying "universal" timescale, historical provenance and long  
> range planning acquire a spatially dependent error term that grows  
> with time.  

Long-range planning does not and cannot extend 3.5 millennia into
the future.

> In short, time has duration not just discrete epochs to worry about.

Local time, even if DST effects are excluded, is unfit to measure
duration: it has too many discontinuities.

-- 
John Cowan    cowan at ccil.org    http://ccil.org/~cowan
        Sound change operates regularly to produce irregularities;
        analogy operates irregularly to produce regularities.
                --E.H. Sturtevant, ca. 1945, probably at Yale

From matsakis.demetrios at usno.navy.mil  Thu Dec 18 11:24:35 2008
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Thu, 18 Dec 2008 11:24:35 -0500
Subject: [LEAPSECS] WP7A status
In-Reply-To: <494A3989.1090307@cox.net>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
	<494A3989.1090307@cox.net>
Message-ID: <5BE518100A3B5041BFADC26754C50353B2C908@echoex.timenet.usno.navy.mil>

The best way to get "Time" out of GPS is to apply the leap seconds and
subframe 4 corrections of the broadcast GPS navigation message to GPS
time, and get UTC(USNO) via GPS.  Most GPS receivers do this
automatically. There can be calibration and latency issues, which are
usually but not always below 10 ns.

GPS time itself is provided for navigation solutions.  That is why it
does not incorporate leap seconds, and that is also why GPS time is
steered by acceleration (not rate) to UTC(USNO), modulo 1 second, using
the so-called bang-bang algorithm.

The best reference would be the ICD-GPS-202, which is written in style I
would describe as "for engineers".

-----Original Message-----
From: leapsecs-bounces at leapsecond.com
[mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Greg Hennessy
Sent: Thursday, December 18, 2008 6:53 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] WP7A status


> http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-
> leap-second-grow.html

The report has a sentence "GPS time is not a reference, it is simply an
internal time for GPS system synchronization, as GLONASS time is and
Galileo time will be."

Is what it takes to be a reference documented any where?


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

From imp at bsdimp.com  Thu Dec 18 12:28:38 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 18 Dec 2008 10:28:38 -0700 (MST)
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
 sun
In-Reply-To: <10573.1229588910@critter.freebsd.dk>
References: <20081218030954.GA26396@ucolick.org>
	<10573.1229588910@critter.freebsd.dk>
Message-ID: <20081218.102838.-432837111.imp@bsdimp.com>

In message: <10573.1229588910 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <20081218030954.GA26396 at ucolick.org>, Steve Allen writes:
: 
: >http://www.ucolick.org/~sla/leapsecs/deltat.html
: 
: I belive your LORAN-C TOC is wrong, that should be 01-01-1958 00:00:00 UTC

I believe it is correct.

Although the epic of LORAN-C TOC is indeed 1958, LORAN-C TOC followed
the 'rubber seconds' from 1958 until 1972 when leap seconds were
introduced.  After that, its course is parallel to UTC without further
leap seconds.

I guess I guest to cite the US replacement LORAN-C timing system I was
heavily involved in as my source of authority here.  I'd cite actual
documents, but I can't walk into Tom's office anymore to grab the
LORAN-C definition anymore...

Warner

From lang at unb.ca  Thu Dec 18 13:13:51 2008
From: lang at unb.ca (Richard B. Langley)
Date: Thu, 18 Dec 2008 14:13:51 -0400
Subject: [LEAPSECS] WP7A status
In-Reply-To: <5BE518100A3B5041BFADC26754C50353B2C908@echoex.timenet.usno.navy.mil>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
	<494A3989.1090307@cox.net>
	<5BE518100A3B5041BFADC26754C50353B2C908@echoex.timenet.usno.navy.mil>
Message-ID: <1229624031.494a92df688f4@webmail.unb.ca>

Not just for navigation. The geodetic community time-tags GPS measurements with GPS
(System) Time and all RINEX observation files, for example, use GPS Time as the
measurement epoch time scale. But, there are also other high-level time scales
maintained by different GPS analysis centres as well as a merged IGS time scale. More
info here for those interested in the intracacies:
<www.ngs.noaa.gov/IGSWorkshop2008/docs/IGS2008-Senior.pdf>.
-- Richard Langley

Quoting "Matsakis, Demetrios" <matsakis.demetrios at usno.navy.mil>:

> The best way to get "Time" out of GPS is to apply the leap seconds and
> subframe 4 corrections of the broadcast GPS navigation message to GPS
> time, and get UTC(USNO) via GPS.  Most GPS receivers do this
> automatically. There can be calibration and latency issues, which are
> usually but not always below 10 ns.
> 
> GPS time itself is provided for navigation solutions.  That is why it
> does not incorporate leap seconds, and that is also why GPS time is
> steered by acceleration (not rate) to UTC(USNO), modulo 1 second, using
> the so-called bang-bang algorithm.
> 
> The best reference would be the ICD-GPS-202, which is written in style I
> would describe as "for engineers".
> 
> -----Original Message-----
> From: leapsecs-bounces at leapsecond.com
> [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Greg Hennessy
> Sent: Thursday, December 18, 2008 6:53 AM
> To: Leap Second Discussion List
> Subject: Re: [LEAPSECS] WP7A status
> 
> 
> > http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-
> > leap-second-grow.html
> 
> The report has a sentence "GPS time is not a reference, it is simply an
> internal time for GPS system synchronization, as GLONASS time is and
> Galileo time will be."
> 
> Is what it takes to be a reference documented any where?
> 
> 
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
> 


===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From sla at ucolick.org  Thu Dec 18 13:14:55 2008
From: sla at ucolick.org (Steve Allen)
Date: Thu, 18 Dec 2008 10:14:55 -0800
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081218.102838.-432837111.imp@bsdimp.com>
References: <20081218030954.GA26396@ucolick.org>
	<10573.1229588910@critter.freebsd.dk>
	<20081218.102838.-432837111.imp@bsdimp.com>
Message-ID: <20081218181455.GB28861@ucolick.org>

On Thu 2008-12-18T10:28:38 -0700, M. Warner Losh hath writ:
> Although the epic of LORAN-C TOC is indeed 1958, LORAN-C TOC followed
> the 'rubber seconds' from 1958 until 1972 when leap seconds were
> introduced.  After that, its course is parallel to UTC without further
> leap seconds.

And if I have read the history correctly the deployment of cesium
standards along the LORAN-C chains in the late 1960s was one of the
strongest motivating forces for the CCIR's unilateral and urgent
action to change the standard for broadcast time signals from
following the earth rotation measure that they explicitly identified
by name as UT2 to following the atomic time measure (which was about
to be named TAI) with added leap seconds.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From jhein at timing.com  Thu Dec 18 13:47:31 2008
From: jhein at timing.com (John Hein)
Date: Thu, 18 Dec 2008 11:47:31 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time
	and	sun
In-Reply-To: <20081218161526.GA30950@mercury.ccil.org>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
Message-ID: <18762.39619.518916.553804@gromit.timing.com>

John Cowan wrote at 11:15 -0500 on Dec 18, 2008:
 > Rob Seaman scripsit:
 > > Because the past remains with us, and the future requires planning.   

In addition to what John Cowan said, I'd also point out that planning
is the one of the biggest issues with leap seconds.

In terms of planning for the future, if an application cares about
local time, not knowing whether a leap second is going to happen
outside a six month window can be a much larger problem than handling
sliding time zones that would happen much less frequently and, one
would think, with considerably more advance notice.

For those that are in favor of the current system of leap seconds, it
might be more effective to pretend that people don't have to plan for
the future than to remind them in the opening sentence.

From matsakis.demetrios at usno.navy.mil  Thu Dec 18 14:44:40 2008
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Thu, 18 Dec 2008 14:44:40 -0500
Subject: [LEAPSECS] WP7A status
In-Reply-To: <1229624031.494a92df688f4@webmail.unb.ca>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
	<494A3989.1090307@cox.net>
	<5BE518100A3B5041BFADC26754C50353B2C908@echoex.timenet.usno.navy.mil>
	<1229624031.494a92df688f4@webmail.unb.ca>
Message-ID: <5BE518100A3B5041BFADC26754C50353B2C90F@echoex.timenet.usno.navy.mil>

Agreed, and I'm sure many other uses have been found for GPS time, as
well.  It wouldn't surprise if some poorly-programmed GPS receivers
ignore the UTC(USNO) correction and just put in leap seconds, for
example.

Both sides on this mailing list could use this example to promote their
case.  Opponents to a change would say that perfectly fine solutions
exist to handle leap seconds, while advocates would say that engineering
solutions naturally gravitate towards the timescales that don't jump,
whether or not they lead to confusion or suboptimal daily performance.

-----Original Message-----
From: Richard B. Langley [mailto:lang at unb.ca] 
Sent: Thursday, December 18, 2008 1:14 PM
To: Leap Second Discussion List; Matsakis, Demetrios
Subject: Re: [LEAPSECS] WP7A status

Not just for navigation. The geodetic community time-tags GPS
measurements with GPS
(System) Time and all RINEX observation files, for example, use GPS Time
as the measurement epoch time scale. But, there are also other
high-level time scales maintained by different GPS analysis centres as
well as a merged IGS time scale. More info here for those interested in
the intracacies:
<www.ngs.noaa.gov/IGSWorkshop2008/docs/IGS2008-Senior.pdf>.
-- Richard Langley

Quoting "Matsakis, Demetrios" <matsakis.demetrios at usno.navy.mil>:

> The best way to get "Time" out of GPS is to apply the leap seconds and

> subframe 4 corrections of the broadcast GPS navigation message to GPS 
> time, and get UTC(USNO) via GPS.  Most GPS receivers do this 
> automatically. There can be calibration and latency issues, which are 
> usually but not always below 10 ns.
> 
> GPS time itself is provided for navigation solutions.  That is why it 
> does not incorporate leap seconds, and that is also why GPS time is 
> steered by acceleration (not rate) to UTC(USNO), modulo 1 second, 
> using the so-called bang-bang algorithm.
> 
> The best reference would be the ICD-GPS-202, which is written in style

> I would describe as "for engineers".
> 
> -----Original Message-----
> From: leapsecs-bounces at leapsecond.com
> [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Greg Hennessy
> Sent: Thursday, December 18, 2008 6:53 AM
> To: Leap Second Discussion List
> Subject: Re: [LEAPSECS] WP7A status
> 
> 
> > http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-th
> > e-
> > leap-second-grow.html
> 
> The report has a sentence "GPS time is not a reference, it is simply 
> an internal time for GPS system synchronization, as GLONASS time is 
> and Galileo time will be."
> 
> Is what it takes to be a reference documented any where?
> 
> 
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
> 


========================================================================
=======
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web:
http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See:
http://www.city.fredericton.nb.ca/
========================================================================
=======



From seaman at noao.edu  Thu Dec 18 16:23:57 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 14:23:57 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081218161526.GA30950@mercury.ccil.org>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
Message-ID: <4F2EB5F0-A8DF-4ED2-B1B6-9E38BD6B8F33@noao.edu>

On Dec 18, 2008, at 9:15 AM, John Cowan wrote:

> The median number of changes over the century-give-or-take of standard
> time (exactly when standard time begins depends on the jurisdiction)
> is 3, minimum 1, maximum 17 (!), mean 3.94, standard deviation 2.88.
> Even if we ignore all changes before the Unix epoch, we still have 545
> changes in 231 jurisdictions.

And how precisely is this making your point?  In the absence of a  
coherent zoneinfo scheme like Steve Allen's, you are asserting that  
the (literally) rock solid basis of mean solar time anchored deep in  
the Earth, be replaced with a completely unreliable mapping that  
varies under diverse authority both in geographic location and by  
decade and century.  Historians and scientists interested not only in  
marking time - but in doing something useful with it - will mock this  
effort.

Again - civil time is clearly a flavor of mean solar time, whether or  
not we decide to cheat by embargoing leap seconds or by sloshing the  
timezones around.  For example, we have sent missions to Mars, and the  
obvious and immediate response of the projects operating equipment on  
the surface was to establish a mission clock synchronized to Martian  
mean solar time.

There are two types of time - interval and Earth orientation.  Civil  
time clearly has more to do with the latter than the former.   
Technological systems often (but not always) rely more on the former  
than the latter.  Get over it.  That's just the way it is.  Design  
systems that recognize such requirements.

The ITU report recently circulated infers from the (non-unanimous)  
support within WP7A for emasculating UTC that some consensus has been  
reached.  Rather, the disagreements that continue year after year on  
this mailing list are closer to expressing the true fact that no such  
consensus exists.  In the absence of consensus, no decision should be  
taken.   Conferences and other opportunities for face-to-face debate  
and wrangling, research publications detailing the logistical,  
technical, historical, sociological, political, scientific and other  
aspects of civil timekeeping should be produced.  Grants should be  
pursued to carry out this research.  Proper system engineering best  
practices should be followed to conduct trade-off studies and risk  
analyses, and so forth and so on.

Why is this controversial?

At the very least, someone promoting this proposal should show the  
rest of the world and themselves the respect of creating some sort of  
actual plan for what options might exist when the embargoed leap  
seconds turn into minutes and hours.  The proposal is intellectually  
embarrassing as it stands.

Rob


From cowan at ccil.org  Thu Dec 18 16:46:37 2008
From: cowan at ccil.org (John Cowan)
Date: Thu, 18 Dec 2008 16:46:37 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <4F2EB5F0-A8DF-4ED2-B1B6-9E38BD6B8F33@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<4F2EB5F0-A8DF-4ED2-B1B6-9E38BD6B8F33@noao.edu>
Message-ID: <20081218214637.GG9007@mercury.ccil.org>

Rob Seaman scripsit:

> And how precisely is this making your point?  In the absence of a  
> coherent zoneinfo scheme like Steve Allen's, you are asserting that  
> the (literally) rock solid basis of mean solar time anchored deep in  
> the Earth,

Nothing anyone can do will change the value of mean solar time.

> be replaced with a completely unreliable mapping that  
> varies under diverse authority both in geographic location and by  
> decade and century.  

I'm pointing out that we are *already* doing that when establishing
local time.

> Again - civil time is clearly a flavor of mean solar time, whether or  
> not we decide to cheat by embargoing leap seconds or by sloshing the  
> timezones around.  For example, we have sent missions to Mars, and the  
> obvious and immediate response of the projects operating equipment on  
> the surface was to establish a mission clock synchronized to Martian  
> mean solar time.

Mean solar time is very important for certain purposes.  So is moonphase,
but I don't hear you howling against the Gregorian calendar and demanding
the immediate imposition of the Jewish (or Babylonian or Chinese) calendar.

> There are two types of time - interval and Earth orientation.  Civil  
> time clearly has more to do with the latter than the former.   

Oh, absolutely.  I'm not disputing that.

> Why is this controversial?

If you got the money, honey, they've got the time.  If not -- they've still
got the time.

> At the very least, someone promoting this proposal should show the  
> rest of the world and themselves the respect of creating some sort of  
> actual plan for what options might exist when the embargoed leap  
> seconds turn into minutes and hours.  

Actual plan:  Switch to DST and double DST when the difference between
mean solar time and local time becomes embarrassingly large.  (And if
Urumqi isn't embarrassed, why should Washington be?)

-- 
John Cowan    cowan at ccil.org    http://ccil.org/~cowan
If a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect.  --Benjamin Disraeli

From seaman at noao.edu  Thu Dec 18 16:50:19 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 14:50:19 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time
	and	sun
In-Reply-To: <18762.39619.518916.553804@gromit.timing.com>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<18762.39619.518916.553804@gromit.timing.com>
Message-ID: <5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>

So, the assertion is that an imaginary requirement that technology  
worldwide must remain synchronized to the fractional second level at  
all times in all places forever and ever - that this takes precedence  
over the actual (if heretofore largely unstated) requirement that  
historians and long term planners (and yes, some folks do think  
thousands of years into the past and the future) need a coherent  
system for tracking clock relationships between countries and centuries?

The real issue is and has been the quadratically increasing rate  
differences between atomic and solar time.  Technology wants a stable  
rate.  We live (in our manifold civil time scheduled ways) on a  
slowing platform.  Interval timekeeping has one set of requirements.   
Civil timekeeping has another.

Solutions for "applications" can and should rely on properly designed  
systems, not on kludges involving telling, for instance, the  
historians of the world that they will never again be able to keep  
track of relative clock time during battles and negotiations and  
journeys.

There are two kinds of time.  They demand two clocks.  UTC manages to  
convey both, but if you want to throw this useful feature out, you  
will still need two kinds of clocks.

Planning first requires recognizing the full scope of the problem.  If  
you don't like leap seconds, track the difference using Allen's  
zoneinfo system.  Or suggest your own system.  There has been a fair  
amount of support on this list for exploring the notion of stabilizing  
the leap second scheduling algorithm.  Most suggestions floated so far  
are even potentially in compliance with the current definition of  
UTC.  If a lack of predictability is really the issue with leap  
seconds, explore these options.

Rather, a unilateral and relentless campaign has been followed with  
the singleminded goal of eradicating leap seconds entirely.  Between  
repeated cycles of attempting to fend off this campaign, there has  
been no time to actually attempt to solve the problem you assert.

We live on a planet with charmingly irregular motions.  Attempting to  
ignore this fact will inevitably fail, perhaps spectacularly.

Rob
---

On Dec 18, 2008, at 11:47 AM, John Hein wrote:

> John Cowan wrote at 11:15 -0500 on Dec 18, 2008:
>> Rob Seaman scripsit:
>>> Because the past remains with us, and the future requires planning.
>
> In addition to what John Cowan said, I'd also point out that planning
> is the one of the biggest issues with leap seconds.
>
> In terms of planning for the future, if an application cares about
> local time, not knowing whether a leap second is going to happen
> outside a six month window can be a much larger problem than handling
> sliding time zones that would happen much less frequently and, one
> would think, with considerably more advance notice.
>
> For those that are in favor of the current system of leap seconds, it
> might be more effective to pretend that people don't have to plan for
> the future than to remind them in the opening sentence.
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs


From seaman at noao.edu  Thu Dec 18 16:54:03 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 14:54:03 -0700
Subject: [LEAPSECS] WP7A status
In-Reply-To: <5BE518100A3B5041BFADC26754C50353B2C90F@echoex.timenet.usno.navy.mil>
References: <20081218113849.56E9153F90@viterbi.cl.cam.ac.uk>
	<494A3989.1090307@cox.net>
	<5BE518100A3B5041BFADC26754C50353B2C908@echoex.timenet.usno.navy.mil>
	<1229624031.494a92df688f4@webmail.unb.ca>
	<5BE518100A3B5041BFADC26754C50353B2C90F@echoex.timenet.usno.navy.mil>
Message-ID: <CF6D3D7C-AE2F-4C4C-8579-A92A80F54C81@noao.edu>

On Dec 18, 2008, at 12:44 PM, Matsakis, Demetrios wrote:

> Both sides on this mailing list could use this example to promote  
> their
> case.  Opponents to a change would say that perfectly fine solutions
> exist to handle leap seconds, while advocates would say that  
> engineering
> solutions naturally gravitate towards the timescales that don't jump,
> whether or not they lead to confusion or suboptimal daily performance.

And these suggestions have been made.  One gets the impression that  
the - ahem - "advocate of change" despise GPS time more that UTC.

The issue also isn't "suboptimal daily performance", the issue is  
introducing a secular term into civil time.  This is precisely the  
quadratic term that the original GPS World article fretted about.

Rob


From seaman at noao.edu  Thu Dec 18 17:09:48 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 15:09:48 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081218214637.GG9007@mercury.ccil.org>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<4F2EB5F0-A8DF-4ED2-B1B6-9E38BD6B8F33@noao.edu>
	<20081218214637.GG9007@mercury.ccil.org>
Message-ID: <9E4357C2-FAF7-4525-81CB-75F11B01D974@noao.edu>

I should make the aside that these debates seem to pop up "like  
clockwork" every year around this time :-)

Regardless of everyone's entrenched positions, a most Happy New Year!

On Dec 18, 2008, at 2:46 PM, John Cowan wrote:

> I'm pointing out that we are *already* doing that when establishing
> local time.

No.  It is different in kind to layer local standard time on top of a  
UTC that is kept calibrated with respect to an external standard (the  
Earth), than it is to attempt to use local standard time itself to  
perform this calibration.

> Mean solar time is very important for certain purposes.  So is  
> moonphase,
> but I don't hear you howling against the Gregorian calendar and  
> demanding
> the immediate imposition of the Jewish (or Babylonian or Chinese)  
> calendar.

We are governed by many natural cycles.  The diurnal cycle is clearly  
preeminent.

My college logic text is at home.  What is the fallacy called that  
condemns me for arguments I've never made?  No, indeed, I've never  
howled about any of the problems weirwolves might have with keeping  
track of the full moon - even though, very significantly, this is an  
astronomical object.

If mean solar time doesn't matter, consider the gedanken experiment of  
the ITU proposing we redefine the day to be 100,000 SI seconds, for  
the sake of the obvious "convenience" this would bring.  Why would  
this be unacceptable?

> Actual plan:  Switch to DST and double DST when the difference between
> mean solar time and local time becomes embarrassingly large.  (And if
> Urumqi isn't embarrassed, why should Washington be?)

A) Does this really amount to a "plan" wherever you work?

B) I'll refrain from speculating about what it would take to embarrass  
Washington.  There are some other, rather higher priority, items that  
I would have thought might have done so recently.

C) By attempting to handle the situation this way, historical  
timekeeping (past and future) becomes far more of a fiction than the  
simple requirement of having to keep track of a list of prior leap  
seconds or predictions of future such.

Rob



From phk at phk.freebsd.dk  Thu Dec 18 17:13:17 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 18 Dec 2008 22:13:17 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: Your message of "Thu, 18 Dec 2008 14:50:19 MST."
	<5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu> 
Message-ID: <38070.1229638397@critter.freebsd.dk>

In message <5A9295BC-1704-489C-B4B1-2942C0414DF7 at noao.edu>, Rob Seaman writes:

>We live on a planet with charmingly irregular motions.  Attempting to  
>ignore this fact will inevitably fail, perhaps spectacularly.

Before the first timezone ever shifts to compensate for the abandoned
leapseconds, that number is almost certain to have increased to at
least two and likely more irregular rocks.

Which reminds me: you have never answered my question:

Why should mumans on Mars or the Moon, care about the rotation of
a rock they are not on when they want to time events ?  Isn't it
bad enough that relativity messes them up ?

And I still find it utterly ironic, that people like you attempt
to lock the timescale which has "Universal" in its name to a
particular piece of rock with known bad timekeeping properties.

A timescale which takes earth rotation into account should be
called "Terrestial Time Coordinated" (TTC ?) and the timescale
that takes into account the rotation of Mars should be MTC.

But the universal timescale should depend on nothing that is not
uniform throughout the Universe.  A good choice would be an
easy to measure and well defined atomic resonance under well
defined relativist circumstances.

I agree that the SI second lacks a bit before it lives up to last
clause there, but UTC with leap seconds is not a contender.

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From greg.hennessy at cox.net  Thu Dec 18 17:13:43 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Thu, 18 Dec 2008 17:13:43 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
 sun
In-Reply-To: <9E4357C2-FAF7-4525-81CB-75F11B01D974@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>	<20081218010103.GC9007@mercury.ccil.org>	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>	<20081218161526.GA30950@mercury.ccil.org>	<4F2EB5F0-A8DF-4ED2-B1B6-9E38BD6B8F33@noao.edu>	<20081218214637.GG9007@mercury.ccil.org>
	<9E4357C2-FAF7-4525-81CB-75F11B01D974@noao.edu>
Message-ID: <494ACB17.9010304@cox.net>

Rob Seaman wrote:
> I should make the aside that these debates seem to pop up "like 
> clockwork" every year around this time :-)

Probably because leapseconds tend to be around this time. :)


From jhein at timing.com  Thu Dec 18 17:32:39 2008
From: jhein at timing.com (John Hein)
Date: Thu, 18 Dec 2008 15:32:39 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about
	time	and	sun
In-Reply-To: <5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<18762.39619.518916.553804@gromit.timing.com>
	<5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
Message-ID: <18762.53127.165662.23992@gromit.timing.com>

Rob Seaman wrote at 14:50 -0700 on Dec 18, 2008:
 > So, the assertion is that an imaginary requirement that technology  
 > worldwide must remain synchronized to the fractional second level at  
 > all times in all places forever and ever - that this takes precedence  
 > over the actual (if heretofore largely unstated) requirement that  
 > historians and long term planners (and yes, some folks do think  
 > thousands of years into the past and the future) need a coherent  
 > system for tracking clock relationships between countries and centuries?

I'm not sure if you were responding to my post or not.  If so, then
no, that was not my assertion - I'm not sure how you inferred that
from my response.  I was simply stating that it's based on a shaky
foundation to argue against an alternative to leap seconds by stating
that planning for the future will be hard (for the alternative).


 > Solutions for "applications" can and should rely on properly designed  
 > systems

Indeed.  And relying on a system whereby you receive six months notice
is one of the problems with the current system of leap seconds.

I was trying specifically limit the scope of my previous comment to
this narrow issue, so I'll not be dragged into a dialog or rebuttal of
the remaining discussion, opinion & hyperbole of your reply at this
time, other than to agree on the elementary premise that there are
different timescales involved.

From seaman at noao.edu  Thu Dec 18 17:40:09 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 15:40:09 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <38070.1229638397@critter.freebsd.dk>
References: <38070.1229638397@critter.freebsd.dk>
Message-ID: <F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>

On Dec 18, 2008, at 3:13 PM, Poul-Henning Kamp wrote:

> Before the first timezone ever shifts to compensate for the abandoned
> leapseconds, that number is almost certain to have increased to at
> least two and likely more irregular rocks.

Scroll back the the very beginning of the archives.  I had some sort  
of response to a similar assertion from Demetrios Matsakis's original  
survey.  I might even still agree with it, if I read it again :-)

> Which reminds me: you have never answered my question:
>
> Why should mumans on Mars or the Moon, care about the rotation of
> a rock they are not on when they want to time events ?

Well, because they likely want to communicate with their families back  
on Earth, I suppose, but again you are making my point.  What are you  
asserting here?  That people living on Mars will clearly want to keep  
Martian time?  I believe that completely.  Martian civil time will  
clearly be mean solar time on Mars.

I don't intrinsically care about leap seconds, other than as a means  
to an end.  I care about maintaining the obvious connection between  
civil timekeeping and some functional flavor of mean solar time.

> Isn't it bad enough that relativity messes them up ?

This sounds like an interesting question, but you are discussing facts  
(or not facts) that haven't been entered into evidence.

> And I still find it utterly ironic, that people like you attempt
> to lock the timescale which has "Universal" in its name to a
> particular piece of rock with known bad timekeeping properties.

People like me don't particularly care about the "fossil poetry" (as  
Emerson calls it) of the origin of word phrases - at least not as far  
as usage is concerned.  UTC has been defined as a flavor of UT.  The  
original wording of the UTC standard (if I can call it that) included  
the clear statement:

	"GMT may be regarded as the general equivalent of UT."

Ignore everything else we've ever discussed.  The central issue with  
several of us is that the meaning of the UTC standard should not be  
changed.  If a decision (ideally a calm, reasoned and publicly  
transparent decision) is made to relayer civil timekeeping on a clock  
without leap seconds, then don't call that clock "UTC".

How about calling it - say - GPS?  The public already knows GPS,  
already owns devices that speak it, and already regards it as a brand  
name denoting high precision/accuracy timekeeping.

> A timescale which takes earth rotation into account should be
> called "Terrestial Time Coordinated" (TTC ?) and the timescale
> that takes into account the rotation of Mars should be MTC.

Go for it!  I have no particular opinion on this subject (well - yet -  
depending on how bizarre the political machinations become :-)  The  
difference between this suggestion and the ongoing discussion of UTC  
is that UTC has a long tangled history.  If you want to cut that  
tangle, do what Alexander did with the Gordian Knot - cleave it in  
half entirely by referencing a completely new timescale lacking in  
prior complications.

> But the universal timescale should depend on nothing that is not
> uniform throughout the Universe.

This is a misuse of the multiple meanings of the word "universal".  My  
TV receives a cable channel called "Universal HD".  Should I take them  
to court for misrepresentation?  What about Universal Studios or a  
universal remote control?

Rob

From zefram at fysh.org  Thu Dec 18 17:43:22 2008
From: zefram at fysh.org (Zefram)
Date: Thu, 18 Dec 2008 22:43:22 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <38070.1229638397@critter.freebsd.dk>
References: <5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
	<38070.1229638397@critter.freebsd.dk>
Message-ID: <20081218224322.GH2263@fysh.org>

Poul-Henning Kamp wrote:
>A timescale which takes earth rotation into account should be
>called "Terrestial Time Coordinated" (TTC ?) and the timescale
>that takes into account the rotation of Mars should be MTC.

The name "MTC" has already been used to refer, not to the Martian
equivalent of UTC, but to the Martian equivalent of GMT.  Obviously, the
people who did this are among those who don't think of the leap seconds
in UTC, but instead use "UTC" as the label for vague UT.  They were in
fact people at NASA working on the Mars rover missions.[0]

I think the fact that professionals in such a closely-related discipline
can't keep UT and UTC straight says something about the viability of
working with leap seconds.  It chimes with how we've seen all manner
of technical systems, even including NTP implementations, misbehave
around leap seconds.  It also matches my experience in editing the
Wikipedia articles on time scales: my plan to merge [[leap second]]
into [[Coordinated Universal Time]] was overwhelmingly rejected, by
people to whom the distinguishing feature of UTC is its Universality,
rather than its Coordination.

The Martian time scale in question, the local solar time on the Airy
meridian, is better described by the older name "Airy Mean Time" ("AMT").
We have a pretty good idea of the time on that timescale now, to within
a second.  (Though we did not have that precision when the rovers landed,
which explains the odd offsets of the mission timezones.)  Creating a
Martian equivalent for UTC is a much more complex job: it requires the
concepts of Marticentric Coordinate Time (TCM) and Martian Time (TM),
and an atomic time scale Martian Atomic Time (TAM) that realises TM.
That'll require actual atomic clocks on Mars.  Then MTC would have the
job of coordinating TAM with AMT (possibly also to be named MT1).

I find that the mental exercise of the previous paragraph drives home
just how artificial UTC and TAI are compared to UT1.  Pondering MTC
also gives some insight into the far future of UTC: current MTC, if we
could implement it, with TAM ticking SI seconds, would already require
more than one leap second per *minute*.  A minute of AMT occupies about
61.65 SI seconds.  We'd certainly need some arithmetical scheduling.

>But the universal timescale should depend on nothing that is not
>uniform throughout the Universe.  A good choice would be an
>easy to measure and well defined atomic resonance under well
>defined relativist circumstances.

Current physical theory does not identify any preferred reference frame.
The closest time scale we have so far is TCB, which is based on a
reference frame in which the barycentre of the solar system is at rest.

-zefram

[0] Michael Allison and Robert Schmunk, "Technical Notes on Mars
Solar Time as Adopted by the Mars24 Sunclock", Dec. 13 2005,
<http://www.giss.nasa.gov/tools/mars24/help/notes.html>.

From imp at bsdimp.com  Thu Dec 18 17:46:47 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 18 Dec 2008 15:46:47 -0700 (MST)
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
 sun
In-Reply-To: <18762.53127.165662.23992@gromit.timing.com>
References: <18762.39619.518916.553804@gromit.timing.com>
	<5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
	<18762.53127.165662.23992@gromit.timing.com>
Message-ID: <20081218.154647.1186305782.imp@bsdimp.com>

In message: <18762.53127.165662.23992 at gromit.timing.com>
            John Hein <jhein at timing.com> writes:
:  > Solutions for "applications" can and should rely on properly designed  
:  > systems
: 
: Indeed.  And relying on a system whereby you receive six months notice
: is one of the problems with the current system of leap seconds.

I find this ironic too.  "We must have a predictable future" is
fundamentally incompatible with the current system of leap seconds.
There's no predictability to the current system at all.  There's no
way to know how many leap seconds that will elapse between now and
the end of 2040.

Also, trying to force a system that's been in place for 37 years with
known limitations to last 1000's of years seems like an unwise
engineering move.  When Pope Gregor reformed the calendar, it was
based on hundreds if not thousands of years of observations, and was
known to be good for tens of thousands of years without anything else
ever changing, or any need for any authority to dictate leap days.
The necessity to say 'yea or nay' on leap seconds at a given time, as
opposed to a mechanical means of knowing, is a fundamental flaw with
the current system of leap seconds.

I guess the fundamental problem is that eventually, the day will be
86401 seconds.

Warner

From zefram at fysh.org  Thu Dec 18 18:27:29 2008
From: zefram at fysh.org (Zefram)
Date: Thu, 18 Dec 2008 23:27:29 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time
	and	sun
In-Reply-To: <5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<18762.39619.518916.553804@gromit.timing.com>
	<5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
Message-ID: <20081218232729.GI2263@fysh.org>

Rob Seaman wrote:
>historians and long term planners (and yes, some folks do think  
>thousands of years into the past and the future) need a coherent  
>system for tracking clock relationships between countries and centuries?

Historians have to relate whatever time scale was historically in use
to current time scales.  This is a complex job even for pre-industrial
history, given the multitude of calendars historically used.  To mention
but a handful of complications: many societies have labelled years
according to reigns of monarchs; Julian calendar users had widely
differing opinions about when the numbered year starts; some calendars
had irregular intercalation of months.

Obviously historians need to know whatever they can about the time
scales used by the society they're studying.  Future historians looking
at today will be interested in sub-second timing of some of the events
that we record, and for that purpose they'll need to know when the
leap seconds are in UTC.  This is directly analogous to knowing which
years in the Roman civil calendar had a Mercedonius.  Similarly, to
coordinate sub-hour times between countries, historians need the Olson
timezone database.  I don't think we can optimise our time scales to be
easy on future historians, because we don't know what kind of time scale
they'd prefer.  But it is our duty to record the relationships between
UT1, TT, and civil time.

When planning for the future, similar considerations apply, except that
the future civil time scales are all hypothetical.  We must use UT1 to
plan some things and TT to plan others.  Converting these to the civil
time scale of the time in question must be left to future generations.

So overall I don't think these issues form any argument one way or
another about what sort of time scale we ought to use, or plan to use,
for civil purposes.  That's just local convention.  Over long periods of
time we do best thinking in terms of the naturally-occurring timescales,
of both flavours.

>                                  telling, for instance, the  
>historians of the world that they will never again be able to keep  
>track of relative clock time during battles and negotiations and  
>journeys.

I don't see how we'd be telling historians this sort of thing under any of
our scenarios for civil time.  Historians can always perform conversions.
Unless we destroy all the records of what we did.

>There are two kinds of time.  They demand two clocks.  UTC manages to  
>convey both,

UTC only conveys interval time if you have the list of leap seconds.

>will still need two kinds of clocks.

I think the more fundamental issue is that we will, any way round, need
data that relates the two flavours of time.  A single clock reading
can't give both types of time in the absence of such knowledge.

-zefram

From cowan at ccil.org  Thu Dec 18 23:45:55 2008
From: cowan at ccil.org (John Cowan)
Date: Thu, 18 Dec 2008 23:45:55 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
Message-ID: <20081219044555.GA389@mercury.ccil.org>

Rob Seaman scripsit:

> >Why should mumans on Mars or the Moon, care about the rotation of
> >a rock they are not on when they want to time events ?
> 
> Well, because they likely want to communicate with their families back  
> on Earth, I suppose, but again you are making my point.  What are you  
> asserting here?  That people living on Mars will clearly want to keep  
> Martian time?  I believe that completely.  Martian civil time will  
> clearly be mean solar time on Mars.

Ah, but will Lunar civil time be mean solar time on Luna?

> Ignore everything else we've ever discussed.  The central issue with  
> several of us is that the meaning of the UTC standard should not be  
> changed.  If a decision (ideally a calm, reasoned and publicly  
> transparent decision) is made to relayer civil timekeeping on a clock  
> without leap seconds, then don't call that clock "UTC".

As you know, I support that.

> How about calling it - say - GPS?  The public already knows GPS,  
> already owns devices that speak it, and already regards it as a brand  
> name denoting high precision/accuracy timekeeping.

I think the public associates GPS with location rather than time.

> This is a misuse of the multiple meanings of the word "universal".  My  
> TV receives a cable channel called "Universal HD".  Should I take them  
> to court for misrepresentation?  What about Universal Studios or a  
> universal remote control?

The World Series does seem an egregiously stupid name, though.

-- 
Even the best of friends cannot                 John Cowan
attend each others' funeral.                    cowan at ccil.org
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan

From seaman at noao.edu  Fri Dec 19 01:24:02 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 23:24:02 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time
	and	sun
In-Reply-To: <20081218232729.GI2263@fysh.org>
References: <46869.1229443650@critter.freebsd.dk>
	<38A3A941-F702-4518-AC7E-121214B51E9D@noao.edu>
	<20081218010103.GC9007@mercury.ccil.org>
	<7C47734D-E76E-410A-B3B8-0266D48B67B6@noao.edu>
	<20081218161526.GA30950@mercury.ccil.org>
	<18762.39619.518916.553804@gromit.timing.com>
	<5A9295BC-1704-489C-B4B1-2942C0414DF7@noao.edu>
	<20081218232729.GI2263@fysh.org>
Message-ID: <C8FFC557-4E91-42A0-BDED-7EC7CDD4C12F@noao.edu>

On Dec 18, 2008, at 4:27 PM, Zefram wrote:

> I think the more fundamental issue is that we will, any way round,  
> need data that relates the two flavours of time.  A single clock  
> reading can't give both types of time in the absence of such  
> knowledge.

...and wouldn't a description of how these data would be conveyed make  
a useful section of any planning document related to fundamentally  
changing the definition of this standard?  One might suggest such a  
section would in other circumstances be required - and be widely  
understood to be required - in order to adopt a fundamental change  
like this.

Rather, the ITU wants to entirely remove the current DUT1 reporting  
requirement.

Rob


From seaman at noao.edu  Fri Dec 19 01:50:08 2008
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 18 Dec 2008 23:50:08 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081219044555.GA389@mercury.ccil.org>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
Message-ID: <DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>

On Dec 18, 2008, at 9:45 PM, John Cowan wrote:

> Ah, but will Lunar civil time be mean solar time on Luna?

For many purposes, yes.  The Apollo missions were planned to occur in  
daylight, for instance.  For other purposes, the factor of ~30  
contrast between the lunar day and the innate human diurnal rhythms  
would result in the natural use of a clock similar or identical to  
mean solar time on Earth.  One supposes the lunar synodic period would  
be divided into 30 parts.  It would be interesting to see whether the  
Earth day or Lunar day would win out - that is, whether the synodic  
period would be evenly divided by 30 to set a local clock rate, or  
whether the Earth day (meaning the mean solar day on Earth, of course)  
would trump being evenly divisible into the local day.

>> Ignore everything else we've ever discussed.  The central issue with
>> several of us is that the meaning of the UTC standard should not be
>> changed.  If a decision (ideally a calm, reasoned and publicly
>> transparent decision) is made to relayer civil timekeeping on a clock
>> without leap seconds, then don't call that clock "UTC".
>
> As you know, I support that.

Copacetic.

>> How about calling it - say - GPS?  The public already knows GPS,
>> already owns devices that speak it, and already regards it as a brand
>> name denoting high precision/accuracy timekeeping.
>
> I think the public associates GPS with location rather than time.

As an aside, I highly recommend Steven Pinker's "The Stuff of  
Thought", which persuasively argues that the grammatical structures we  
use to describe time are precisely the same as those used to describe  
(and reason about) spatial information.

GPS is a very popular brand name that could certainly be used as a  
component of a successful campaign to market a new concept of civil  
timekeeping.  Redefining UTC, on the other hand, will simply make what  
is a somewhat obscure standard even more obscure.

> The World Series does seem an egregiously stupid name, though.

No - they simply ought to extend it to teams from Japan and the  
Dominican Republic, etc.

Rob


From pete.forman at westerngeco.com  Fri Dec 19 04:09:33 2008
From: pete.forman at westerngeco.com (Pete Forman)
Date: Fri, 19 Dec 2008 09:09:33 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time
	and	sun
In-Reply-To: <DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
Message-ID: <7.0.1.0.2.20081219083452.03475cf0@gatwick.westerngeco.slb.com>

At 2008-12-18 23:50 -0700, Rob Seaman wrote:
>GPS is a very popular brand name that could certainly be used as a
>component of a successful campaign to market a new concept of civil
>timekeeping.

Please, no.  I've had to spend a lot of time explaining the difference
between GPS time as used in the satellite constellation and UTC as
reported from a GPS receiver.

Unless, that is, when leap seconds are abolished that GPS and UTCng
are to be synchronized.  I had intended that as a flippant remark;
but if civil time is to shift to an atomic scale then it will diverge
from solar time.  A one-off step of a few seconds would trumpet the
change in time keeping.

-- 
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman at westerngeco.com    -./\.-   the opinion of Schlumberger or
http://petef.22web.net           -./\.-   WesternGeco.


From cowan at ccil.org  Fri Dec 19 12:34:15 2008
From: cowan at ccil.org (John Cowan)
Date: Fri, 19 Dec 2008 12:34:15 -0500
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
Message-ID: <20081219173414.GC389@mercury.ccil.org>

Rob Seaman scripsit:

> One supposes the lunar synodic period would be divided into 30 parts.

*One* may suppose it, but others have not, such as Manuel Garcia
O'Kelly-Davis, an actual (though fictional) resident of Luna, describing
the timescale discussions of the "Ad-Hoc Congress for Organization of
Free Luna":

	Another time they argued "time."  Sure, Greenwich time
	bears no relation to lunar.  But why should it when we live
	underground?  Show me loonie who can sleep two weeks and
	work two weeks; lunars don't fit our metabolism.  What was
	urged was to make a lunar exactly equal to twenty-eight days
	(instead of 29 days, 12 hours, 44 minutes, 2.78 seconds)
	and do this by making days longer--and hours, minutes,
	and seconds, thus making each semi-lunar exactly two weeks.

	Sure, lunar is necessary for many purposes.  Controls when
	we go up on surface, why we go, and how long we stay.  But,
	aside from throwing us out of gear with our only neighbor,
	had that wordy vacuum skull thought what this would do
	to every critical figure in science and engineering?  As
	an electronics man I shuddered. Throw away every book,
	table, instrument, and start over?  I know that some of my
	ancestors did that in switching from old English units to
	MKS--but they did it to make things easier.  Fourteen inches
	to a foot and some odd number of feet to a mile.  Ounces
	and pounds.  Oh, Bog!

	Made sense to change that--but why go out of your way to
	create confusion?

> >The World Series does seem an egregiously stupid name, though.
> 
> No - they simply ought to extend it to teams from Japan and the  
> Dominican Republic, etc.

But that wouldn't be the World Series, it would be another thing by
the same name; a thing which arguably should exist, but not meeting
the original issue, which can be met only by rectification of the name.

-- 
John Cowan      cowan at ccil.org         http://www.ccil.org/~cowan
Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler

From seaman at noao.edu  Fri Dec 19 18:42:00 2008
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 19 Dec 2008 16:42:00 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081219173414.GC389@mercury.ccil.org>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
Message-ID: <F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>

On Dec 19, 2008, at 10:34 AM, John Cowan wrote:

> Rob Seaman scripsit:
>
>> One supposes the lunar synodic period would be divided into 30 parts.
>
> *One* may suppose it, but others have not, such as Manuel Garcia
> O'Kelly-Davis, an actual (though fictional) resident of Luna,  
> describing
> the timescale discussions of the "Ad-Hoc Congress for Organization of
> Free Luna":
>
> 	Another time they argued "time."  Sure, Greenwich time
> 	bears no relation to lunar.  But why should it when we live
> 	underground?  Show me loonie who can sleep two weeks and
> 	work two weeks; lunars don't fit our metabolism.  What was
> 	urged was to make a lunar exactly equal to twenty-eight days
> 	(instead of 29 days, 12 hours, 44 minutes, 2.78 seconds)
> 	and do this by making days longer--and hours, minutes,
> 	and seconds, thus making each semi-lunar exactly two weeks.

So the two things that would be preserved (in addition to honoring the  
lunar day/night cycle), are sexagesimal notation and the 7-day week?   
I wonder if Heinlein even realized his tunnel vision here?  At any  
rate, I'm skeptical that a cycle of 25h19m (in SI units) would be  
physiologically acceptable even without the next point:

> 	Sure, lunar is necessary for many purposes.  Controls when
> 	we go up on surface, why we go, and how long we stay.  But,
> 	aside from throwing us out of gear with our only neighbor,
> 	had that wordy vacuum skull thought what this would do
> 	to every critical figure in science and engineering?  As
> 	an electronics man I shuddered. Throw away every book,
> 	table, instrument, and start over?  I know that some of my
> 	ancestors did that in switching from old English units to
> 	MKS--but they did it to make things easier.  Fourteen inches
> 	to a foot and some odd number of feet to a mile.  Ounces
> 	and pounds.  Oh, Bog!
>
> 	Made sense to change that--but why go out of your way to
> 	create confusion?

The underlying alternatives outlined in the 1999 GPS World article  
(and in my screed http://iraf.noao.edu/~seaman/leap) remain.  To  
synchronize two clocks (Earth and Lunar in this case), you can adjust  
the rates on one end or the other, or you can reset the zero point of  
one or the other on some sort of schedule.  Additionally, if the  
differential rates continue to vary, then the scheduling has to vary.   
If the clock rates are too far apart, the best solution is to put two  
clocks on the wall.  (Most of the arguments over the past five years  
are equivalent to a requirement to label the clocks correctly.  Don't  
call it UTC if it isn't UTC.)

It is only that the SI second (essen) and the civil second (1/86400 of  
a mean solar day) are still very close that a scheme of ignoring the  
whole thing for a few generations can even be entertained.  If the SI  
second had been chosen (as it arguably should have been) to be some  
different, non-denumerable duration, then we would be worrying about  
civil timekeeping as the entirely separate issue that it is.

This idea reaches back to the dawn of precision timekeeping.   
Harrison's #4 clock succeeded where the first three failed because he  
stopped trying to build a perfect clock, and instead chose to  
calibrate imperfect chronometers.  His navigational solution would  
have worked perfectly fine if the rate of the chronometer was quite  
distinct from the diurnal rate.

Similarly, if sexagesimal were reserved for angles (like mean solar  
time), instead of being misused for interval timing, issues as above  
would be simplified because Heinlein wouldn't need to fret  
unnecessarily over scientific and engineering units.  My copy of "The  
Moon is a Harsh Mistress" is in some box in the garage.  I gather the  
passage is implying that the loonies simply use GMT, rather than  
lunations (other than that this matters for "many purposes") or trying  
to use the "rationalized" 28-day units?

The key issue in the passage above is the implicit meaning for  
timekeeping on Earth, not the Moon.

(Any good quotes from Clarke or Asimov?  Heinlein is always a bit too  
concerned with his underlying political agenda to focus on details of  
technology for its own sake.)

Rob


From sla at ucolick.org  Sat Dec 20 11:03:57 2008
From: sla at ucolick.org (Steve Allen)
Date: Sat, 20 Dec 2008 08:03:57 -0800
Subject: [LEAPSECS] (no subject)
Message-ID: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>

> In addition to what John Cowan said, I'd also point out that planning
> is the one of the biggest issues with leap seconds.
>
> In terms of planning for the future, if an application cares about
> local time, not knowing whether a leap second is going to happen
> outside a six month window can be a much larger problem than handling
> sliding time zones that would happen much less frequently and, one
> would think, with considerably more advance notice.
>
> For those that are in favor of the current system of leap seconds, it
> might be more effective to pretend that people don't have to plan for
> the future than to remind them in the opening sentence.


Please identify the operations which need one second predictability
over a time span of six months.  They can't be scheduling a meeting,
for a time zone change might be decreed.  They can't be launching  
shuttle
to rendezvous with ISS, for the solar activity will drag the atmosphere
by more than that much.
What are these applications?

For these operations please explain why the timing demands of the
system did not already recognize that they needed to design a
GPS time receiver into the applications.  (As we've just read, the
geodecists recognized that the technical aspects of using GPS
outweighed any bureaucratic mandate to use a time scale with an
international recommendation behind it.)

And to the more general audience than John Hein...

Please explain why using the name UTC for something with different
characteristics and applications is more important than the history
and art embodied in Dennis di Cicco's analemma
http://www.twanight.org/newTWAN/photos.asp?ID=3001422

Please explain why changing the name of the broadcast time scale
to TI and putting UTC and the leap seconds into zoneinfo does
not satisfy all requirements of the need for uniform time scale.

Please explain why the recommendations of the assembly of world
time experts at Torino in 2003 are not valid even after it has
been pointed out that zoneinfo provides a mechanism for implementing
them.

If the objections are about presumptions of computer code with respect
to scheduling something for the same civil time tomorrow please identify
code systems which correctly implement the sorts of things seen here
http://www.webexhibits.org/daylightsaving/g.html
and discuss the relative number of systems which already get it wrong.

I want to know why I should give up the notion of civil time being
based on mean solar time, for myself and for posterity.

--
Steve Allen                 <sla at ucolick.org>                WGS-84  
(GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat   
+36.99855
University of California    Voice: +1 831 459 3046           Lng  
-122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m






From phk at phk.freebsd.dk  Sat Dec 20 11:36:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 20 Dec 2008 16:36:30 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Sat, 20 Dec 2008 08:03:57 PST."
	<006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org> 
Message-ID: <47945.1229790990@critter.freebsd.dk>

In message <006D7A34-31D9-4492-9014-667C7B92612C at ucolick.org>, Steve Allen writ
es:

>Please identify the operations which need one second predictability
>over a time span of six months.

Wrong question.

Try:  Please identify computer communications where it is not guaranteed
that all involved computers will have their software updated every
six months.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sat Dec 20 11:48:32 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 09:48:32 -0700
Subject: [LEAPSECS] Schedule for success (was Re:  (no subject))
In-Reply-To: <47945.1229790990@critter.freebsd.dk>
References: <47945.1229790990@critter.freebsd.dk>
Message-ID: <D754EF5C-767A-4FF0-AC64-6E9543AAA62A@noao.edu>

Poul-Henning Kamp wrote:

> Steve Allen writes:
>
>> Please identify the operations which need one second predictability  
>> over a time span of six months.
>
> Wrong question.
>
> Try:  Please identify computer communications where it is not  
> guaranteed that all involved computers will have their software  
> updated every six months.

Meant as a bon mot, I guess?  Seems to emphasize Steve's point in any  
event.

However, you've actually identified a potential mechanism for  
distributing scheduling data of all sorts, including for leap  
seconds.  Instead of building computer hardware, operating systems and  
applications that pretend the relentless update cycle doesn't exist,  
build such systems to expect scheduled updates to software and key  
data structures.  Leap seconds are just one from a large class of non- 
static information that needs to be widely shared in common for  
infrastructure to work.

Perhaps my frequent observations about the wisdom of following system  
engineering best practices simply need to be redirected to a broader  
class of problem to find more acceptance :-)

Rob


From phk at phk.freebsd.dk  Sat Dec 20 11:52:29 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 20 Dec 2008 16:52:29 +0000
Subject: [LEAPSECS] Schedule for success (was Re: (no subject))
In-Reply-To: Your message of "Sat, 20 Dec 2008 09:48:32 MST."
	<D754EF5C-767A-4FF0-AC64-6E9543AAA62A@noao.edu> 
Message-ID: <47998.1229791949@critter.freebsd.dk>

In message <D754EF5C-767A-4FF0-AC64-6E9543AAA62A at noao.edu>, Rob Seaman writes:

>Instead of building computer hardware, operating systems and  
>applications that pretend the relentless update cycle doesn't exist,  
>build such systems to expect scheduled updates to software and key  
>data structures.

Great idea!

As a system programmer I would love that.

Why don't you take that idea to to Airbus, Boeing, Lockheed, the
FAA, NRC and the nuclear powerplant industry ?

I am sure they are more than eager to get their EAL processes given
a workout every six months.

Let me know the pricetag they slap on your proposal.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From greg.hennessy at cox.net  Sat Dec 20 12:16:54 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Sat, 20 Dec 2008 12:16:54 -0500
Subject: [LEAPSECS] Schedule for success (was Re: (no subject))
In-Reply-To: <47998.1229791949@critter.freebsd.dk>
References: <47998.1229791949@critter.freebsd.dk>
Message-ID: <494D2886.5020004@cox.net>


> Why don't you take that idea to to Airbus, Boeing, Lockheed, the
> FAA, NRC and the nuclear powerplant industry ?

When they complain, we will.


From imp at bsdimp.com  Sat Dec 20 12:46:40 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 10:46:40 -0700 (MST)
Subject: [LEAPSECS] (no subject)
In-Reply-To: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
Message-ID: <20081220.104640.437128889.imp@bsdimp.com>

In message: <006D7A34-31D9-4492-9014-667C7B92612C at ucolick.org>
            Steve Allen <sla at ucolick.org> writes:
: I want to know why I should give up the notion of civil time being
: based on mean solar time, for myself and for posterity.

Leap-seconds, as implement, are unworkable.  You can see long messages
from me in the past enumerating the reasons relating to systems,
especially systems disconnected from the internet...

Leap-seconds, the concept, have a limited shelf life.  Maybe only a
few thousands years.  So there's nothing really to preserve.  One day
they must be abandoned.

As soon as we fixed the length of a second based on atomic behavior
rather than as 1/86400th of a mean solar day, we really abandoned time
based on mean solar time.  Leap seconds are at best a hack to paper
over this fundamental decision.

Warner

From seaman at noao.edu  Sat Dec 20 13:01:03 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 11:01:03 -0700
Subject: [LEAPSECS] Schedule for success (was Re: (no subject))
In-Reply-To: <47998.1229791949@critter.freebsd.dk>
References: <47998.1229791949@critter.freebsd.dk>
Message-ID: <21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>

Poul-Henning Kamp wrote:

> In message <D754EF5C-767A-4FF0-AC64-6E9543AAA62A at noao.edu>, Rob  
> Seaman writes:
>
>> Instead of building computer hardware, operating systems and
>> applications that pretend the relentless update cycle doesn't exist,
>> build such systems to expect scheduled updates to software and key
>> data structures.
>
> Great idea!
>
> As a system programmer I would love that.
>
> Why don't you take that idea to to Airbus, Boeing, Lockheed, the
> FAA, NRC and the nuclear powerplant industry ?
>
> I am sure they are more than eager to get their EAL processes given
> a workout every six months.
>
> Let me know the pricetag they slap on your proposal.

But you're the one who brought up the issue of updates occurring every  
six months.  If this is indeed going to happen, we are surely better  
off planning for it.  The plan would certainly include the possibility  
of certain systems opting out.  Again - it is better to plan special  
cases than to simply fail to accommodate frozen (in whatever regard)  
legacy systems in your update process.

At any rate, aircraft and ATC already go through a well controlled set  
of update procedures before every takeoff.  If updating a table of  
leap seconds, for instance, were critical to flight operations, then  
this could be accommodated at any frequency between maintenance cycles  
several times a year and operations cycles several times a day.  Data  
with at least as high a level of criticality as leap seconds are  
updated over and over again on aircraft.

I indicated that such data tables *could* be accommodated within a  
well managed software update schedule.  These could also be updated  
according to other schedules.  There is nothing special about a table  
of retrospective and predicted leap seconds compared to all sorts of  
other non-static procedural information describing public policies.

And whatever the pricetag is, it can't be zeroed out by attempting to  
ignore an issue that is intrinsic to the problem at hand.

Rob


From imp at bsdimp.com  Sat Dec 20 13:35:38 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 11:35:38 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <494D2886.5020004@cox.net>
References: <47998.1229791949@critter.freebsd.dk>
	<494D2886.5020004@cox.net>
Message-ID: <20081220.113538.-1237388223.imp@bsdimp.com>

In message: <494D2886.5020004 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: > Why don't you take that idea to to Airbus, Boeing, Lockheed, the
: > FAA, NRC and the nuclear powerplant industry ?
: 
: When they complain, we will.

When you do business with these sorts of people, they have clauses in
their contracts that effectively put the kabash on this whole idea.
They state up front that this is a non-starter.

Warner

From imp at bsdimp.com  Sat Dec 20 13:33:57 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 11:33:57 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <D754EF5C-767A-4FF0-AC64-6E9543AAA62A@noao.edu>
References: <47945.1229790990@critter.freebsd.dk>
	<D754EF5C-767A-4FF0-AC64-6E9543AAA62A@noao.edu>
Message-ID: <20081220.113357.1976893189.imp@bsdimp.com>

In message: <D754EF5C-767A-4FF0-AC64-6E9543AAA62A at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Poul-Henning Kamp wrote:
: 
: > Steve Allen writes:
: >
: >> Please identify the operations which need one second predictability  
: >> over a time span of six months.
: >
: > Wrong question.
: >
: > Try:  Please identify computer communications where it is not  
: > guaranteed that all involved computers will have their software  
: > updated every six months.
: 
: Meant as a bon mot, I guess?  Seems to emphasize Steve's point in any  
: event.
: 
: However, you've actually identified a potential mechanism for  
: distributing scheduling data of all sorts, including for leap  
: seconds.  Instead of building computer hardware, operating systems and  
: applications that pretend the relentless update cycle doesn't exist,  
: build such systems to expect scheduled updates to software and key  
: data structures.  Leap seconds are just one from a large class of non- 
: static information that needs to be widely shared in common for  
: infrastructure to work.

Sadly this is well divorced from reality.  People can and do build
systems that have a long shelf life.  It is routine in certain sectors
to buy 10 of something and put 8 into the field.  The other 2 are
spares and sit on the shelf for a long period of time.  The software
is rarely updated on systems like this (why should it be, they are
simple and bug-free enough to run for years).  These systems are
expected to run for 10 years with < .001% (so called 5 9's) downtime.
Upgrades make that nearly impossible to meet.

When one fails, another one gets swapped in.  Otherwise the system is
up all the time.  To force an upgrade every 6 months would force a
down time, which is unacceptable.  It would also, in many cases, for
someone to physically go to the location where the systems are running
to do the upgrade since many of these systems aren't on public
networks (and the private ones are oversubscribed with their current
data loads, no room for extra software updates).

The non-regularity of leap seconds makes this very hard to do.  Even
with a GPS receiver in hand, it can be hard to start cold, and there's
no way to startup reliably if you've been off as little as one year.
These systems routinely exchange data with timestamps, some of which
is historical.  Without leapsecond knowledge, you get degraded
performance.  Systems that are off for a year have no clue when the
last leapsecond(s) were, unless there weren't any in that time.  This
can and does lead to degraded performance in some cases.

: Perhaps my frequent observations about the wisdom of following system  
: engineering best practices simply need to be redirected to a broader  
: class of problem to find more acceptance :-)

Except, of course, in this case good system engineering is that these
systems will run, unattended (and unnetworked), for years doing the
job they need to do.  To force them all to upgrade just because of
leap seconds is silly.

You've constantly poo-pooed the notion that people that have actually
written and deployed dozens of these systems know what they are
talking about.  You all but call such people morons for not following
good system engineering practices.  Yet, you show a surprising
ignorance of how things actually work and of system engineering
practices demanded by customers.

The root cause of all of this is the irregularity of the scheduling of
leap seconds.  If they were on a schedule, known years in advance,
then these systems could be built.

Imagine if you have to find out from the pope every year if this year
was going to be a leap year or not?  There's all kinds of problems
*THAT* would cause, and nobody would debate it....

Warner

From imp at bsdimp.com  Sat Dec 20 13:39:09 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 11:39:09 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
References: <47998.1229791949@critter.freebsd.dk>
	<21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
Message-ID: <20081220.113909.324381192.imp@bsdimp.com>

You are under the fundamental misimpression that all systems are or
can be upgraded every 6 months.  That simply isn't possible for a
large class of systems.

So everything else that follows this fundamental flaw in reasoning is
therefore fundamentally flawed.

Warner

From seaman at noao.edu  Sat Dec 20 13:45:49 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 11:45:49 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <20081220.104640.437128889.imp@bsdimp.com>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
	<20081220.104640.437128889.imp@bsdimp.com>
Message-ID: <490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>

M. Warner Losh wrote:

> Leap-seconds, as implement, are unworkable.

If so, there are worlds of possibilities short of the vain attempt to  
eradicate them entirely.

> You can see long messages from me in the past enumerating the  
> reasons relating to systems, especially systems disconnected from  
> the internet...

Systems (still unenumerated) that require real-time access to actual  
"UT" (a flavor of GMT), will have this same exact issue, but the ITU  
proposal does nothing to plan for a replacement.  Rather, it demands  
that the current DUT1 mechanism be abandoned.

As other long messages point out, it is simply not true that most or  
many or more than a very small fraction of systems need real-time leap  
second updates.

Ultimately, even non-realtime systems will suffer as vast numbers of  
embargoed leap seconds pile up.  These will have to be released  
eventually.  What is the plan for doing so?  Include that plan in any  
proposal to change the status quo.

> Leap-seconds, the concept, have a limited shelf life.  Maybe only a
> few thousands years.  So there's nothing really to preserve.  One day
> they must be abandoned.

The current standard is workable for at least hundreds of years.  What  
is the hurry to vote on this issue without reaching consensus first?   
Could it be that the proponents don't believe the current proposal is  
coherent enough to win over converts outside of their own special  
interests?  Whatever action might be taken, plan the evolving standard  
fully before taking it.

> As soon as we fixed the length of a second based on atomic behavior
> rather than as 1/86400th of a mean solar day, we really abandoned time
> based on mean solar time.

Civil time is and will remain a flavor of mean solar time.  If you  
believe otherwise, muster arguments for how this assertion fails to be  
true.  It is a basic requirement of any replacement that the clock not  
drift willy-nilly, but rather be accommodated by some well thought out  
plan.  It isn't the astronomers on this list who have been unwilling  
to consider alternative proposals.

> Leap seconds are at best a hack to paper over this fundamental  
> decision.

No - inappropriate attempts to apply interval timescales to civil  
timekeeping are the real kludge.  The issue remains the conflation of  
the two distinct concepts of the SI second with the civil second  
(1/86400 of a day).  This is a naive attempt at redefining the  
fundamental concept of the day.

Even if we evolve into mole-people living underground and losing the  
power of sight, an intelligent species will never abandon civil  
timekeeping based on mean solar time.  Diurnal rhythms abound  
throughout our society and its infrastructure.  All the confusion  
about zero point shifts is a red herring.  The issue is that the mean  
solar rate has to be maintained.  It is a strange position for  
precision timekeepers to take that a residual rate of milliseconds per  
day should be regarded as negligible.  We can cheat the sun for a  
while - but only for a while.

There are two kinds of time, interval and earth orientation.  Whatever  
the ITU rules at some future meeting these must be kept straight - and  
civil timekeeping depends much more on earth orientation than on  
interval timing.  If there are problems with interval timekeeping,  
then civil time is not the right place to address them.  Separate the  
two sets of issues and the proper solution(s) will become easier to  
design and deploy.

Rob

From imp at bsdimp.com  Sat Dec 20 13:55:02 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 11:55:02 -0700 (MST)
Subject: [LEAPSECS] (no subject)
In-Reply-To: <490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
	<20081220.104640.437128889.imp@bsdimp.com>
	<490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>
Message-ID: <20081220.115502.1057479243.imp@bsdimp.com>

In message: <490A82A4-A8B3-485E-8DED-F9C8ADC894F7 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > Leap-seconds, as implement, are unworkable.
: 
: If so, there are worlds of possibilities short of the vain attempt to  
: eradicate them entirely.

Dude, stop misrepresenting my position.

Either we kill them entirely, since they are going away eventually
anyway, or we put them on a regular schedule like leap years.  The
current system sucks too bad to be allowed to continue.

Like this silly discussion, leap seconds take a hugely
disproportionate amount of time and money in the implementation of
timing systems that I've been involved in.

All the rest is polemics..

Warner

From seaman at noao.edu  Sat Dec 20 14:31:31 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 12:31:31 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081220.113357.1976893189.imp@bsdimp.com>
References: <47945.1229790990@critter.freebsd.dk>
	<D754EF5C-767A-4FF0-AC64-6E9543AAA62A@noao.edu>
	<20081220.113357.1976893189.imp@bsdimp.com>
Message-ID: <4957DFE1-9C18-4941-AA87-79E5DD429E5B@noao.edu>

Scroll down for my response.  Context seemed important.

On Dec 20, 2008, at 11:33 AM, M. Warner Losh wrote:

> In message: <D754EF5C-767A-4FF0-AC64-6E9543AAA62A at noao.edu>
>            Rob Seaman <seaman at noao.edu> writes:
> : Poul-Henning Kamp wrote:
> :
> : > Steve Allen writes:
> : >
> : >> Please identify the operations which need one second  
> predictability
> : >> over a time span of six months.
> : >
> : > Wrong question.
> : >
> : > Try:  Please identify computer communications where it is not
> : > guaranteed that all involved computers will have their software
> : > updated every six months.
> :
> : Meant as a bon mot, I guess?  Seems to emphasize Steve's point in  
> any
> : event.
> :
> : However, you've actually identified a potential mechanism for
> : distributing scheduling data of all sorts, including for leap
> : seconds.  Instead of building computer hardware, operating systems  
> and
> : applications that pretend the relentless update cycle doesn't exist,
> : build such systems to expect scheduled updates to software and key
> : data structures.  Leap seconds are just one from a large class of  
> non-
> : static information that needs to be widely shared in common for
> : infrastructure to work.
>
> Sadly this is well divorced from reality.  People can and do build
> systems that have a long shelf life.  It is routine in certain sectors
> to buy 10 of something and put 8 into the field.  The other 2 are
> spares and sit on the shelf for a long period of time.  The software
> is rarely updated on systems like this (why should it be, they are
> simple and bug-free enough to run for years).  These systems are
> expected to run for 10 years with < .001% (so called 5 9's) downtime.
> Upgrades make that nearly impossible to meet.
>
> When one fails, another one gets swapped in.  Otherwise the system is
> up all the time.  To force an upgrade every 6 months would force a
> down time, which is unacceptable.  It would also, in many cases, for
>>
> someone to physically go to the location where the systems are running
> to do the upgrade since many of these systems aren't on public
> networks (and the private ones are oversubscribed with their current
> data loads, no room for extra software updates).

You are arguing with Poul-Henning, not with me.

Just a reminder that not only are astronomers big-time customers for  
*both* high precision interval timescales *and* high accuracy earth  
orientation timescales, but we *also* have some of the more bizarre  
requirements for high reliability, remotely located, long shelf life  
systems such as you describe.

Again - why are engineering best practices regarded as an annoyance?   
If the real world places a requirement on a system (like - SI seconds  
are not civil seconds), then a better solution will result from  
actually designing this into the system up front.  Perhaps this will  
require an update every 6 months.  Perhaps it can be longer than  
that.  Perhaps autonomous, adaptive scheduling can be built in.

Trying to pretend the requirement doesn't exist is naive decision- 
making at its worst.  One can't claim that systems resulting from such  
a decision-making process have been engineered in any real sense at all.

> The non-regularity of leap seconds makes this very hard to do.  Even
> with a GPS receiver in hand, it can be hard to start cold, and there's
> no way to startup reliably if you've been off as little as one year.
> These systems routinely exchange data with timestamps, some of which
> is historical.  Without leapsecond knowledge, you get degraded
> performance.  Systems that are off for a year have no clue when the
> last leapsecond(s) were, unless there weren't any in that time.  This
> can and does lead to degraded performance in some cases.

What are those cases?  Use cases drive requirements.  If we weren't  
perpetually trying to squelch the inappropriate rush to a decision of  
the ITU, we could focus on the actual system engineering issues.

> Except, of course, in this case good system engineering is that these
> systems will run, unattended (and unnetworked), for years doing the
> job they need to do.  To force them all to upgrade just because of
> leap seconds is silly.

You are describing another requirement for untended operation.   
Requirements aren't a zero-sum game with one winning over another.   
Rather, a coherent set of requirements have to all be honored in a  
conforming solution.  I said the exact opposite of demanding that they  
update.  However, if as PHK says, many systems have to update  
frequently, those that do could use this as an opportunity to update  
broad categories of data tables - not just leap seconds.  Those small  
number that can't use this commercial update regime, will still  
benefit from following a coherent plan.

Truly untended, unnetworked systems likely have no requirement to use  
UTC in the first place.  An instrumentality of mankind that is  
disjoint from the rest of civilization may need timekeeping, but  
likely doesn't need civil timekeeping.

> You've constantly poo-pooed the notion that people that have actually
> written and deployed dozens of these systems know what they are
> talking about.  You all but call such people morons for not following
> good system engineering practices.  Yet, you show a surprising
> ignorance of how things actually work and of system engineering
> practices demanded by customers.

Customers pay for solutions.  Solutions require problems to be  
defined.  That definition benefits from engineering.  A customer might  
attempt to specify an engineering process. (Although it seems more  
likely that they would specify some widely known best practice  
engineering process, rather than some ad hoc abrogation of same.)  A  
vendor or engineering firm should take the customer's specifications  
into account when preparing a proposal.  A wise engineering firm won't  
accept a job with unrealistic strings attached.

I don't believe I've called anybody a moron.  I apologize if so.   
Otherwise, I am not responsible for the inferences of others to what  
truly seem to me to be unremarkable statements regarding the  
engineering of systems.  Naive solutions are bad.  Proper engineering  
is the best way to avoid naive solutions.  Why is this controversial?

It is my college logic professor you are arguing with if the assertion  
is that one should defer to experts simply because they are experts.   
However, folks do understand perhaps that the astronomers contributing  
to this list are predominately members of the astronomical software  
community and are experts themselves?

I'm not sure what "these systems" refers to, but timekeeping has often  
been a key element of systems I've designed and deployed.  I'm well  
aware of the mistakes I've made over the years.  My goal is to keep  
the ITU from making one big whopper of a mistake revising this general  
standard.  Unless I sit on a design review for a specific system, I  
don't have an opinion about the process design choices for that system.

> The root cause of all of this is the irregularity of the scheduling of
> leap seconds.  If they were on a schedule, known years in advance,
> then these systems could be built.

And several of us from the astronomy software side have expressed  
interest in exploring options for lengthening the schedule.  My  
reading of the current UTC standard is that this might even be  
completely acceptable with no ITU or government level changes.   
Wouldn't this be even easier and quicker to implement than the goal of  
eradicating leap seconds, a goal that cannot (apparently) be reached  
before 2019?

> Imagine if you have to find out from the pope every year if this year
> was going to be a leap year or not?  There's all kinds of problems
> *THAT* would cause, and nobody would debate it....

And yet that is exactly the case with time zones and daylight saving  
adjustments.  Any government anywhere can change these far more  
visible policies at anytime.  The sliding time zone solution would  
magnify this reality at a quadratically increasing cadence worldwide.

Rob

From seaman at noao.edu  Sat Dec 20 14:51:08 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 12:51:08 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <20081220.115502.1057479243.imp@bsdimp.com>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
	<20081220.104640.437128889.imp@bsdimp.com>
	<490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>
	<20081220.115502.1057479243.imp@bsdimp.com>
Message-ID: <20A20210-28FB-4237-8FE5-32FBAAD7F823@noao.edu>

Dude, I'm not representing your position at all.  Assertions are  
made.  I respond.  The "current system" for instance, is simply the  
mechanics of the solar system.  It will remain the underlying system  
whatever the ITU decides.  What is your position on the solar system?   
I don't know.  (Personally, I'm all for it.)

On the other hand, you've spent the last few messages taking offense  
at insults I've never uttered and misrepresenting PHK's jocular  
comment as my own.

Leap seconds principally take time and money because people have  
selected UTC for some purpose requiring an interval timescale.  The  
advice seems pretty obvious - don't use UTC.  There is no "one size  
fits all" timescale.  Attempts to create one will fail.

If you think it is a silly discussion, why keep returning to it?  On  
the other hand, my observatory has just undergone a round of  
downsizing due to the poor economy.  If the ITU succeeds in their (far  
more silly) exercise of removing leap seconds from UTC, it will cost  
the astronomical community millions of dollars worldwide - perhaps  
many millions of dollars.  (When you mention remote untended systems,  
few are more so than space-based telescopes.)  Those millions of  
dollars will inevitably result in many more layoffs since not once has  
any suggestion been made of compensating astronomers for the cost of  
such a change to the standard.  Thus I continue my part in what seems  
rather more a threatening, than a silly, discussion.

Rob
---

On Dec 20, 2008, at 11:55 AM, M. Warner Losh wrote:

> In message: <490A82A4-A8B3-485E-8DED-F9C8ADC894F7 at noao.edu>
>            Rob Seaman <seaman at noao.edu> writes:
> : M. Warner Losh wrote:
> :
> : > Leap-seconds, as implement, are unworkable.
> :
> : If so, there are worlds of possibilities short of the vain attempt  
> to
> : eradicate them entirely.
>
> Dude, stop misrepresenting my position.
>
> Either we kill them entirely, since they are going away eventually
> anyway, or we put them on a regular schedule like leap years.  The
> current system sucks too bad to be allowed to continue.
>
> Like this silly discussion, leap seconds take a hugely
> disproportionate amount of time and money in the implementation of
> timing systems that I've been involved in.
>
> All the rest is polemics..
>
> Warner


From phk at phk.freebsd.dk  Sat Dec 20 14:53:42 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 20 Dec 2008 19:53:42 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sat, 20 Dec 2008 12:31:31 MST."
	<4957DFE1-9C18-4941-AA87-79E5DD429E5B@noao.edu> 
Message-ID: <48637.1229802822@critter.freebsd.dk>

In message <4957DFE1-9C18-4941-AA87-79E5DD429E5B at noao.edu>, Rob Seaman writes:


>Again - why are engineering best practices regarded as an annoyance?   

Rob,

They are not, but they are far different from what you think
they are, and they are slavishly adhered to.

I know several astronomers, including the one who I think were the
first to use a computer observationally.

And they are a really cool crew, and fun to be with, but they
wouldn't last 10 minutes in the real IT world.

None of them, and obviously you in particular, have any idea what
"safety of life" means in an IT context.

Yeah, sure: you could knock a phd out cold with a radio-telescope,
but that is just an average industrial accident, that has nothing
to do with computers really.

Real "safety of life" systems often must be approved by several
authorities, and tested to predetermined and randomized scenarios,
and then, likely as not, you will end up not rolling them out,
likely for several months, because some other issue, anomaly or
just operational pattern prevents it.

Getting a new OS rolled out under an ATC system every six months ?

F'get it buddy, not even close, lets talk about it in 2012, OK ?

And you know what ?

That _is_ good engineering practice for systems like that: you do
not risk blacking out an entire ATC sector, just because some raving
astronomer cannot find stars with his telescope.

Dream on in your own little world, Rob, but please stop thinking
that the rest of the world is like your sandbox.

Poul-Henning

(Who has waited 3 months for the paperwork to move, so he can install
patch which changes the color of a touch panel button in an ATC
system.)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sat Dec 20 17:21:39 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 15:21:39 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48637.1229802822@critter.freebsd.dk>
References: <48637.1229802822@critter.freebsd.dk>
Message-ID: <B00E39AF-B2CE-4828-9DFF-E6EDE16DD6B4@noao.edu>

Poul-Henning Kamp wrote to start this thread:

> Please identify computer communications where it is not guaranteed
> that all involved computers will have their software updated every
> six months.

Presumably this was at least half humorous, but I took the chance to  
point out that if this were true (or indeed any other enforced update  
schedule), one could use this proactively to effectuate updates to the  
leap second list.  No enforced updates - no opportunity to exploit.

No big point - just one more minor discussion on the mailing list.

Now, Poul-Henning Kamp writes:

> In message <4957DFE1-9C18-4941-AA87-79E5DD429E5B at noao.edu>, Rob  
> Seaman writes:
>
>> Again - why are engineering best practices regarded as an annoyance?
>
> Rob,
>
> They are not, but they are far different from what you think
> they are, and they are slavishly adhered to.

"Slavishly" isn't an adjective to describe best practices of any  
sort.  You also appear to think that I'm seeking to continue the  
little side discussion about software updates.  Rather, my main point  
is that planning is good, in particular planning to change a civil  
timekeeping standard effecting the vast majority of clocks on the  
planet.

> I know several astronomers, including the one who I think were the
> first to use a computer observationally.
>
> And they are a really cool crew, and fun to be with, but they
> wouldn't last 10 minutes in the real IT world.

I won't waste time disputing which world is actually the real  
world :-)  But if you are asserting that your applications are more  
important than my applications, then my opinion is that your  
applications require better planning than mine do.

As far as the actual proposal were debating here, the one to change  
UTC.  Evaluate the economic costs.  Investigate the risks of all  
options.  Generate a plan for what happens at the inevitable point  
that the leap second embargo fails.  The current proposal is  
embarrassing in its lack of details.  Improve the proposal.

> None of them, and obviously you in particular, have any idea what
> "safety of life" means in an IT context.
>
> Yeah, sure: you could knock a phd out cold with a radio-telescope,
> but that is just an average industrial accident, that has nothing
> to do with computers really.

I won't belabor how many ways this might relate to computers.  But  
systems engineering isn't an esoteric technical discipline, nor is it  
the same thing as meeting reporting and other requirements for  
regulatory agencies.  Systems engineering is a pragmatic exploration  
of human and technological factors in relation to human goals.

> Real "safety of life" systems often must be approved by several
> authorities, and tested to predetermined and randomized scenarios,
> and then, likely as not, you will end up not rolling them out,
> likely for several months, because some other issue, anomaly or
> just operational pattern prevents it.

And a proposal equivalent to "1) stop issuing leap seconds, and 2)  
stop issuing DUT1 announcements, and 3) ignore everything else"  
somehow meets this test?

> Getting a new OS rolled out under an ATC system every six months ?
>
> F'get it buddy, not even close, lets talk about it in 2012, OK ?

Ok, then next time you shouldn't initiate such a rhetorical argument  
in that case :-)  I've spent the last half dozen messages making a  
completely different point over and over.  Let's move on to something  
else.

> And you know what ?
>
> That _is_ good engineering practice for systems like that: you do
> not risk blacking out an entire ATC sector, just because some raving
> astronomer cannot find stars with his telescope.

Nobody has spent a dime on investigating possible risks involved in  
aircraft navigation.  This discussion has never been about astronomers  
(other than the unfunded costs to simply maintain our current  
capabilities).

Rather it is about civil timekeeping as in civil aviation and every  
other aspect of modern society.  The assertion that absolutely nothing  
about aviation could possibly care about mean solar time is something  
that could and should be tested before proceeding to change the UTC  
standard.  Has anybody even started by grepping for strings like  
"DUT1" in the source code for any of these systems?

> (Who has waited 3 months for the paperwork to move, so he can install
> patch which changes the color of a touch panel button in an ATC
> system.)

So the color of a button should receive more attention than the clocks  
ensuring that airplanes don't collide?

I remain fascinated that after all my flights of fancy, the one  
talking point that receives such a staunchly negative response is a  
simple suggestion to generate a realistic and at least marginally  
complete proposal before voting on it.

Rob

From phk at phk.freebsd.dk  Sat Dec 20 17:32:43 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 20 Dec 2008 22:32:43 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sat, 20 Dec 2008 15:21:39 MST."
	<B00E39AF-B2CE-4828-9DFF-E6EDE16DD6B4@noao.edu> 
Message-ID: <49208.1229812363@critter.freebsd.dk>

In message <B00E39AF-B2CE-4828-9DFF-E6EDE16DD6B4 at noao.edu>, Rob Seaman writes:

>Nobody has spent a dime on investigating possible risks involved in  
>aircraft navigation.

That shows, if nothing else, the depth of your research.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From ashley at semantic.org  Sat Dec 20 18:22:07 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat, 20 Dec 2008 15:22:07 -0800
Subject: [LEAPSECS] (no subject)
In-Reply-To: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
Message-ID: <1229815327.12027.2.camel@glastonbury>

On Sat, 2008-12-20 at 08:03 -0800, Steve Allen wrote:
> I want to know why I should give up the notion of civil time being
> based on mean solar time, for myself and for posterity.

I believe the answer being argued is "the aerospace and nuclear
industries would save money".

-- 
Ashley Yakeley


From sla at ucolick.org  Sat Dec 20 20:45:55 2008
From: sla at ucolick.org (Steve Allen)
Date: Sat, 20 Dec 2008 17:45:55 -0800
Subject: [LEAPSECS] (no subject)
In-Reply-To: <20081220.115502.1057479243.imp@bsdimp.com>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
	<20081220.104640.437128889.imp@bsdimp.com>
	<490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>
	<20081220.115502.1057479243.imp@bsdimp.com>
Message-ID: <8D831340-BE80-4595-9E73-EAA3465A41B6@ucolick.org>


On 2008 Dec 20, at 10:55, M. Warner Losh wrote:
> Either we kill them entirely, since they are going away eventually
> anyway, or we put them on a regular schedule like leap years.  The
> current system sucks too bad to be allowed to continue.

Pardon me, but I'm missing something in this about the annoyance
of leap seconds.  I thought the trouble was that they interrupt the
broadcast time scale (which I distinguish from UTC).

If the ITU-R decides to bless a new time scale like TI, then POSIX
can take note and say as of then time_t is to be interpreted as the
internationally-blessed broadcast time scale named TI.  Bureacracy
that happens to have specified UTC can be reinterpreted on a case
by case basis to decide whether it wants TI or UTC, but in the
interim all the operational systems keep on working.

If leap seconds go into zoneinfo, then they are only as much nuisance
as when the political princes of the world decree a change in the
rules for time zones, and not even total unanimity within the ITU can
stop that.

I agree that the current system is dysfunctional.

I typically carry around 100 GB of storage, a GHz of processing
capability, and devices that can communicate with 4 different
wireless protocols.  That is how the world has changed since 1970
when everything was pencil, paper, and slide rule.  My devices can
receive something like TI, use it internally, and report to me something
with added timezone offsets.

But of those wireless protocols, one of them was entirely shut down
by the FCC before I had owned the device 5 years, so that one is defunct
and the hardware deserves replacement.

I don't want to see mean solar time abandoned because of the  
shortcomings
of systems with that sort of lifetime.

--
Steve Allen                 <sla at ucolick.org>                WGS-84  
(GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat   
+36.99855
University of California    Voice: +1 831 459 3046           Lng  
-122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m






From seaman at noao.edu  Sat Dec 20 21:16:48 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 20 Dec 2008 19:16:48 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <49208.1229812363@critter.freebsd.dk>
References: <49208.1229812363@critter.freebsd.dk>
Message-ID: <F065122B-DB4C-4CDC-B9DA-F55581DB5C7F@noao.edu>

On Dec 20, 2008, at 3:32 PM, Poul-Henning Kamp wrote:

> In message <B00E39AF-B2CE-4828-9DFF-E6EDE16DD6B4 at noao.edu>, Rob  
> Seaman writes:
>
>> Nobody has spent a dime on investigating possible risks involved in
>> aircraft navigation.
>
> That shows, if nothing else, the depth of your research.

I was obviously speaking (as I have for nine years) of the context of  
the limp yet relentless proposal to eviscerate UTC.  If somebody has  
references to risk analyses (for ATC or any other industry) of  
relayering UTC on something other than mean solar time, please share  
them with the list.  I'd be happy to delve deeper.

Turning the issue around, is there even a coherent such study of the  
effects of leap seconds on ATC (or any other industry)?  (Completely  
ignoring the question, if you will, of whether or not aircraft  
navigation might actually care about mean solar time.)

We're to understand that leap seconds "suck".  Wouldn't the obvious  
first step to motivating the need for a change be to demonstrate that  
such a problem actually exists?  And then to explore the scope of the  
issue and any external scheduling constraints?

Rob




From imp at bsdimp.com  Sun Dec 21 01:06:45 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 20 Dec 2008 23:06:45 -0700 (MST)
Subject: [LEAPSECS] (no subject)
In-Reply-To: <8D831340-BE80-4595-9E73-EAA3465A41B6@ucolick.org>
References: <490A82A4-A8B3-485E-8DED-F9C8ADC894F7@noao.edu>
	<20081220.115502.1057479243.imp@bsdimp.com>
	<8D831340-BE80-4595-9E73-EAA3465A41B6@ucolick.org>
Message-ID: <20081220.230645.-432836952.imp@bsdimp.com>

In message: <8D831340-BE80-4595-9E73-EAA3465A41B6 at ucolick.org>
            Steve Allen <sla at ucolick.org> writes:
: 
: On 2008 Dec 20, at 10:55, M. Warner Losh wrote:
: > Either we kill them entirely, since they are going away eventually
: > anyway, or we put them on a regular schedule like leap years.  The
: > current system sucks too bad to be allowed to continue.
: 
: Pardon me, but I'm missing something in this about the annoyance
: of leap seconds.  I thought the trouble was that they interrupt the
: broadcast time scale (which I distinguish from UTC).

That's one of many problems.

: If the ITU-R decides to bless a new time scale like TI, then POSIX
: can take note and say as of then time_t is to be interpreted as the
: internationally-blessed broadcast time scale named TI.  Bureacracy
: that happens to have specified UTC can be reinterpreted on a case
: by case basis to decide whether it wants TI or UTC, but in the
: interim all the operational systems keep on working.

I'd have to think about this carefully to make sure that it would
work, but there's still at least one problem if UTC is still around...

: If leap seconds go into zoneinfo, then they are only as much nuisance
: as when the political princes of the world decree a change in the
: rules for time zones, and not even total unanimity within the ITU can
: stop that.

There's three issues with this.  First, long running programs
(programs that run for years) will force the libraries that cope with
these files to stat them from time to time to make sure that there
isn't a new update (otherwise your time will be 1s off).  Second, many
programs need to run over leap seconds still and behave properly.
Third, you never know if you have the right, up to date files when you
startup (think systems that are cold spares that have been on the
shelf for a year).  How do you reconcile that?

Also, there's silly operational things like "how do I update these
files if there's no vendor to update them?" which is a matter of
programming.  And do I let anybody update them?  What if my GPS
control program wants to do it?  What if ntpd wants to do it (assuming
it goes to TI)?  What if they both want to do it and the data are
unconsistent?  You still have to figure out who to believe in this
case.

And what's the recommended SOP for dealing with systems that learn
that the current offset is 42 seconds, but the leap files only have 34
seconds listed?  Is there a "good enough" standard for "interpolating"
when these leap seconds could have happened and updates to the tables
happen that way?

And what about network protocols that still need to report UTC times
rather than these new TI times for things like file modification time
(say, NFS)?  Since these are implemented in the kernel, now you have
to give the kernel a reasonable table.  And since timestamps span a
number of years, the question about putative leap seconds from the
previous paragraph doesn't sound so funny.  People likely won't care
too much if the timestamps are off a few seconds, but things like
'make' will care (if your sources are on a NFS server and your objects
are on local storage).

Oh, and likely a dozen other issues I've not thought of off the top of
my head.  At least with UTC, everybody botches leap seconds, but also
the broadcast of time is deterministic.  If you broadcast time that's
offset, and rely on tables in the receiving device, then you lose some
of that because of the problem of stale tables (or worse, wrong ones).

: I agree that the current system is dysfunctional.

Yea!

: I typically carry around 100 GB of storage, a GHz of processing
: capability, and devices that can communicate with 4 different
: wireless protocols.  That is how the world has changed since 1970
: when everything was pencil, paper, and slide rule.  My devices can
: receive something like TI, use it internally, and report to me something
: with added timezone offsets.

Right.  However, many of these systems that I'm used to dealing with
aren't connected to a meaningful network at all.  Most of these
systems have 100-300 MHz of power, ~100MB of storage (or less), and
limited connectivity.  Often times they just know the current offset
(and that only after 30 minutes in a cold start case for gear that's
been on the shelf for a while).  Since their purpose is to display in
UTC and interact with gear that uses UTC, plus weather a leap second
w/o having a step in their internal time representation (which, btw,
has to be efficient in storage and arithmetic operations done on it,
which makes 'broken down UTC time + leap tables' a non-starter, so a
count of SI seconds since some epoch is usually used, with the
conversions to UTC done for display, which means to do any display,
you have to know the right number of leap seconds).

: But of those wireless protocols, one of them was entirely shut down
: by the FCC before I had owned the device 5 years, so that one is defunct
: and the hardware deserves replacement.
: 
: I don't want to see mean solar time abandoned because of the  
: shortcomings of systems with that sort of lifetime.

But mean solar time already has been abandoned.  The second isn't
1/86400th of a mean solar day anymore, so although it was originally
meant to measure a rotational angle of this spinning rock, we've
changed the units so that it no longer does that.  Leap seconds are at
best a kludge until something better comes along, or until the length
of day is 86401 SI seconds long...

Warner

From phk at phk.freebsd.dk  Sun Dec 21 04:15:51 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 09:15:51 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Sat, 20 Dec 2008 17:45:55 PST."
	<8D831340-BE80-4595-9E73-EAA3465A41B6@ucolick.org> 
Message-ID: <64071.1229850951@critter.freebsd.dk>

In message <8D831340-BE80-4595-9E73-EAA3465A41B6 at ucolick.org>, Steve Allen writ
es:

>If leap seconds go into zoneinfo, then they are only as much nuisance
>as when the political princes of the world decree a change in the
>rules for time zones, and not even total unanimity within the ITU can
>stop that.

That depends critically on how often we have to change the zoneinfo
files.

Many systems avoid local timezones, to decouple the princes whims
from their operation, the poster boy example being air traffic
control, where everything is in UTC.

Putting leapseconds in zoneinfo would put an update obligation on
ATC-, and possibly on-board-, systems to get their zoneinfo files
updated regularly.

The difference between six months and ten years is the difference
between "unacceptable" and "something we an live with".

Getting rid of leap seconds, solves the problem entirely for the
ATC application domain.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Sun Dec 21 04:17:21 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 09:17:21 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sat, 20 Dec 2008 19:16:48 MST."
	<F065122B-DB4C-4CDC-B9DA-F55581DB5C7F@noao.edu> 
Message-ID: <64089.1229851041@critter.freebsd.dk>

In message <F065122B-DB4C-4CDC-B9DA-F55581DB5C7F at noao.edu>, Rob Seaman writes:

>Turning the issue around, is there even a coherent such study of the  
>effects of leap seconds on ATC (or any other industry)?

Call the FAA ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From cloos+leapsecs at jhcloos.com  Sun Dec 21 11:36:49 2008
From: cloos+leapsecs at jhcloos.com (James Cloos)
Date: Sun, 21 Dec 2008 11:36:49 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081220.113909.324381192.imp@bsdimp.com> (M. Warner Losh's
	message of "Sat, 20 Dec 2008 11:39:09 -0700 (MST)")
References: <47998.1229791949@critter.freebsd.dk>
	<21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
	<20081220.113909.324381192.imp@bsdimp.com>
Message-ID: <m3prjlxz5z.fsf@lugabout.jhcloos.org>

>>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:

Warner> You are under the fundamental misimpression that all systems are
Warner> or can be upgraded every 6 months.  That simply isn't possible
Warner> for a large class of systems.

But how many of the systems which do not have such a regular update
procedure in place care about time?  Of those who do, how many do not
use networking to keep their clock?  And of those which are left, how
many need earth-time-of-day to 1 second accuracy?

Are there any left which meet all of those criteria?

Most long-term systems do not care about time of day.

Anything which uses a remote system to sync its time is good; leap
second announcements are part of getting a time sync.

Anything which does not require <=1 sec time-of-day accuracy is also
good.  They simply do not care.

So what is left?

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From seaman at noao.edu  Sun Dec 21 14:48:40 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 21 Dec 2008 12:48:40 -0700
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <64089.1229851041@critter.freebsd.dk>
References: <64089.1229851041@critter.freebsd.dk>
Message-ID: <2630A711-DE58-4C64-B5AF-CC1A9564FB09@noao.edu>

I'm sure all will appreciate that I decided to cut my detailed reply  
short :-)  Here in a nutshell is my recipe for success:

	1) Define the problem.
	2) Design a solution.  (Each problem has many possible solutions.)

This is as simple as it gets for the basis of system engineering.  The  
ITU has spent 9 years assuming they know the one and only solution  
without ever finishing a coherent problem definition.  So:

	A) Finish defining the problem.
	B) Perform an INCOSE vetted trade-off study among the options.
...and	C) Seek consensus *before* voting.

Not only is this the best way to proceed, it is the fastest way to  
proceed.  The ITU way will have taken 20 years before it can possibly  
take effect in 2019.  Other options (e.g., revising leap second  
scheduling) could take effect sooner.

A, B, C - as easy as that.

Merry Christmas!

Rob


From phk at phk.freebsd.dk  Sun Dec 21 15:10:54 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 20:10:54 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sun, 21 Dec 2008 11:36:49 EST."
	<m3prjlxz5z.fsf@lugabout.jhcloos.org> 
Message-ID: <68758.1229890254@critter.freebsd.dk>

In message <m3prjlxz5z.fsf at lugabout.jhcloos.org>, James Cloos writes:
>>>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:
>
>Warner> You are under the fundamental misimpression that all systems are
>Warner> or can be upgraded every 6 months.  That simply isn't possible
>Warner> for a large class of systems.
>
>But how many of the systems which do not have such a regular update
>procedure in place care about time?

Everything relating to the power-grid load/supply distribution,
that means control of power-plants, transformers and switching
stations.  (The "supergrids" people dream about will require better
than 6msec autonomous holdover time precision for 24+hours at all
control points).

Everything relating to modern train control and management.

Everything relating to air traffic control.

Shiping control systems in narrow corridors (The Channel, The Great
Belt etc.)

Military early warning systems.

etc.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From zefram at fysh.org  Sun Dec 21 15:45:13 2008
From: zefram at fysh.org (Zefram)
Date: Sun, 21 Dec 2008 20:45:13 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <2630A711-DE58-4C64-B5AF-CC1A9564FB09@noao.edu>
References: <64089.1229851041@critter.freebsd.dk>
	<2630A711-DE58-4C64-B5AF-CC1A9564FB09@noao.edu>
Message-ID: <20081221204513.GJ2263@fysh.org>

Rob Seaman wrote:
>	A) Finish defining the problem.

The first problem is that there's more than one problem.  Finish?
We've barely begun.

A complicating factor here is that the time scales that we've inherited do
not result from the kind of process that you envision.  Without exception
they've evolved from earlier time scales without any explicit design step.
Does this mean that attempts at design are doomed?

>Merry Christmas!

Not yet.  (<http://isitchristmas.com>.)  But happy solstice!

-zefram

From phk at phk.freebsd.dk  Sun Dec 21 15:53:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 20:53:30 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: Your message of "Sun, 21 Dec 2008 12:48:40 MST."
	<2630A711-DE58-4C64-B5AF-CC1A9564FB09@noao.edu> 
Message-ID: <68977.1229892810@critter.freebsd.dk>

In message <2630A711-DE58-4C64-B5AF-CC1A9564FB09 at noao.edu>, Rob Seaman writes:

>This is as simple as it gets for the basis of system engineering.  The  
>ITU has spent 9 years assuming they know the one and only solution  
>without ever finishing a coherent problem definition.  So:

The only person I have heard claim that the problem is not well
understood is you.

Everybody else (of relevant competence) seems to be in perfect agreement
what the problem is, but not about the solution.

To bring yourself up to speed, try reading the leapsec@ archives, where
people like Warner and me have tried countless times to brief people
on what the problem is.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sun Dec 21 15:58:42 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 21 Dec 2008 13:58:42 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <5EEDFF63-08DB-4EA4-A990-C0F3299D0664@noao.edu>
References: <68758.1229890254@critter.freebsd.dk>
	<F1BCA00E-09A1-49E9-9E99-C2F1DCFFF203@noao.edu>
	<5EEDFF63-08DB-4EA4-A990-C0F3299D0664@noao.edu>
Message-ID: <407EB3F6-55BB-4E60-8D20-C909EA92E6B9@noao.edu>

Rather than speculating on each other's state of mind with words such  
as "fundamental misimpression" (as in the thread below), it might be  
helpful to focus on the actual questions asked.

Consider the iconic issue of timekeeping for trains, one of the  
primary drivers for our current standard time zone system.  Trains  
clearly need to be synchronized with external clocks.  Trains clearly  
have some mechanism or set of procedures (imperfect or not) for doing  
so.  So they don't match the question asked.

Rob
--

On Dec 21, 2008, at 1:10 PM, Poul-Henning Kamp wrote:

> In message <m3prjlxz5z.fsf at lugabout.jhcloos.org>, James Cloos writes:
>>>>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:
>>
>> Warner> You are under the fundamental misimpression that all  
>> systems are
>> Warner> or can be upgraded every 6 months.  That simply isn't  
>> possible
>> Warner> for a large class of systems.
>>
>> But how many of the systems which do not have such a regular update
>> procedure in place care about time?
>
> Everything relating to the power-grid load/supply distribution,
> that means control of power-plants, transformers and switching
> stations.  (The "supergrids" people dream about will require better
> than 6msec autonomous holdover time precision for 24+hours at all
> control points).
>
> Everything relating to modern train control and management.
>
> Everything relating to air traffic control.
>
> Shiping control systems in narrow corridors (The Channel, The Great
> Belt etc.)
>
> Military early warning systems.
>
> etc.


From seaman at noao.edu  Sun Dec 21 16:41:00 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 21 Dec 2008 14:41:00 -0700
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <0AAABD8C-0B07-4934-A422-151AFE180EAA@noao.edu>
References: <68977.1229892810@critter.freebsd.dk>
	<0AAABD8C-0B07-4934-A422-151AFE180EAA@noao.edu>
Message-ID: <8CEBF8D1-D76A-484B-A5C0-2F31D2BD4AC9@noao.edu>

Poul-Henning Kamp wrote:

> The only person I have heard claim that the problem is not well  
> understood is you.

The problem is not something cut and dried like:

	"How do we avoid introducing (or manage, if we can't avoid this)  
timekeeping discontinuities into expensive/remote/critical technical  
systems?"

The problem is rather expressed in a large number of requirements that  
derive from use cases cutting across the panoply of human industries  
and activities.  Is there a consensus that we have completed the task  
of gathering these requirements?

Rob



From phk at phk.freebsd.dk  Sun Dec 21 17:30:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 22:30:30 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sun, 21 Dec 2008 13:58:42 MST."
	<407EB3F6-55BB-4E60-8D20-C909EA92E6B9@noao.edu> 
Message-ID: <69368.1229898630@critter.freebsd.dk>

In message <407EB3F6-55BB-4E60-8D20-C909EA92E6B9 at noao.edu>, Rob Seaman writes:

>Consider the iconic issue of timekeeping for trains, one of the  
>primary drivers for our current standard time zone system.  Trains  
>clearly need to be synchronized with external clocks.  Trains clearly  
>have some mechanism or set of procedures (imperfect or not) for doing  
>so.  So they don't match the question asked.

Modern trains run at speeds of roughly 100 m/s.  They care very much
about seconds and fractions thereof.

In fact, they run so fast that a special version of the GSM mobile
standard called "GSM-R", has been created for train-control
applications.

The main difference between plain GSM and GSM-R is that the latter
allows for dopplershift up to 140 m/s, but now railway people have
started bitching about that not being enough margin.

If you want to know what non-antique rail-road control looks like,
search for and study "ERTMS".

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Sun Dec 21 17:31:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 21 Dec 2008 22:31:33 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: Your message of "Sun, 21 Dec 2008 14:41:00 MST."
	<8CEBF8D1-D76A-484B-A5C0-2F31D2BD4AC9@noao.edu> 
Message-ID: <69389.1229898693@critter.freebsd.dk>

In message <8CEBF8D1-D76A-484B-A5C0-2F31D2BD4AC9 at noao.edu>, Rob Seaman writes:

>The problem is rather expressed in a large number of requirements that  
>derive from use cases cutting across the panoply of human industries  
>and activities.  Is there a consensus that we have completed the task  
>of gathering these requirements?

Before any such consensus can be reached, you have to show probable
cause.

You havn't.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sun Dec 21 18:56:13 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 21 Dec 2008 16:56:13 -0700
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <69389.1229898693@critter.freebsd.dk>
References: <69389.1229898693@critter.freebsd.dk>
Message-ID: <DC6963F2-CA9A-402C-B611-BFCB9ED22DFB@noao.edu>

So now we're into legal analogies?  Civil time would be in civil  
court.  The standard of judgement would be something like "a  
preponderance of the evidence".  My whole point is that there has been  
insufficient data entered into evidence to render any judgement sound.

Probable cause applies to situations in which the evidence is hidden  
within some private residence.  If there are secret data regarding  
civil timekeeping, then one would suggest they be made public so they  
can influence public decision-making.

And if we're to abandon a search for consensus regarding the future  
evolution of this standard, then common sense says the result should  
be a standard that doesn't change.  Mean solar time has formed the  
basis of civil timekeeping since the 19th century (and before, since  
apparent solar time is a periodic offset from mean solar time).  I'm  
simply suggesting "due process" be followed before making a change of  
this magnitude.

Due process is the swiftest process.

Rob
--

On Dec 21, 2008, at 3:31 PM, Poul-Henning Kamp wrote:

> In message <8CEBF8D1-D76A-484B-A5C0-2F31D2BD4AC9 at noao.edu>, Rob  
> Seaman writes:
>
>> The problem is rather expressed in a large number of requirements  
>> that
>> derive from use cases cutting across the panoply of human industries
>> and activities.  Is there a consensus that we have completed the task
>> of gathering these requirements?
>
> Before any such consensus can be reached, you have to show probable
> cause.
>
> You havn't.


From seaman at noao.edu  Sun Dec 21 19:09:57 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 21 Dec 2008 17:09:57 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <69368.1229898630@critter.freebsd.dk>
References: <69368.1229898630@critter.freebsd.dk>
Message-ID: <EC8CC227-DC49-458A-9725-3CE5DDC8F579@noao.edu>

Poul-Henning Kamp wrote:

> In message <407EB3F6-55BB-4E60-8D20-C909EA92E6B9 at noao.edu>, Rob  
> Seaman writes:
>
>> Consider the iconic issue of timekeeping for trains, one of the
>> primary drivers for our current standard time zone system.  Trains
>> clearly need to be synchronized with external clocks.  Trains clearly
>> have some mechanism or set of procedures (imperfect or not) for doing
>> so.  So they don't match the question asked.
>
> Modern trains run at speeds of roughly 100 m/s.  They care very much
> about seconds and fractions thereof.
>
> In fact, they run so fast that a special version of the GSM mobile
> standard called "GSM-R", has been created for train-control
> applications.
>
> The main difference between plain GSM and GSM-R is that the latter
> allows for dopplershift up to 140 m/s, but now railway people have
> started bitching about that not being enough margin.
>
> If you want to know what non-antique rail-road control looks like,
> search for and study "ERTMS".

Very informative!  (Not a hint of irony.  Thanks for the info.)   
However, it still doesn't address the question as asked.

James Cloos wrote:

> Anything which uses a remote system to sync its time is good; leap
> second announcements are part of getting a time sync.
>
> Anything which does not require <=1 sec time-of-day accuracy is also
> good.  They simply do not care.
>
> So what is left?

You may disagree with his premises, but the request was for candidates  
for completely standalone systems requiring high precision clocks.   
Surely the (very interesting) planes, trains, shipping, power and  
military applications you mentioned fail to satisfy the first premise,  
whether or not they meet the second premise.

The closest I've come up with is a self-orienting telescope system  
I've heard off that can (in theory, at least) be deployed by  
parachute.  I'm pretty sure it uses GPS, though.

Rob

From ch at murgatroid.com  Sun Dec 21 19:34:13 2008
From: ch at murgatroid.com (christopher hoover)
Date: Sun, 21 Dec 2008 16:34:13 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <68758.1229890254@critter.freebsd.dk>
References: Your message of "Sun,
	21 Dec 2008 11:36:49 EST."	<m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<68758.1229890254@critter.freebsd.dk>
Message-ID: <000301c963cd$0476cd70$0d646850$@com>

> Everything relating to the power-grid load/supply distribution,
> that means control of power-plants, transformers and switching
> stations.

The power grid does not necessarily require (fully) isochronous operation.  

Microgrid research (e.g., Piagi and Lasseter) has indicated practical ways
to do autonomous control using only local information.   This work has grown
particularly important as we increase distributed generation capacity and
leverage the efficiency of CHP/CCHP/cogeneration.

-ch




From imp at bsdimp.com  Mon Dec 22 01:26:39 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 21 Dec 2008 23:26:39 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <m3prjlxz5z.fsf@lugabout.jhcloos.org>
References: <21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
	<20081220.113909.324381192.imp@bsdimp.com>
	<m3prjlxz5z.fsf@lugabout.jhcloos.org>
Message-ID: <20081221.232639.-432836607.imp@bsdimp.com>

In message: <m3prjlxz5z.fsf at lugabout.jhcloos.org>
            James Cloos <cloos+leapsecs at jhcloos.com> writes:
: >>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:
: 
: Warner> You are under the fundamental misimpression that all systems are
: Warner> or can be upgraded every 6 months.  That simply isn't possible
: Warner> for a large class of systems.
: 
: But how many of the systems which do not have such a regular update
: procedure in place care about time?

I'm personally responsible for hundreds.

: Of those who do, how many do not
: use networking to keep their clock?

All of them.

: And of those which are left, how
: many need earth-time-of-day to 1 second accuracy?

1-second accuracy?  They need microsecond level accuracy over periods
of months.

: Are there any left which meet all of those criteria?

All of them.

: Most long-term systems do not care about time of day.

Control applications for timing systems for LORAN-C slaved to GPS *DO*
care about time of day (but not local time of day), because the local
time of day (UTC) must be displayed on the GUI and on the atomic
clocks at the stations.

: Anything which uses a remote system to sync its time is good; leap
: second announcements are part of getting a time sync.

Correct, but only part of the problem.  Leap seconds announcements
aren't given to systems that are powered down.  You might ask 'so
what?' and I'll reply "these are the cold spares kept on sight and at
HQ for CPU failure scenarios."  These systems sit on the shelf for
many years, and then need to work right when plugged in, as quickly as
possible.  Leap seconds mean a CPU failure is at least 1/2 hour while
the GPS receiver (which is also a cold spare) gets the latest
almanac.  This means that your timing system is off the air for 1/2
hour, and in the LORAN chain this is bad.  Of course, things are
mitigated by having two systems so when one is off, the other can take
over.

: Anything which does not require <=1 sec time-of-day accuracy is also
: good.  They simply do not care.
: 
: So what is left?

A large class of systems similar to the LORAN-C timing software.
These systems monitor time, report UTC, but use an internal time scale
without leap seconds to give them a continuous count of seconds.  To
fully come up, these systems need to know the number of leap seconds.
To operate properly, they really need a full table, to ensure that
some historical queries work properly, but the can operate in a
degraded mode when the full table isn't available...

I'll grant that emacs could care less about leap seconds, but we
aren't talking about those systems that don't care.  We are talking
about the ones that do, that need to implement leap seconds, or
interact with them operationally, and the real, observed problems that
many people on this list have experienced first had.

Warner

From cloos+leapsecs at jhcloos.com  Mon Dec 22 06:27:31 2008
From: cloos+leapsecs at jhcloos.com (James Cloos)
Date: Mon, 22 Dec 2008 06:27:31 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081221.232639.-432836607.imp@bsdimp.com> (M. Warner Losh's
	message of "Sun, 21 Dec 2008 23:26:39 -0700 (MST)")
References: <21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
	<20081220.113909.324381192.imp@bsdimp.com>
	<m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
Message-ID: <m3bpv4with.fsf@lugabout.jhcloos.org>

>>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:

Jim> Of those who do, how many do not use networking to keep their clock?

Warner> All of them.

Warner> Control applications for timing systems for LORAN-C slaved to
Warner> GPS *DO* care about time of day (but not local time of day),

Slaved to gps == use networking to keep their clocks. 

Warner> Leap seconds announcements aren't given to systems that are
Warner> powered down.

OK.  That is indeed a good point.

Obviously GPS needs to provide quicker almanac sync.

But I have to ask:  why should navigation systems care about time of
day?  Shouldn't seconds since an epoch be enough?

It seems like the only issue is human monitoring of the systems' idea
of now.

Warner> ... we aren't talking about those systems that don't care.  We
Warner> are talking about the ones that do, ...

My point is that the majority of systems which care about timing and
which can not get almanac data to correlate an interval since an epoch
with human time-of-day do not, in general, really need the latter.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From zefram at fysh.org  Mon Dec 22 06:47:55 2008
From: zefram at fysh.org (Zefram)
Date: Mon, 22 Dec 2008 11:47:55 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <m3bpv4with.fsf@lugabout.jhcloos.org>
References: <21DD5F1E-DC22-4C1D-A69F-177BBB07965A@noao.edu>
	<20081220.113909.324381192.imp@bsdimp.com>
	<m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
	<m3bpv4with.fsf@lugabout.jhcloos.org>
Message-ID: <20081222114755.GD14473@fysh.org>

James Cloos wrote:
>Obviously GPS needs to provide quicker almanac sync.

There used to be a notable problem with GPS that all the satellites
transmitted the almanac in unison.  This is highly redundant, and
means that the receiver has to wait the full 12(?) minutes to compile a
complete almanac.  There was a proposal that the satellites could instead
transmit the almanac at offset phases, so that a multi-channel receiver
could compile a complete almanac, by combining the pieces received from
different satellites, in one or two minutes.  Anyone know whether this
has been implemented?

>But I have to ask:  why should navigation systems care about time of
>day?  Shouldn't seconds since an epoch be enough?

A good point.  GPS time lacks leap seconds precisely in order to make
it easy to convert to a linear scale for the purposes of computation.
I suspect that much of the need for UTC in navigation systems comes
from adherence to an established dumb design/standard rather than from
fundamental requirement.  GLONASS notably makes gratuitous use of UTC,
and suffers operational glitches at every leap second.  (GPS is not
immune from dumb design either: consider the signal format for GPS time,
and, for that matter, the concept of representing GPS time as a date
and time-of-day in the first place.)

-zefram

From phk at phk.freebsd.dk  Mon Dec 22 06:59:15 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 11:59:15 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: Your message of "Sun, 21 Dec 2008 16:56:13 MST."
	<DC6963F2-CA9A-402C-B611-BFCB9ED22DFB@noao.edu> 
Message-ID: <72897.1229947155@critter.freebsd.dk>

In message <DC6963F2-CA9A-402C-B611-BFCB9ED22DFB at noao.edu>, Rob Seaman writes:

>So now we're into legal analogies?

No.

But if you do not make a credible case that something is being
overlooked, nobody is going to waste time on your proposed process
to look for things that are being overlooked.

If you could come up with just a single credible poster-boy example
you would have a chance, but so far I have seen nothing even remotely
like it from you.

Proposing red tape commisions in the absence of evidence of their
need, is a widely recognized stalling tactic.

Poul-Henning

>>> The problem is rather expressed in a large number of requirements  
>>> that
>>> derive from use cases cutting across the panoply of human industries
>>> and activities.  Is there a consensus that we have completed the task
>>> of gathering these requirements?
>>
>> Before any such consensus can be reached, you have to show probable
>> cause.
>>
>> You havn't.
>
>_______________________________________________
>LEAPSECS mailing list
>LEAPSECS at leapsecond.com
>http://six.pairlist.net/mailman/listinfo/leapsecs
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Mon Dec 22 07:00:12 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 12:00:12 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sun, 21 Dec 2008 17:09:57 MST."
	<EC8CC227-DC49-458A-9725-3CE5DDC8F579@noao.edu> 
Message-ID: <72930.1229947212@critter.freebsd.dk>

In message <EC8CC227-DC49-458A-9725-3CE5DDC8F579 at noao.edu>, Rob Seaman writes:

>You may disagree with his premises, but the request was for candidates  
>for completely standalone systems requiring high precision clocks.   

No, the request was for systems that could not have software updates
applied willy-nilly every six months.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Mon Dec 22 07:15:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 12:15:33 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Sun, 21 Dec 2008 16:34:13 PST."
	<000301c963cd$0476cd70$0d646850$@com> 
Message-ID: <73014.1229948133@critter.freebsd.dk>

In message <000301c963cd$0476cd70$0d646850$@com>, "christopher hoover" writes:
>> Everything relating to the power-grid load/supply distribution,
>> that means control of power-plants, transformers and switching
>> stations.
>
>The power grid does not necessarily require (fully) isochronous operation.  
>
>Microgrid research (e.g., Piagi and Lasseter) has indicated practical ways
>to do autonomous control using only local information.   This work has grown
>particularly important as we increase distributed generation capacity and
>leverage the efficiency of CHP/CCHP/cogeneration.

The magnitude of energy spikes going the wrong direction in a matter
of milliseconds have everybody doing the "let somebody else try this,
with _their_ transformers and generators" shuffle.

It is well known and documented that the current (HVAC) strategy
does not work and the increasing distances between power generator
and consumer dictates HVDC systems.

But so far all HVDC has been point to point and very few experiments
have been done with "busing" where you have multiple entry/exit
points on a HVDC grid.

The main problem with HVDC is that the lack of zero-crossings means
that it is terribly hard to open a circuit under load.

To put matters in perspective:  Many power plants today have the
"fuse of last resort" protecting their kit.  This consists of
approx 3 meters of copper rail with a couple of bars of dynamite
wrapped around the middle, often wired to automatically blow
above a certain fault current.

The secondary problem with HVDC is that the lack of inductive
components and dV in the grid makes faults propagate close to ten
times faster and fault currents build up to values five times higher.

And finally, blowing out a big-ass transformer is bad money news,
but blowing all the thyristors or IGBTs in a AC/DC conversion plant
is _really_ bad money news.

About the only thing people can agree on, is that "coordinated
switching" requires synchronization to better than 10% of period,
which everybody translates to a one microsecond requirement.

One switchpoint being 1 second off because the hadn't heard about
the leap second could make for the best and most new years eve
fireworks you can imagine.

Ohh, and the reason they need UTC ?  Billing.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dot at dotat.at  Mon Dec 22 08:27:30 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 13:27:30 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
References: <006D7A34-31D9-4492-9014-667C7B92612C@ucolick.org>
Message-ID: <alpine.LSU.2.00.0812221313400.9904@hermes-1.csi.cam.ac.uk>

On Sat, 20 Dec 2008, Steve Allen wrote:
>
> Please identify the operations which need one second predictability
> over a time span of six months.

Anything that needs to exchange time stamps with other systems that are
both accurate and specified in some variant of UT (UTC, POSIX time, NTP
time, etc.) needs an up-to-date leap second table. Even if the only future
event that these systems need to predict is leap seconds, that is enough
to affect their software update schedule or require some other way to
periodically obtain a leap second table.

> Please explain why changing the name of the broadcast time scale
> to TI and putting UTC and the leap seconds into zoneinfo does
> not satisfy all requirements of the need for uniform time scale.

You keep asking this question and we keep explaining that it breaks
too much software.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
HUMBER THAMES DOVER: WEST OR NORTHWEST 5 OR 6, DECREASING 3 OR 4 BUT VARIABLE
3 OR LESS IN DOVER. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD,
OCCASIONALLY POOR.

From dot at dotat.at  Mon Dec 22 08:39:39 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 13:39:39 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
 sun
In-Reply-To: <F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
	<F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
Message-ID: <alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>

On Fri, 19 Dec 2008, Rob Seaman wrote:
>
> To synchronize two clocks (Earth and Lunar in this case), you can adjust
> the rates on one end or the other, or you can reset the zero point of
> one or the other on some sort of schedule.  Additionally, if the
> differential rates continue to vary, then the scheduling has to vary.
> If the clock rates are too far apart, the best solution is to put two
> clocks on the wall.

As well as the different rates of rotation of the various extra-
terrestrial bodies, isn't there also the problem of differing relativistic
frames of reference? (Is the magnitude of the difference big enough to
matter?) The local atomic clocks on the Moon or Mars will not run at the
same rate as a time signal transmitted from the Earth. So you will need to
put THREE clocks on the wall, or maybe four: local atomic time, local
rotational angle, terrestrial atomic time, and perhaps also terrestrial
rotational angle.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6 VEERING SOUTHWESTERLY 6 TO GALE 8.
VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From pvince at theiet.org  Mon Dec 22 08:50:58 2008
From: pvince at theiet.org (Peter Vince)
Date: Mon, 22 Dec 2008 13:50:58 +0000
Subject: [LEAPSECS] (no subject)
Message-ID: <49513.1229953858@uk2.net>

>> Please explain why changing the name of the broadcast time scale
>> to TI and putting UTC and the leap seconds into zoneinfo does
>> not satisfy all requirements of the need for uniform time scale.
>
>You keep asking this question and we keep explaining that it breaks
>too much software.
>
>Tony.

Tony,

I am trying to clarify in my mind a couple of proposals, one of which is having no more leap-seconds in the civil (broadcast) 
time scale.  I'm sorry, I must have missed your messages where you said that a lot of software would fail in that scenario - 
could you briefly clarify please?

Peter



From zefram at fysh.org  Mon Dec 22 08:55:30 2008
From: zefram at fysh.org (Zefram)
Date: Mon, 22 Dec 2008 13:55:30 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
	<F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
	<alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
Message-ID: <20081222135530.GE14473@fysh.org>

Tony Finch wrote:
>         The local atomic clocks on the Moon or Mars will not run at the
>same rate as a time signal transmitted from the Earth.

More due to being at high altitude than due to relative motion, I believe.
If you're concerned about local interval time, with a sufficiently heavy
emphasis on "local", TAI or other realisations of TT are inadequate even
on the Earth's surface.  Though you'd likely get better time by applying
a calculated frequency offset to TAI than by running your own (isolated)
atomic clock.

TT (roughly: interval time on the geoid) ticks 0.9999999993030709866 s
(exactly) for each second of TCG (roughly: interval time at infinite
altitude).  Interval time on the lunar surface, like interval time up
a Terran mountain, ticks at some rate between these two.

A side effect of gravitational time dilation is that (presuming infinite
precision) radio time signals with phase-locked carrier don't actually
transmit on precisely their nominal carrier frequency, as judged
locally at the transmitter.  Being above sea level, they transmit on a
fractionally lower frequency.  As the signal travels downwards it gets
blue-shifted, so that at sea level it appears as precisely the nominal
frequency.  It's the revenge of the rubber seconds.

-zefram

From phk at phk.freebsd.dk  Mon Dec 22 09:03:41 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 14:03:41 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Mon, 22 Dec 2008 13:50:58 GMT."
	<49513.1229953858@uk2.net> 
Message-ID: <73737.1229954621@critter.freebsd.dk>

In message <49513.1229953858 at uk2.net>, Peter Vince writes:

>I am trying to clarify in my mind a couple of proposals, one of which is having no more leap-seconds in the civil (broadcast) 
>time scale.  I'm sorry, I must have missed your messages where you said that a lot of software would fail in that scenario - 
>could you briefly clarify please?

There is one (major) problem: software does not grok leapseconds.

One of the solutions Rob peddles for this, is "Make a new timescale
without leap seconds, and leave leap seconds in the UTC timescale".

This does not fly because a lot of systems are legally mandated to
use the UTC timescale.

Changing all those laws and regulations, just because a single
astronomer is very emotionally attached to the name "UTC" is just
not going to happen :-)

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dot at dotat.at  Mon Dec 22 09:10:25 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 14:10:25 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: <49513.1229953858@uk2.net>
References: <49513.1229953858@uk2.net>
Message-ID: <alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Peter Vince wrote:
>
> I am trying to clarify in my mind a couple of proposals, one of which is
> having no more leap-seconds in the civil (broadcast) time scale.  I'm
> sorry, I must have missed your messages where you said that a lot of
> software would fail in that scenario - could you briefly clarify please?

This isn't really about broadcast timescales, but about the semantics of
POSIX time_t. Steve proposes to provide a well-defined uniform timescale
on Unix systems by redefining time_t to follow some linear atomic
timescale instead of UTC, and that the zoneinfo/tzcode library would be
used to translate from this new version of time_t to UTC, using a leap
second table alongside the existing time zone tables.

The code to implement this has in fact already been written, 15 or more
years ago, but no-one uses it because it breaks too much stuff. For
example, there is a lot of time-handling code in the kernel, and because
it does not link with the tzcode library the proposed architecture doesn't
accommodate its requirements. There's also a lot of code which doesn't use
the C tzcode for time handling, such as the Java runtime. There is a
pervasive assumption in Unix that midnight UT is when t % 86400 == 0.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6 VEERING SOUTHWESTERLY 6 TO GALE 8.
VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From dan at tobias.name  Mon Dec 22 09:22:35 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Mon, 22 Dec 2008 09:22:35 -0500
Subject: [LEAPSECS] (no subject)
In-Reply-To: <73737.1229954621@critter.freebsd.dk>
References: <Your message of "Mon,
	22 Dec 2008 13:50:58 GMT." <49513.1229953858@uk2.net> >,
	<73737.1229954621@critter.freebsd.dk>
Message-ID: <494F5C5B.22553.15EF3729@dan.tobias.name>

On 22 Dec 2008 at 14:03, Poul-Henning Kamp wrote:

> This does not fly because a lot of systems are legally mandated to
> use the UTC timescale.

And some laws in some places mandate Greenwich Mean Time, or lots of 
other things.  No matter what is done with time scales in the future, 
it's going to run contrary to somebody's laws somewhere.


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From seaman at noao.edu  Mon Dec 22 09:25:03 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 07:25:03 -0700
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
	<F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
	<alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
Message-ID: <037BA1CD-DA84-4AE9-8623-657F4CF8E3AC@noao.edu>

Tony Finch wrote:

> On Fri, 19 Dec 2008, Rob Seaman wrote:
>>
>> To synchronize two clocks (Earth and Lunar in this case), you can  
>> adjust
>> the rates on one end or the other, or you can reset the zero point of
>> one or the other on some sort of schedule.  Additionally, if the
>> differential rates continue to vary, then the scheduling has to vary.
>> If the clock rates are too far apart, the best solution is to put two
>> clocks on the wall.
>
> As well as the different rates of rotation of the various extra-
> terrestrial bodies, isn't there also the problem of differing  
> relativistic
> frames of reference? (Is the magnitude of the difference big enough to
> matter?) The local atomic clocks on the Moon or Mars will not run at  
> the
> same rate as a time signal transmitted from the Earth. So you will  
> need to
> put THREE clocks on the wall, or maybe four: local atomic time, local
> rotational angle, terrestrial atomic time, and perhaps also  
> terrestrial
> rotational angle.

In addition to Zefram's excellent comments, there are several ways to  
approach this.

1) The references from this message a couple of weeks ago:

	http://six.pairlist.net/pipermail/leapsecs/2008-December/000605.html

rather thoroughly put the last nail in the coffin of overreaching  
assertions about the origin of leap seconds having anything to do with  
relativistic effects.

2) Also, Dave Mills has been working on the issue of timekeeping in  
space in the NTP context:

	http://www.cis.udel.edu/~mills/proximity.html

This adds a nicely engineered shell on top of the physical model.   
Basically, the ephemerides of the planets and the known velocity and  
location of spacecraft allow the relativistic (Newtonian and Einstein)  
corrections to be computed.

3) My own point of view focuses on the requirements for "wall  
clocks".  Civil timekeeping has (heretofore) been mean solar time  
because the clocks in question are general purpose clocks on people's  
walls, wrists, laptops and phones.  For instance, our conference rooms  
have multiple clocks because the observatory has sites or partners in  
Hawaii, Arizona, Chile, Illinois and a corporate HQ in Washington, DC  
(no surprise there).  Separate wall clocks are needed for human  
purposes.

Whether four clocks as you list are needed is a question of whether  
civilians need to keep track of atomic time versus earth orientation  
time (times two planets).  Until now, the answer has been "no",  
because atomic time has been a technical timescale that only folks  
like us have to keep track of.

4) The ITU proposal is basically an assertion that people don't care  
about mean solar time.  (We can continue arguing that point in some  
other thread.)  They would answer "no" to your question since a key  
point of the notion is to substitute one time scale for another while  
recycling the namespace.

5) The zoneinfo idea is to preserve civilian access to mean solar  
time, while providing enhanced expert access to atomic time (interval  
time of whatever origin).  It does not imply that both clocks have to  
be displayed - or indeed, that one would choose to represent the data  
in the same format at all.

Rob


From zefram at fysh.org  Mon Dec 22 09:27:02 2008
From: zefram at fysh.org (Zefram)
Date: Mon, 22 Dec 2008 14:27:02 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: <20081222135530.GE14473@fysh.org>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
	<F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
	<alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
	<20081222135530.GE14473@fysh.org>
Message-ID: <20081222142702.GA22408@fysh.org>

I wrote:
>Tony Finch wrote:
>>         The local atomic clocks on the Moon or Mars will not run at the
>>same rate as a time signal transmitted from the Earth.
>
>More due to being at high altitude than due to relative motion, I believe.

I've just found this relevant graph on Wikipedia:

http://upload.wikimedia.org/wikipedia/commons/9/98/Orbit_times.png

-zefram

From dot at dotat.at  Mon Dec 22 09:31:54 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 14:31:54 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
 sun
In-Reply-To: <20081222142702.GA22408@fysh.org>
References: <38070.1229638397@critter.freebsd.dk>
	<F3525D67-4A4A-4655-9561-79F16C8F7BA0@noao.edu>
	<20081219044555.GA389@mercury.ccil.org>
	<DEA8D9B8-9149-4F00-ADD3-C1F9F322DFED@noao.edu>
	<20081219173414.GC389@mercury.ccil.org>
	<F7B628AA-9B54-485C-980B-8A37B74512AB@noao.edu>
	<alpine.LSU.2.00.0812221329350.9904@hermes-1.csi.cam.ac.uk>
	<20081222135530.GE14473@fysh.org> <20081222142702.GA22408@fysh.org>
Message-ID: <alpine.LSU.2.00.0812221431310.9904@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Zefram wrote:
>
> http://upload.wikimedia.org/wikipedia/commons/9/98/Orbit_times.png

Cool, thanks for that and the interesting details in your other post.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: VARIABLE BACKING SOUTHEAST 3 OR 4, OCCASIONALLY 5 IN
PLYMOUTH. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN PLYMOUTH. DRIZZLE.
MODERATE OR GOOD, OCCASIONALLY POOR.

From seaman at noao.edu  Mon Dec 22 09:34:01 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 07:34:01 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <494F5C5B.22553.15EF3729@dan.tobias.name>
References: <Your message of "Mon,
	22 Dec 2008 13:50:58 GMT." <49513.1229953858@uk2.net> >,
	<73737.1229954621@critter.freebsd.dk>
	<494F5C5B.22553.15EF3729@dan.tobias.name>
Message-ID: <7E0FC399-EBE4-4860-800B-A31DFC71FBC5@noao.edu>

On Dec 22, 2008, at 7:22 AM, Daniel R. Tobias wrote:

> On 22 Dec 2008 at 14:03, Poul-Henning Kamp wrote:
>
>> This does not fly because a lot of systems are legally mandated to
>> use the UTC timescale.
>
> And some laws in some places mandate Greenwich Mean Time, or lots of
> other things.  No matter what is done with time scales in the future,
> it's going to run contrary to somebody's laws somewhere.

One might also mention the usual example of attempting to legislate  
physical reality, the "Indiana pi bill":

	http://www.agecon.purdue.edu/crd/Localgov/Second%20Level%20pages/indiana_pi_bill.htm

It may be hard to believe (whatever countries we live in), but dig  
deep enough down through our interlocking systems of laws and treaties  
and you eventually reach some underlying model of physical reality :-)

Example:  If the ITU proposal were to attempt to relayer civil  
timekeeping on Earth onto the length of the Martian day, one can be  
confident they would fail.

The issue is how close is close enough?

Rob


From phk at phk.freebsd.dk  Mon Dec 22 09:36:38 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 14:36:38 +0000
Subject: [LEAPSECS] WP7A status and Re: clinical evidence about time and
	sun
In-Reply-To: Your message of "Mon, 22 Dec 2008 07:25:03 MST."
	<037BA1CD-DA84-4AE9-8623-657F4CF8E3AC@noao.edu> 
Message-ID: <73961.1229956598@critter.freebsd.dk>

In message <037BA1CD-DA84-4AE9-8623-657F4CF8E3AC at noao.edu>, Rob Seaman writes:

>3) My own point of view focuses on the requirements for "wall  
>clocks".  Civil timekeeping has (heretofore) been mean solar time  
>[...]

You mean "has been within a couple of hours of mean solar time" ?

>4) The ITU proposal is basically an assertion that people don't care  
>about mean solar time.

The fact that the majority of the earths population use a legal time
that is more than 15 minutes different from mean solaer time, would
seem to support the ITU in this.

Have you or others provided any documentation for the opposite claim ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From sla at ucolick.org  Mon Dec 22 11:01:45 2008
From: sla at ucolick.org (Steve Allen)
Date: Mon, 22 Dec 2008 08:01:45 -0800
Subject: [LEAPSECS] (no subject)
In-Reply-To: <alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
References: <49513.1229953858@uk2.net>
	<alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
Message-ID: <20081222160145.GB7103@ucolick.org>

On Mon 2008-12-22T14:10:25 +0000, Tony Finch hath writ:
> The code to implement this has in fact already been written, 15 or more
> years ago, but no-one uses it because it breaks too much stuff.

I am aware of the interesting breakages that happened when
zoneinfo files were retroactively modified to be inconsistent
with POSIX.  Clearly that change cannot be done for past
history.  That's part of the point of this live javascript page
http://www.ucolick.org/~sla/leapsecs/epochtime.html

> example, there is a lot of time-handling code in the kernel, and because
> it does not link with the tzcode library the proposed architecture doesn't
> accommodate its requirements. There's also a lot of code which doesn't use
> the C tzcode for time handling, such as the Java runtime. There is a
> pervasive assumption in Unix that midnight UT is when t % 86400 == 0.

So if the broadcast time scale were to become TI then these operations
would be taking place at "atomic day midnight" instead of mean solar
day midnight.  That's still a legitimate kind of day.

Are there actually serious technical problems (kindly ignore
bureaucratic ones about conformance with UTC) with that sort of thing?

The argument that "atomic time will drift by no more than a few
seconds from mean solar during this century has been used by those who
want to abandon leaps.  In the presence of an internationally approved
atomic time scale I think that argument goes both ways.  It doesn't
hurt anybody if certain technical operations drift a few seconds from
civil wall clock time.

It has become clear in the ITU process that a change to the nature of
the broadcast time scale cannot be decreed with less than a decade of
advance notice.  That's enough time to fix a lot of software and throw
away a lot of hardware.

If getting leaps out of the broadcast time scale is the principal and
urgent *technical* goal then it might be far quicker to decide to
choose "TI" than to hope for the *political* goals involved in getting
the ITU to disregard the history and the words of the CGPM when they
recommended UTC as a form of mean solar time.  Technicians can adapt
a lot faster than politicians.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Mon Dec 22 11:07:17 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 16:07:17 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Mon, 22 Dec 2008 08:01:45 PST."
	<20081222160145.GB7103@ucolick.org> 
Message-ID: <74243.1229962037@critter.freebsd.dk>

In message <20081222160145.GB7103 at ucolick.org>, Steve Allen writes:

>If getting leaps out of the broadcast time scale is the principal and
>urgent *technical* goal [...]

No, the principal goal is make sure all UTC days have exactly 86400
seconds, playing games with the names of timescales will not help.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From imp at bsdimp.com  Mon Dec 22 11:20:53 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 22 Dec 2008 09:20:53 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <m3bpv4with.fsf@lugabout.jhcloos.org>
References: <m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
	<m3bpv4with.fsf@lugabout.jhcloos.org>
Message-ID: <20081222.092053.146405415.imp@bsdimp.com>

In message: <m3bpv4with.fsf at lugabout.jhcloos.org>
            James Cloos <cloos+leapsecs at jhcloos.com> writes:
: My point is that the majority of systems which care about timing and
: which can not get almanac data to correlate an interval since an epoch
: with human time-of-day do not, in general, really need the latter.

I see that you've stated this point, but I don't think it is valid.
There's very few timing systems that don't care about UTC at some
point.  And those are the only systems that care about something other
than UTC.

In general, all systems need to be synchronized to human time because
at some point they have to interact with humans.  As long as we have a
time scale that is irregular, there are going to be problems.

People readily poo-poo the off-by-one-second issue with leap seconds,
but I can assure you as someone who has a lot of software experience,
that in both timing and non-timing applications people care a lot
about that.  Sure, it usually doesn't matter much, and you can usually
get away with it, but that reason alone is not sufficient to say it is
never a problem.

Finally, I say 'human time' here for a reason.  The only reason I care
that it is 9:11am as I type this is because my son has a hockey game
at 1:30pm today, my friends are coming over for dinner at 6:00, etc.
The solar time locally is about 20 minutes different than these times,
and that concerns me not at all.  The authorities said the time right
now is 9:11am and everybody agrees with to use that time, I'm happy
with it.  That's the important part of the current system: everybody
agreeing on what time it is.  That's why I tolerate the current
dysfunctional leap second system, but want to make it better.

Since I'm already divorced from local solar time, and seconds aren't
based on this year's mean solar day, I find it a quaint throwback to
have leap seconds at all.  Since we can measure and publish the drift,
why bother with all the hair of leap seconds?  They are at best a
short-term kludge until we find something better.  Since we've only
been using them for 40 years, there's no real posterity to worry
about.  Since we're going to have to have them with increasing
regularity over the next 50 years, to the point where 2 a year are
unlikely to be enough, we need to ask ourselves if there's some better
way to distribute time than what we're doing.  We should learn from
our experiences with leap seconds and adjust the system to something
that works better.  When leap seconds started, there was no Internet,
and there were maybe a hundred people in the world that were affected
by them and needed to get them right.  Now that the world is
interconnected, and ntpd still can't seem to get them right on all the
computers running it (in part due to well meaning people causing
problems with rubber seconds around the leap event), I think that
experience has shown that the system needs to be reegineered.

Warner

From seaman at noao.edu  Mon Dec 22 11:39:53 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 09:39:53 -0700
Subject: [LEAPSECS] MEAN! SOLAR! TIME!  (was re: something else)
In-Reply-To: <73961.1229956598@critter.freebsd.dk>
References: <73961.1229956598@critter.freebsd.dk>
Message-ID: <414E3707-C031-4139-9F7A-B3496E2EF9D0@noao.edu>

  Poul-Henning Kamp wrote:

> Rob Seaman writes:
>
>> 3) My own point of view focuses on the requirements for "wall
>> clocks".  Civil timekeeping has (heretofore) been mean solar time
>> [...]
>
> You mean "has been within a couple of hours of mean solar time" ?

No.  I mean "mean solar time".  As explained, for instance, in 2005 (I  
could go back farther):

	http://www.mail-archive.com/leapsecs at rom.usno.navy.mil/msg00676.html

and

	http://www.febo.com/pipermail/time-nuts/2005-July/018991.html

and in 2006:

	http://www.mail-archive.com/leapsecs at rom.usno.navy.mil/msg00954.html

and in 2007:

	http://catless.ncl.ac.uk/Risks/24.79.html#subj3

and in 2008:

	http://six.pairlist.net/pipermail/leapsecs/2008-January/000184.html

Searching on these various lists (or via google or in my mail folders)  
hasn't uncovered a message I remember sending to one of the lists that  
addressed the question even more explicitly, but the plots from that  
message are in the first link above.  In any event, I've attempted to  
answer this question over and over and it keeps popping up.  My  
apologies for failing to find the words to make the point clear.

Briefly:  Apparent solar time is a red herring (http://www.nizkor.org/features/fallacies/red-herring.html 
).  Mean solar time is simply sidereal time (the "real" length of day  
on Earth) offset by about 4 minutes to make up for the Earth lapping  
the Sun once a year.  The issue is the stability of the rate, not some  
imagined average over lots of separate measurements of the Sun's  
apparent position in the sky.  After all, we circle the Sun, not the  
other way around.  Local time is an offset from mean solar time, not  
the other way around.

The first plot in the first link:

	http://www.mail-archive.com/leapsecs at rom.usno.navy.mil/msg00676/daylength.pdf

shows that the sidereal rate (adjusted for one lapped day per year) is  
quite stable, even when the shape of the Earth's orbit and the  
inclination of its axis are accommodated. (I'll keep looking for that  
message, it discussed all this.)  Rather, the issue is confused by the  
sundial corrections shown in the second plot, grandly named the  
"equation of time".  The EOT is nothing special, just the integral of  
the modest annual LOD excursions.  Static timezone offsets and  
periodic DST zero point adjustments are similarly beside the point.

Even briefer:  The real length of the day on the planet earth for  
human purposes is the mean solar day.  Introducing a secular trend  
into this is a poor idea with a limited lifespan.  Eventually the  
embargoed leap seconds (or equivalent) will have to be released, else  
it is the definition of "day" that will be broken.  Any viable  
proposal has to include some plan for what happens then.

>> 4) The ITU proposal is basically an assertion that people don't care
>> about mean solar time.
>
> The fact that the majority of the earths population use a legal time
> that is more than 15 minutes different from mean solaer time, would
> seem to support the ITU in this.

Local time is not the issue, has never been the issue, has nothing to  
do with the issue.

The issue is stabilizing the daily rate of the underlying "universal"  
time scale.

> Have you or others provided any documentation for the opposite claim ?

Over and over and over.

Here's another go:  As you say, it is likely that most people rely on  
local standard time that is more than 15 minutes different from local  
mean solar time at their location.  In addition, their local apparent  
solar time has excursions from their local mean time of around 15  
minutes in amplitude (although most of the year, they will be closer  
than this).  In addition, their local government may institute DST  
adjustments of an hour or more.  The citizens may also be jet lagged,  
for that matter.

However:  Everybody everywhere, throughout history, has observed a day  
whose LENGTH throughout the year is within +/- 30 SI seconds of the  
mean solar day length:

	http://www.mail-archive.com/leapsecs at rom.usno.navy.mil/msg00676/daylength.pdf

The ITU is attempting to tilt the baseline of this plot.  (Or rather,  
remove the controls that periodically accommodate the natural tilt.)   
Whether or not you believe this is an acceptable kludge, it most  
definitely is a kludge.  Such a secular trend cannot accumulate forever.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081222/2af48f1f/attachment.html>

From dot at dotat.at  Mon Dec 22 11:56:31 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 16:56:31 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: <20081222160145.GB7103@ucolick.org>
References: <49513.1229953858@uk2.net>
	<alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
	<20081222160145.GB7103@ucolick.org>
Message-ID: <alpine.LSU.2.00.0812221642280.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Steve Allen wrote:
>
> I am aware of the interesting breakages that happened when zoneinfo
> files were retroactively modified to be inconsistent with POSIX.
> Clearly that change cannot be done for past history.

It can't be done for future history either, because it breaks invariants
that are relied on all over the place.

> > There is a pervasive assumption in Unix that midnight UT is when
> > time_t % 86400 == 0.
>
> So if the broadcast time scale were to become TI then these operations
> would be taking place at "atomic day midnight" instead of mean solar
> day midnight.  That's still a legitimate kind of day.

This isn't about scheduling operations, it's about inter-converting
between a count of seconds and broken-down civil time. There are lots of
in-kernel functions and standard data formats (network protocols, file
systems) that rely on the "trivial UT" assumption of 86400 seconds per
day. POSIX time is one example amongst many.

> The argument that "atomic time will drift by no more than a few
> seconds from mean solar during this century has been used by those who
> want to abandon leaps.  In the presence of an internationally approved
> atomic time scale I think that argument goes both ways.  It doesn't
> hurt anybody if certain technical operations drift a few seconds from
> civil wall clock time.

Disseminating a linear timescale instead of UTC doesn't address the
problem if civil time continues to be UTC, because all these systems are
more tightly coupled to civil time than they are to the timescale of their
reference clock(s). Civil time is a pervasive dependency - i.e. lots of
software has built-in assumptions about its structure - whereas time
synchronization is a relatively self-contained function.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
LUNDY FASTNET IRISH SEA: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN IRISH
SEA. MODERATE, OCCASIONALLY ROUGH IN LUNDY AND FASTNET. DRIZZLE. MODERATE OR
GOOD, OCCASIONALLY POOR.

From seaman at noao.edu  Mon Dec 22 12:15:52 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 10:15:52 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <73737.1229954621@critter.freebsd.dk>
References: <73737.1229954621@critter.freebsd.dk>
Message-ID: <70692779-0276-4CB0-AAB5-43A9C2CF9C9F@noao.edu>

Poul-Henning Kamp wrote:

> There is one (major) problem: software does not grok leapseconds.

If my car fails to grok gasoline, I fix the car.  Leap seconds (or the  
equivalent) are simply a fact of life on a tidally slowing orb.  If  
you wish to eliminate the overhead of managing leap seconds over the  
short term, you have to pay the price of managing them over the long  
term.  No such management plan has been proposed.

> One of the solutions Rob peddles for this, is "Make a new timescale
> without leap seconds, and leave leap seconds in the UTC timescale".

I haven't peddled any solution (other than better managing the status  
quo).  It is premature to discuss solutions as more than brainstorming  
to better understand the problem at hand.

> This does not fly because a lot of systems are legally mandated to
> use the UTC timescale.

And others are and have been legally mandated to use mean solar time.   
The ITU is attempting to separate the two without cleaning up the  
resulting mess.  A better (and quicker) process would be to:

	1) understand the problem
	2) evaluate possible solutions
	3) seek consensus before voting

> Changing all those laws and regulations, just because a single
> astronomer is very emotionally attached to the name "UTC" is just
> not going to happen :-)

There are more on this list than a single supporter of preserving the  
meaning of UTC.  This was also the consensus in Torino.

Words like "emotionally attached" add nothing to the discussion.

Rob


From seaman at noao.edu  Mon Dec 22 12:20:57 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 10:20:57 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <72930.1229947212@critter.freebsd.dk>
References: <72930.1229947212@critter.freebsd.dk>
Message-ID: <2346F99C-35F5-4B73-BEB8-90C2AC9E004A@noao.edu>

Poul-Henning Kamp wrote:

> In message <EC8CC227-DC49-458A-9725-3CE5DDC8F579 at noao.edu>, Rob  
> Seaman writes:
>
>> You may disagree with his premises, but the request was for  
>> candidates
>> for completely standalone systems requiring high precision clocks.
>
> No, the request was for systems that could not have software updates
> applied willy-nilly every six months.

Here is the original message:

	http://six.pairlist.net/pipermail/leapsecs/2008-December/000681.html

Clearly our interpretation of the question asked differs.  In any  
event, that thread has moved on.

Rob


From imp at bsdimp.com  Mon Dec 22 12:32:33 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 22 Dec 2008 10:32:33 -0700 (MST)
Subject: [LEAPSECS] (no subject)
In-Reply-To: <alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
References: <49513.1229953858@uk2.net>
	<alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
Message-ID: <20081222.103233.-1303463668.imp@bsdimp.com>

In message: <alpine.LSU.2.00.0812221354000.9904 at hermes-1.csi.cam.ac.uk>
            Tony Finch <dot at dotat.at> writes:
: On Mon, 22 Dec 2008, Peter Vince wrote:
: >
: > I am trying to clarify in my mind a couple of proposals, one of which is
: > having no more leap-seconds in the civil (broadcast) time scale.  I'm
: > sorry, I must have missed your messages where you said that a lot of
: > software would fail in that scenario - could you briefly clarify please?
: 
: This isn't really about broadcast timescales, but about the semantics of
: POSIX time_t. Steve proposes to provide a well-defined uniform timescale
: on Unix systems by redefining time_t to follow some linear atomic
: timescale instead of UTC, and that the zoneinfo/tzcode library would be
: used to translate from this new version of time_t to UTC, using a leap
: second table alongside the existing time zone tables.
: 
: The code to implement this has in fact already been written, 15 or more
: years ago, but no-one uses it because it breaks too much stuff. For
: example, there is a lot of time-handling code in the kernel, and because
: it does not link with the tzcode library the proposed architecture doesn't
: accommodate its requirements. There's also a lot of code which doesn't use
: the C tzcode for time handling, such as the Java runtime. There is a
: pervasive assumption in Unix that midnight UT is when t % 86400 == 0.

This has been called the 'naive math' problem.  Applications don't
fill out struct tm's to compute time_t's.  If they all did, time_t's
definitions wouldn't matter so much.  However, many of them *KNOW*
that it *IS* seconds since 1970 (with leap seconds swizzled in, so you
can ignore them entirely).  So the time_t for Feb 15, 2008 1:23:34 is computed
like so:

     time_t t = ((2008 - 1970) * 365 + 9) * 86400 + 1 * 3600 + 23 * 60
	     + 34;

Which is broken with the above software: it is off by the number of
leap seconds.

There's another problem.  NFS requires UTC time stamps (the
unredefined time_t values), so you have to know about leap seconds,
and when they all happened to get the times right.  Again, you could
say "who cares" but lots of people do care about pedantic correctness,
so you get bugs when things aren't exactly right.  These conversions
need to happen an all file accesses, so that can have a big negative
performance effect, since rather than just copying 4 bytes, you have
to do a table lookup (at beast O(ln(#leapseconds)).  There's no way to
compute leap seconds in the kernel without it.

Warner

From dot at dotat.at  Mon Dec 22 12:48:24 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 17:48:24 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: <20081222.103233.-1303463668.imp@bsdimp.com>
References: <49513.1229953858@uk2.net>
	<alpine.LSU.2.00.0812221354000.9904@hermes-1.csi.cam.ac.uk>
	<20081222.103233.-1303463668.imp@bsdimp.com>
Message-ID: <alpine.LSU.2.00.0812221743090.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, M. Warner Losh wrote:
>
> Applications don't fill out struct tm's to compute time_t's.  If they
> all did, time_t's definitions wouldn't matter so much.  However, many of
> them *KNOW* that it *IS* seconds since 1970 (with leap seconds swizzled
> in, so you can ignore them entirely).

There are good reasons for this. I mentioned Java because libraries for
languages other than C often want a native implementation of time and date
functions so that they fit in better with the rest of the language.
There's also the fact that the standard C library is bad in many ways so
it's common for programmers to try to improve on it.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
HUMBER THAMES DOVER: WEST OR NORTHWEST BACKING SOUTHWEST 4 OR 5, BUT BECOMING
VARIABLE 3 IN DOVER. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD,
OCCASIONALLY POOR.

From seaman at noao.edu  Mon Dec 22 13:05:17 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 11:05:17 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081222.092053.146405415.imp@bsdimp.com>
References: <m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
	<m3bpv4with.fsf@lugabout.jhcloos.org>
	<20081222.092053.146405415.imp@bsdimp.com>
Message-ID: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>

So many messages, so little time!

M. Warner Losh wrote:

> In general, all systems need to be synchronized to human time  
> because at some point they have to interact with humans.


	Right.  And human time is synchronized with mean solar time because  
we happen to live on the planet Earth.  What we are debating is how  
this synchronization should happen and on what schedule.

> Sure, it usually doesn't matter much, and you can usually get away  
> with it, but that reason alone is not sufficient to say it is never  
> a problem.


	No, but it is a good argument for following a coherent and  
transparent decision-making process, and for not rushing into a bad  
decision.

> Since we've only been using them for 40 years, there's no real  
> posterity to worry about.


	No.  We have been using mean solar time formally since the 19th  
century, and informally since we woke each morning to light shining  
through the entrance of the cave.  Leap seconds are simply the current  
mechanism for instituting a civil timescale based on mean solar time.

> Since we're going to have to have them with increasing regularity  
> over the next 50 years, to the point where 2 a year are unlikely to  
> be enough, we need to ask ourselves if there's some better way to  
> distribute time than what we're doing.

	The frequency over the next 50 years will be similar to the past 50  
years, and likely for a couple of centuries after that:

	http://six.pairlist.net/pipermail/leapsecs/2008-January/000184.html

It would be delightful to discuss better ways to define and distribute  
civil and professional timescales.  It is hard to find time to do this  
after 9 years of persistent attempts to rush to judgement.

Rob


From dot at dotat.at  Mon Dec 22 13:17:02 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 18:17:02 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
References: <m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
	<m3bpv4with.fsf@lugabout.jhcloos.org>
	<20081222.092053.146405415.imp@bsdimp.com>
	<8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
Message-ID: <alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Rob Seaman wrote:
>
> 	No.  We have been using mean solar time formally since the 19th
> century, and informally since we woke each morning to light shining through
> the entrance of the cave.

Apparent solar time is not mean solar time. Remember that for a lot of
history we used rubber hours that varied according to the time between
sunrise and sunset. Mean solar time cannot be established without
reasonably accurate clocks.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
LUNDY FASTNET IRISH SEA: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN IRISH
SEA. MODERATE, OCCASIONALLY ROUGH IN LUNDY AND FASTNET. OCCASIONAL DRIZZLE.
MODERATE OR GOOD, OCCASIONALLY POOR.

From seaman at noao.edu  Mon Dec 22 13:27:49 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 11:27:49 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
References: <m3prjlxz5z.fsf@lugabout.jhcloos.org>
	<20081221.232639.-432836607.imp@bsdimp.com>
	<m3bpv4with.fsf@lugabout.jhcloos.org>
	<20081222.092053.146405415.imp@bsdimp.com>
	<8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>

Tony Finch wrote:

> On Mon, 22 Dec 2008, Rob Seaman wrote:
>>
>> 	No.  We have been using mean solar time formally since the 19th
>> century, and informally since we woke each morning to light shining  
>> through
>> the entrance of the cave.
>
> Apparent solar time is not mean solar time. Remember that for a lot of
> history we used rubber hours that varied according to the time between
> sunrise and sunset. Mean solar time cannot be established without
> reasonably accurate clocks.

Either you haven't read this message yet:

	http://six.pairlist.net/pipermail/leapsecs/2008-December/000714.html

or I've yet again failed to make my point.

Mother Earth "establishes" mean solar time simply by spinning on its  
axis and orbiting the sun.  Apparent solar time is a mere happenstance  
of angles.  Rates matter more than offsets.

Rob


From phk at phk.freebsd.dk  Mon Dec 22 13:27:58 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 18:27:58 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Mon, 22 Dec 2008 10:15:52 MST."
	<70692779-0276-4CB0-AAB5-43A9C2CF9C9F@noao.edu> 
Message-ID: <74721.1229970478@critter.freebsd.dk>

In message <70692779-0276-4CB0-AAB5-43A9C2CF9C9F at noao.edu>, Rob Seaman writes:

>And others are and have been legally mandated to use mean solar time.   

Examples, please ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Mon Dec 22 13:34:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 18:34:33 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Mon, 22 Dec 2008 11:05:17 MST."
	<8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu> 
Message-ID: <74771.1229970873@critter.freebsd.dk>

In message <8B194364-41A0-4565-9F5A-4DC99219BFC5 at noao.edu>, Rob Seaman writes:

>	Right.  And human time is synchronized with mean solar time [...]

What do you really mean by "Synchronized ?"

The civil (and therefore human) time at any spot on the planet, is
offset up to several hours from, and steps up to one hour, due to
DST, relative to any kind of physically based solar time you might
care to name.

You claim seems to be that this "synchronization" has to be nailed
at the sub-second level ?

Again, I have yet to see any sort of data backing up this tacit
claim of yours ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From imp at bsdimp.com  Mon Dec 22 13:35:20 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 22 Dec 2008 11:35:20 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
References: <m3bpv4with.fsf@lugabout.jhcloos.org>
	<20081222.092053.146405415.imp@bsdimp.com>
	<8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
Message-ID: <20081222.113520.-233675053.imp@bsdimp.com>

In message: <8B194364-41A0-4565-9F5A-4DC99219BFC5 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: So many messages, so little time!
: 
: M. Warner Losh wrote:
: 
: > In general, all systems need to be synchronized to human time  
: > because at some point they have to interact with humans.
: 
: 
: 	Right.  And human time is synchronized with mean solar time because  
: we happen to live on the planet Earth.  What we are debating is how  
: this synchronization should happen and on what schedule.

No.  We're synchronized with mean solar time at an arbitrary location
on the globe that happens to no longer even be on the prime meridian
anymore since GPS' new definition of the geoid.  And we're not
counting 'natural' seconds anymore either: they are based on
oscillations of atoms, not on the rotation of the earth.  Who the flip
cares of the 'prime' meridian (defined as the places where 0:00:00
corresponds to midnight astronomically) drifts a bit.  It just doesn't
matter to people.

: > Sure, it usually doesn't matter much, and you can usually get away  
: > with it, but that reason alone is not sufficient to say it is never  
: > a problem.
: 
: 	No, but it is a good argument for following a coherent and  
: transparent decision-making process, and for not rushing into a bad  
: decision.

True, but not relevant to this discussion.  You often conflate the
decision making process of some committee with the current leap second
system.  They aren't relevant to discussing the current problems.

: > Since we've only been using them for 40 years, there's no real  
: > posterity to worry about.
: 
: 
: 	No.  We have been using mean solar time formally since the 19th  
: century, and informally since we woke each morning to light shining  
: through the entrance of the cave.  Leap seconds are simply the current  
: mechanism for instituting a civil timescale based on mean solar time.

No.  We've been using leap seconds for 40 years.  We used actual local
solar time before the 19th century for a few thousand years before
that.  The main benefit of using standard time zones is everybody
using the same time.  It isn't that it is mean solar time, that just
happened to be one way to define things that is arbitrary based on
some set of aesthetics.  It was useful when the second was not
realized precisely enough to there to be a difference between the
second and 1/86400th of the day.  Now that we've defined the second to
not be 1/86400th of the day, the aesthetics of the situation has
changed.  We should really consider if it still matters to have things
based on mean solar time at an arbitrary meridian, or if such a
coupling really matters at all.  This is the crux of the debate: I
think it is silly, you think it is so obviously critical that we can't
find common ground on this point.

: > Since we're going to have to have them with increasing regularity  
: > over the next 50 years, to the point where 2 a year are unlikely to  
: > be enough, we need to ask ourselves if there's some better way to  
: > distribute time than what we're doing.
: 
: 	The frequency over the next 50 years will be similar to the past 50  
: years, and likely for a couple of centuries after that:
: 
: 	http://six.pairlist.net/pipermail/leapsecs/2008-January/000184.html
: 
: It would be delightful to discuss better ways to define and distribute  
: civil and professional timescales.  It is hard to find time to do this  
: after 9 years of persistent attempts to rush to judgement.

The frequency of the next 50 years is likely to be higher than that of
the previous 50 years because the earth's deceleration has been
accelerating.  Of course, given how hard it is to predict the rotation
of the earth, who can say for sure.  I'm afraid I don't have a paper
reference for this, I learned of it talking with Judah Levine one day
about other issues (like why he was seeing issues with the measurement
system my company had deployed for him).  I've heard others on this
list refer to it as well.

Warner

From imp at bsdimp.com  Mon Dec 22 13:43:03 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 22 Dec 2008 11:43:03 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
References: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
	<F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
Message-ID: <20081222.114303.58457443.imp@bsdimp.com>

In message: <F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Tony Finch wrote:
: 
: > On Mon, 22 Dec 2008, Rob Seaman wrote:
: >>
: >> 	No.  We have been using mean solar time formally since the 19th
: >> century, and informally since we woke each morning to light shining  
: >> through
: >> the entrance of the cave.
: >
: > Apparent solar time is not mean solar time. Remember that for a lot of
: > history we used rubber hours that varied according to the time between
: > sunrise and sunset. Mean solar time cannot be established without
: > reasonably accurate clocks.
: 
: Either you haven't read this message yet:
: 
: 	http://six.pairlist.net/pipermail/leapsecs/2008-December/000714.html
: 
: or I've yet again failed to make my point.
: 
: Mother Earth "establishes" mean solar time simply by spinning on its  
: axis and orbiting the sun.  Apparent solar time is a mere happenstance  
: of angles.  Rates matter more than offsets.

But the second is no longer defined in terms of solar time, so why
does this really matter?  UTC isn't the same as local time for most of
the planet.  We already do time zones, and we already accept an hour
or two of difference between our local time and the sun's time.  Why
then the slavish need to keep UTC corresponding to the time at what is
at best an arbitrary meridian?  The second no longer measures earth
time.

Warner

From seaman at noao.edu  Mon Dec 22 14:12:01 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 12:12:01 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <74721.1229970478@critter.freebsd.dk>
References: <74721.1229970478@critter.freebsd.dk>
Message-ID: <174DA871-5A3D-4558-8522-EAE34BA7E05C@noao.edu>

Poul-Henning Kamp wrote:

> In message <70692779-0276-4CB0-AAB5-43A9C2CF9C9F at noao.edu>, Rob  
> Seaman writes:
>
>> And others are and have been legally mandated to use mean solar time.
>
> Examples, please ?

This issue has come up repeatedly.

Apparently Denmark:

	http://www.mail-archive.com/leapsecs at leapsecond.com/msg00509.html

And the UK and EU (not sure how EU policies would resolve local  
differences):

	http://six.pairlist.net/pipermail/leapsecs/2007-August/000091.html

In any event, the UTC standard itself originally contained language:

	"GMT may be regarded as the general equivalent of UT."

Rob


From seaman at noao.edu  Mon Dec 22 14:18:39 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 12:18:39 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081222.114303.58457443.imp@bsdimp.com>
References: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
	<F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
	<20081222.114303.58457443.imp@bsdimp.com>
Message-ID: <8AC28472-EE68-4874-8623-51E2B15999DC@noao.edu>

The fact that the mean solar rate differs from the SI rate is the  
whole enchilada.  I have to put the Christmas lights on the tree, but  
you could search leapsecs for "secular" and "periodic" to locate my  
screed on this topic.

Rob
--

On Dec 22, 2008, at 11:43 AM, M. Warner Losh wrote:

> In message: <F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7 at noao.edu>
>            Rob Seaman <seaman at noao.edu> writes:
> : Tony Finch wrote:
> :
> : > On Mon, 22 Dec 2008, Rob Seaman wrote:
> : >>
> : >> 	No.  We have been using mean solar time formally since the 19th
> : >> century, and informally since we woke each morning to light  
> shining
> : >> through
> : >> the entrance of the cave.
> : >
> : > Apparent solar time is not mean solar time. Remember that for a  
> lot of
> : > history we used rubber hours that varied according to the time  
> between
> : > sunrise and sunset. Mean solar time cannot be established without
> : > reasonably accurate clocks.
> :
> : Either you haven't read this message yet:
> :
> : 	http://six.pairlist.net/pipermail/leapsecs/2008-December/ 
> 000714.html
> :
> : or I've yet again failed to make my point.
> :
> : Mother Earth "establishes" mean solar time simply by spinning on its
> : axis and orbiting the sun.  Apparent solar time is a mere  
> happenstance
> : of angles.  Rates matter more than offsets.
>
> But the second is no longer defined in terms of solar time, so why
> does this really matter?  UTC isn't the same as local time for most of
> the planet.  We already do time zones, and we already accept an hour
> or two of difference between our local time and the sun's time.  Why
> then the slavish need to keep UTC corresponding to the time at what is
> at best an arbitrary meridian?  The second no longer measures earth
> time.
>
> Warner


From phk at phk.freebsd.dk  Mon Dec 22 14:23:46 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 22 Dec 2008 19:23:46 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: Your message of "Mon, 22 Dec 2008 12:12:01 MST."
	<174DA871-5A3D-4558-8522-EAE34BA7E05C@noao.edu> 
Message-ID: <74968.1229973826@critter.freebsd.dk>

In message <174DA871-5A3D-4558-8522-EAE34BA7E05C at noao.edu>, Rob Seaman writes:
>Poul-Henning Kamp wrote:

>>> And others are and have been legally mandated to use mean solar time.
>>
>> Examples, please ?
>
>This issue has come up repeatedly.
>
>Apparently Denmark:
>
>	http://www.mail-archive.com/leapsecs at leapsecond.com/msg00509.html

The fact that Denmark does not follow its own law on this point
is a severe blow to your argument.

Do you have any *real* examples ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dot at dotat.at  Mon Dec 22 14:24:07 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 19:24:07 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <8AC28472-EE68-4874-8623-51E2B15999DC@noao.edu>
References: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
	<F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
	<20081222.114303.58457443.imp@bsdimp.com>
	<8AC28472-EE68-4874-8623-51E2B15999DC@noao.edu>
Message-ID: <alpine.LSU.2.00.0812221919480.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Rob Seaman wrote:

> The fact that the mean solar rate differs from the SI rate is the whole
> enchilada.  I have to put the Christmas lights on the tree, but you could
> search leapsecs for "secular" and "periodic" to locate my screed on this
> topic.

The mean length of year differs from the Gregorian calendar's average
length. Should we switch to the French Revolutionary Calendar to prevent
Christmas drifting away further and faster from the winter solstice?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: NORTHWESTERLY 5 OR 6 BACKING SOUTHERLY 4 OR 5,
INCREASING 6 OR 7 LATER IN NORTH UTSIRE. VERY ROUGH BECOMING MODERATE.
FAIR THEN RAIN. MODERATE OR GOOD, BECOMING OCCASIONALLY POOR.

From dot at dotat.at  Mon Dec 22 15:05:31 2008
From: dot at dotat.at (Tony Finch)
Date: Mon, 22 Dec 2008 20:05:31 +0000
Subject: [LEAPSECS] (no subject)
In-Reply-To: <74968.1229973826@critter.freebsd.dk>
References: <74968.1229973826@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0812221924170.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Poul-Henning Kamp wrote:
>
> The fact that Denmark does not follow its own law on this point
> is a severe blow to your argument.

The thing that amused me about the WP7A update was Britain objecting to
the demise of leap seconds. Our government abolished the Royal Greenwich
Observatory because it had nothing useful left to do. Our timekeeping lab
is the National Physical Laboratory. The other major part of the RGO was
the Nautical Almanac Office which is now the Hydrographic Office, which
produces nautical charts. I doubt we even have any government agency still
involved in earth orientation - about the closest we have is the STFC
which funds a number of physics and astronomy research facilities. I can't
imagine it's that hard to fix our obsolete time legislation, which even
the Government ignores - our official time references (MSF, the BBC, the
stratim 1 NTP servers at the LINX) are all UTC, not GMT. Bah.

On the other hand, perhaps the relevant civil servant doesn't want to put
a time-related bill in front of parliament, because they'll probably start
blethering about BST, whether the Scots can live with CET, when the Easter
Act will be put into force, et cetera ad nauseam, until time runs out and
the bill never gets enacted. Bah.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
HEBRIDES BAILEY FAIR ISLE FAEROES SOUTHEAST ICELAND SOUTHERLY OR SOUTHWESTERLY
VEERING WESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN BAILEY AND SOUTHEAST ICELAND,
PERHAPS GALE 8 LATER IN HEBRIDES, FAIR ISLE AND FAEROES. VERY ROUGH OR HIGH.
OCCASIONAL RAIN THEN MAINLY FAIR. MODERATE OR POOR BECOMING GOOD.

From msokolov at ivan.Harhan.ORG  Mon Dec 22 15:12:40 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 22 Dec 2008 20:12:40 GMT
Subject: [LEAPSECS] Schedule for success
Message-ID: <0812222012.AA04263@ivan.Harhan.ORG>

Tony Finch <dot at dotat.at> wrote:

> Should we switch to the French Revolutionary Calendar to prevent
> Christmas drifting away further and faster from the winter solstice?

Yes, absolutely!  Or even better, the Republic of Terra Calendar:

http://ivan.Harhan.ORG/RT/Calendar/spec.txt

MS

From jhein at timing.com  Mon Dec 22 16:12:07 2008
From: jhein at timing.com (John Hein)
Date: Mon, 22 Dec 2008 14:12:07 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <0812222012.AA04263@ivan.Harhan.ORG>
References: <0812222012.AA04263@ivan.Harhan.ORG>
Message-ID: <18768.679.805017.706247@gromit.timing.com>

Michael Sokolov wrote at 20:12 GMT on Dec 22, 2008:
 > Tony Finch <dot at dotat.at> wrote:
 > > Should we switch to the French Revolutionary Calendar to prevent
 > > Christmas drifting away further and faster from the winter solstice?
 > 
 > Yes, absolutely!  Or even better, the Republic of Terra Calendar:
 > 
 > http://ivan.Harhan.ORG/RT/Calendar/spec.txt

By the way, that's a lower case 'c' in 'calendar'.  Let me guess, you
use outlook or something similarly helpful.

From msokolov at ivan.Harhan.ORG  Mon Dec 22 16:23:48 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 22 Dec 2008 21:23:48 GMT
Subject: [LEAPSECS] Schedule for success
Message-ID: <0812222123.AA04524@ivan.Harhan.ORG>

John Hein <jhein at timing.com> wrote:

> By the way, that's a lower case 'c' in 'calendar'.

Yes, thank you for catching my mistake; the correct URL is:

http://ivan.Harhan.ORG/RT/calendar/spec.txt

It was a human mistake on my part, I had typed the URL in from memory
without checking it.

> Let me guess, you
> use outlook or something similarly helpful.

Oh no, absolutely not, Microsuxx software (both OSes and apps) is
totally banned at this facility.  I use the UNIX Mail program on
4.3BSD-Quasijarus, which is just one notch above whisting into a phone
to create modem tones corresponding to 0s and 1s in terms of software
sophistication.

And by the way, this adamantly non-POSIX UNIX system uses rubber seconds!

MS

From seaman at noao.edu  Mon Dec 22 18:36:28 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 16:36:28 -0700
Subject: [LEAPSECS] (no subject)
In-Reply-To: <74968.1229973826@critter.freebsd.dk>
References: <74968.1229973826@critter.freebsd.dk>
Message-ID: <0A0DF28D-C4CA-4BB5-8415-85F9CF8B0FE1@noao.edu>

You appear to be trying to get a rise out of me.  Nothing in my  
previous messages were predicated on the de jure or de facto policies  
of any governments.  That seems to be a facet of your argument.  You  
asked for an example.  I provided.

You also previously chided me to read the archives.  I could advise  
same.

Rob
---

On Dec 22, 2008, at 12:23 PM, Poul-Henning Kamp wrote:

> In message <174DA871-5A3D-4558-8522-EAE34BA7E05C at noao.edu>, Rob  
> Seaman writes:
>> Poul-Henning Kamp wrote:
>
>>>> And others are and have been legally mandated to use mean solar  
>>>> time.
>>>
>>> Examples, please ?
>>
>> This issue has come up repeatedly.
>>
>> Apparently Denmark:
>>
>> 	http://www.mail-archive.com/leapsecs at leapsecond.com/msg00509.html
>
> The fact that Denmark does not follow its own law on this point
> is a severe blow to your argument.
>
> Do you have any *real* examples ?


From seaman at noao.edu  Mon Dec 22 18:52:48 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 16:52:48 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <alpine.LSU.2.00.0812221919480.10002@hermes-1.csi.cam.ac.uk>
References: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
	<F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
	<20081222.114303.58457443.imp@bsdimp.com>
	<8AC28472-EE68-4874-8623-51E2B15999DC@noao.edu>
	<alpine.LSU.2.00.0812221919480.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <32B4B232-6733-4092-9BD9-9E414DE7EF8F@noao.edu>

I guess the looming leap second is preying on everybody's mind :-)

By "whole enchilada", I meant the essence of the problem.  Do you  
disagree?

When the calendar drifts far enough away for some future potentate to  
decree that something must be done, what will be done is the insertion  
(or omission) of an integral number of days in an intercalary event.   
The mechanism is clear, the policy is lacking.  The ITU proposal is  
lacking not just guidance on policy for the equivalent clock issue,  
but fails to even speculate on options for a mechanism.

Rob
---

> On Mon, 22 Dec 2008, Rob Seaman wrote:
>
>> The fact that the mean solar rate differs from the SI rate is the  
>> whole
>> enchilada.  I have to put the Christmas lights on the tree, but you  
>> could
>> search leapsecs for "secular" and "periodic" to locate my screed on  
>> this
>> topic.
>
> The mean length of year differs from the Gregorian calendar's average
> length. Should we switch to the French Revolutionary Calendar to  
> prevent
> Christmas drifting away further and faster from the winter solstice?
>
> Tony.

From seaman at noao.edu  Mon Dec 22 19:37:39 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 17:37:39 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081222.113520.-233675053.imp@bsdimp.com>
References: <m3bpv4with.fsf@lugabout.jhcloos.org>
	<20081222.092053.146405415.imp@bsdimp.com>
	<8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<20081222.113520.-233675053.imp@bsdimp.com>
Message-ID: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>

M. Warner Losh wrote:

> We should really consider if it still matters to have things based  
> on mean solar time at an arbitrary meridian, or if such a coupling  
> really matters at all.  This is the crux of the debate: I think it  
> is silly, you think it is so obviously critical that we can't find  
> common ground on this point.


Actually, if this mailing list had any influence on policy-making, I  
suspect we could easily find common ground.  These discussions are  
nothing compared to some other working groups I've seen :-)

I have failed to make my argument clear that civil timekeeping is  
equivalent (in the sense of a mathematical identity) to some stable  
approximation to mean solar time.  I don't really need to make this  
argument, because the solar system will make it for me in the fullness  
of time :-)

Which is to say - you appear to believe that I am insisting on some  
sort of whimsical policy choice.  Rather, it is a trite truism.  The  
coupling you mention matters because it actually exists.  The issues  
are how much the coupling matters, and what level of approximation is  
sufficient, and how shall it be implemented.  There is room for all  
the different notional positions that have ever been mentioned on the  
list.  However, how well those positions are evaluated depends on  
appropriateness of the mental model used.

Over and over again - certainly within the ITU proposal - arguments  
are made based on the assumption that the underlying timescale is a  
free parameter.  This is simply untrue.  Solid arguments can't be  
built on faulty premises.  A day cannot be redefined to have 100,000  
SI seconds.  It likely cannot be redefined to have 86401 SI seconds.

 From the top:  Since the SI second was defined to be close to the  
mean solar second, it is possible for the ITU to cheat for a while.   
Eventually this will no longer be acceptable.  It doesn't seem too  
much to ask, for instance, that their proposal actually include a  
sunset provision.  (Pun noted.)

Rob


From seaman at noao.edu  Mon Dec 22 20:56:37 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 18:56:37 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <74771.1229970873@critter.freebsd.dk>
References: <74771.1229970873@critter.freebsd.dk>
Message-ID: <31FA28B5-6F48-42BC-81EA-A20572D5EE7E@noao.edu>

Poul-Henning Kamp wrote:

> Rob Seaman writes:
>
>> Right.  And human time is synchronized with mean solar time [...]
>
> What do you really mean by "Synchronized ?"

The sun rises, the sun sets.  We care about this in innumerable ways.

Other than that, this is the precise issue we have been debating for 9  
years.

> The civil (and therefore human) time at any spot on the planet, is
> offset up to several hours from, and steps up to one hour, due to
> DST, relative to any kind of physically based solar time you might
> care to name.

Again see:

	http://six.pairlist.net/pipermail/leapsecs/2008-December/000714.html

> You claim seems to be that this "synchronization" has to be nailed
> at the sub-second level ?

Over long periods of time, it has to average to near zero.  Over short  
periods of time it is better to manage the issue than to ignore it.

Uncontrolled secular trends (as proposed by ITU) are untenable.  The  
amplitude of periodic effects needs to be bounded.  The duration  
between "resets" (of whatever sort) should be short enough for  
continuity of oversight.  The mean of the waveform is mean solar time.

> Again, I have yet to see any sort of data backing up this tacit
> claim of yours ?

See above and included messages.  The alternative is to believe that  
humanity would put up with some bizarre civilization where day and  
night don't matter.

Tacit:
	1) understood without being openly expressed
	2) silent; saying nothing
	3) unvoiced or unspoken

Clearly this word has nothing to do with me :-)

Rob

From seaman at noao.edu  Mon Dec 22 21:25:27 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 22 Dec 2008 19:25:27 -0700
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <72897.1229947155@critter.freebsd.dk>
References: <72897.1229947155@critter.freebsd.dk>
Message-ID: <8FF6A915-DB87-4CD9-BDC9-93E4D2C24FB7@noao.edu>

Finally!  All will be happy to know that I've dug back to the  
beginning of this morning's crop of messages :-)

Poul-Henning Kamp wrote:

> But if you do not make a credible case that something is being  
> overlooked, nobody is going to waste time on your proposed process  
> to look for things that are being overlooked.

I work in the astronomical community.  Many long, long years ago, when  
this issue was first broached, we started vetting issues pertaining to  
astronomy.  This change would surely cost us millions of dollars.   
Criticizing the one group who have taken the time to look is rather  
brazen.

You have mentioned planes, trains, shipping, power and military  
applications.  I gather you have experience with these projects.   
Somehow it is my job to vet your systems from the outside?  At the  
very least, grep the source for terms like "DUT1" to search for the  
Y2K-like issues.  This won't catch the implicit dependencies on Earth  
orientation.  Perhaps there are none.  If so, a risk analysis should  
be straightforward.  That isn't an argument to skip it.

> Proposing red tape commisions in the absence of evidence of their  
> need, is a widely recognized stalling tactic.

Again, I find it truly bizarre that after all my previous rhetorical  
gambits, the one topic that gets a rise out of the group is a simple,  
heartfelt suggestion that proper system engineering practices be  
followed.

	System engineering != red tape

Far from stalling, separating problem definition and requirements  
discovery from a tradeoff study of possible solutions is the fastest  
way to proceed.

Rob


From phk at phk.freebsd.dk  Tue Dec 23 03:43:40 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 23 Dec 2008 08:43:40 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Mon, 22 Dec 2008 17:37:39 MST."
	<26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu> 
Message-ID: <4217.1230021820@critter.freebsd.dk>

In message <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE at noao.edu>, Rob Seaman writes:

>I have failed to make my argument clear that civil timekeeping is  
>equivalent (in the sense of a mathematical identity) to some stable  
>approximation to mean solar time.

I don't think anybody disputes that.

The current argument seems to consist of you claiming that the
tolerance be on the order of one second, for reasons you have not
provided any hint off, but want to start a red-tape commision on.

The rest of us have no trouble with a tolerance of up to (at least)
one hour, because that's what is already the reality for 99.9..%
of the population.

I'm still looking for the "poster boy" reason for your 1sec tolerance
claim.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 23 03:48:20 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 23 Dec 2008 08:48:20 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: Your message of "Mon, 22 Dec 2008 19:25:27 MST."
	<8FF6A915-DB87-4CD9-BDC9-93E4D2C24FB7@noao.edu> 
Message-ID: <4264.1230022100@critter.freebsd.dk>

In message <8FF6A915-DB87-4CD9-BDC9-93E4D2C24FB7 at noao.edu>, Rob Seaman writes:

>I work in the astronomical community.  Many long, long years ago, when  
>this issue was first broached, we started vetting issues pertaining to  
>astronomy.  This change would surely cost us millions of dollars.   
>Criticizing the one group who have taken the time to look is rather  
>brazen.

And I have told you over and over, that if astronomers got their
act together, they would get this upgrade in the blink of an eye
if business which have real money riding on the leap-second could
get rid of them.

>At the  
>very least, grep the source for terms like "DUT1" to search for the  
>Y2K-like issues.

This, again, shows that you simply don't understand what our trouble
is.  We do not need to grep for DUT1, because it's not there, we don't
care about DUT1.

What we need to do, at every single leap-second, is to sit and
monitor N computers, to see if they all agreed about the existence
of the leap-second, if their operating systems all did the
standards-mandated stupidity of replaying the 23:59:59 second in
unison and if any applications croaked because of that.

If the computers are hooked up to important or dangerous hardware,
we have to stop that hardware before the leap-second, and start
it again afterwards.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dot at dotat.at  Tue Dec 23 08:40:00 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 23 Dec 2008 13:40:00 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <32B4B232-6733-4092-9BD9-9E414DE7EF8F@noao.edu>
References: <8B194364-41A0-4565-9F5A-4DC99219BFC5@noao.edu>
	<alpine.LSU.2.00.0812221814270.10002@hermes-1.csi.cam.ac.uk>
	<F0158734-CA0B-4CD1-BB0E-6B0AD31A1EB7@noao.edu>
	<20081222.114303.58457443.imp@bsdimp.com>
	<8AC28472-EE68-4874-8623-51E2B15999DC@noao.edu>
	<alpine.LSU.2.00.0812221919480.10002@hermes-1.csi.cam.ac.uk>
	<32B4B232-6733-4092-9BD9-9E414DE7EF8F@noao.edu>
Message-ID: <alpine.LSU.2.00.0812231335420.10002@hermes-1.csi.cam.ac.uk>

On Mon, 22 Dec 2008, Rob Seaman wrote:
>
> When the calendar drifts far enough away for some future potentate to decree
> that something must be done, what will be done is the insertion (or omission)
> of an integral number of days in an intercalary event.  The mechanism is
> clear, the policy is lacking.  The ITU proposal is lacking not just guidance
> on policy for the equivalent clock issue, but fails to even speculate on
> options for a mechanism.

The point of the calendrical comparison is that people prefer a fixed
arithmetic calendar that's stable over long periods, and they don't like
unpredictable observational calendars even if they are always accurate.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FISHER GERMAN BIGHT: WEST 3 OR 4, VEERING NORTHWEST 5 TO 7, PERHAPS GALE 8
LATER IN FISHER. ROUGH BECOMING MODERATE, OCCASIONALLY SLIGHT LATER IN SOUTH
GERMAN BIGHT. DRIZZLE LATER. GOOD, BECOMING MODERATE OR POOR.

From dan at tobias.name  Tue Dec 23 08:49:54 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 23 Dec 2008 08:49:54 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <4217.1230021820@critter.freebsd.dk>
References: <Your message of "Mon, 22 Dec 2008 17:37:39 MST."
	<26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu> >,
	<4217.1230021820@critter.freebsd.dk>
Message-ID: <4950A632.19177.1AF7BB8E@dan.tobias.name>

On 23 Dec 2008 at 8:43, Poul-Henning Kamp wrote:

> The rest of us have no trouble with a tolerance of up to (at least)
> one hour, because that's what is already the reality for 99.9..%
> of the population.

And then your distant descendants will throw a huge fit about the 
possibility of a leap hour being imposed, which would be much more 
noticeably disruptive than leap seconds, and will indefinitely block 
such a thing, until some day noon comes in the middle of the night.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From dot at dotat.at  Tue Dec 23 09:10:46 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 23 Dec 2008 14:10:46 +0000
Subject: [LEAPSECS] sunrise time is the solution!
Message-ID: <alpine.LSU.2.00.0812231341150.9904@hermes-1.csi.cam.ac.uk>

It occurs to me that my proposal for a rational replacement for daylight
saving time also provides an answer to the leap second question.

http://catless.ncl.ac.uk/Risks/25.10.html#subj1

The essence of sunrise time is that we reset our clocks each day to a
fixed time when the sun rises at a benchmark location. For the UK, the
benchmark location would be where the Greenwich meridian crosses the
Tropic of Cancer. The fixed time is 06:44, which is the time of the latest
sunrise at that location according to mean solar time (UT1). The reset is
accomplished by adjusting your timezone offset, which you'd do a few hours
earlier than sunrise to avoid disrupting early risers, and you'd round the
offset to the nearest minute to avoid breaking things like ISO 8601.

If you are setting civil time according to these rules, then civil time is
by definition coupled to the rotation of the Earth, and there can be no
accelerating secular difference between the two. This is true whatever
time scale you use as the basis from which timezone offsets are
calculated. You have a pretty free choice of basis timescale long as
its length of day is not too far from the Earth's LOD.

The resulting system has several useful properties:

* You can use atomic time as your basis timescale, with a LOD of 86400
SI seconds.

* The only other time(s) you need to worry about are local time(s), just
like the current situation.

* Both basis time and local time have fixed-length minutes and hours,
which is much simpler than the current situation.

* Basis time has fixed-length days, which is also a simplification.

* Local time has variable-length days, just like the current situation.

* Small timezone adjustments are less disruptive than large ones.

* Frequent timezone adjustments make timezone-related bugs more obvious
and therefore easier to fix.

* It preserves the role of Earth location scientists in time keeping.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTH UTSIRE: SOUTHERLY 3 OR 4 VEERING NORTHWESTERLY 5 TO 7. MODERATE.
DRIZZLE THEN FAIR. MODERATE BECOMING GOOD.

From seaman at noao.edu  Tue Dec 23 09:33:26 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 23 Dec 2008 07:33:26 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <4217.1230021820@critter.freebsd.dk>
References: <4217.1230021820@critter.freebsd.dk>
Message-ID: <7414ED04-6816-49B2-9353-3EEE7F6C6AC0@noao.edu>

Poul-Henning Kamp wrote:

>> civil timekeeping is equivalent (in the sense of a mathematical  
>> identity) to some stable approximation to mean solar time.
>
> I don't think anybody disputes that.

Ok.  Glad to hear it.

"Stable approximation" implies that a proposal to change UTC includes  
a plan for maintaining stability.  The ITU proposal does not (in  
addition to other shortcomings).

> The current argument seems to consist of you claiming that the  
> tolerance be on the order of one second, for reasons you have not  
> provided any hint off, but want to start a red-tape commision on.

I've searched my email for messages to leapsecs that contain the word  
"tolerance".  The most recent before your mentioning it now was on 11  
November - when it was also one of your messages.

You also are the only one to use the phrase "red-tape commission".   
Proper system engineering is the quickest way to solve a problem.  If  
anything describes "red-tape", it is the process being followed by the  
ITU.

Rob


From seaman at noao.edu  Tue Dec 23 11:04:21 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 23 Dec 2008 09:04:21 -0700
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: <4264.1230022100@critter.freebsd.dk>
References: <4264.1230022100@critter.freebsd.dk>
Message-ID: <66044CA9-B04E-40F3-8AD6-37F9D5248410@noao.edu>

Poul-Henning Kamp wrote:

> I have told you over and over, that if astronomers got their act  
> together, they would get this upgrade in the blink of an eye if  
> business which have real money riding on the leap-second could get  
> rid of them.

Make us an offer.  What have I ever said to suggest that I'm not open  
to a bribe ;-)

>> At the very least, grep the source for terms like "DUT1" to search  
>> for the Y2K-like issues.
>
> This, again, shows that you simply don't understand what our trouble  
> is.  We do not need to grep for DUT1, because it's not there, we  
> don't care about DUT1.

So no naive subcontractors put DUT1 in after reading the ITU UTC  
document?  And nowhere in any of these systems does UTC meet GMT  
derived from some legacy source?  It isn't whether you care about DUT1  
- it is whether you are dependent on it.  If the Y2K-like strings  
aren't there, it should be little trouble to grep for them.

You appear to believe that your argument is with me.  Rather, we're  
all arguing with the ITU.

> What we need to do, at every single leap-second, is to sit and
> monitor N computers, to see if they all agreed about the existence
> of the leap-second, if their operating systems all did the
> standards-mandated stupidity of replaying the 23:59:59 second in
> unison and if any applications croaked because of that.
>
> If the computers are hooked up to important or dangerous hardware,
> we have to stop that hardware before the leap-second, and start
> it again afterwards.


Yes, I understand this.  If you want this to influence decision- 
making, document it and attach it to a coherent systems engineering  
management plan.

However, if you really believe you are fixing your systems by seeking  
to limit the inputs to those systems, you are only setting yourself up  
for other classes of failures.  Are leap seconds the only glitch the  
systems might ever see?  Surely subsystems should validate their own  
inputs.

Rob

From zefram at fysh.org  Tue Dec 23 11:33:28 2008
From: zefram at fysh.org (Zefram)
Date: Tue, 23 Dec 2008 16:33:28 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <4950A632.19177.1AF7BB8E@dan.tobias.name>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
Message-ID: <20081223163328.GF14473@fysh.org>

Daniel R. Tobias wrote:
>And then your distant descendants will throw a huge fit about the 
>possibility of a leap hour being imposed, which would be much more 
>noticeably disruptive than leap seconds, and will indefinitely block 
>such a thing, until some day noon comes in the middle of the night.

I, for one, don't see a problem with the time of solar midnight being
labelled "12:00".  If office hours are consistently 21:00 to 05:00, and
particularly if they've been something like that for your whole life,
I think you'd cope.  But that's not what I want to talk about here.

Suppose that people in the future overwhelmingly want local civil time
of day to continue to approximate local solar time of day.  Suppose also
that since 2020 civil time has been based on TI, defined as TAI - 38 s,
instead of being based on UTC.  (Whether the UTC service continues to
exist is irrelevant here, as is the possibility of TI being misleadingly
named "UTC".)  What do people actually do?  Presumably they don't let
things get as far as solar midnight being at 12:00.

I think in this situation it is inevitable that the timezones will shift.
We already have political debates about changing timezone offsets to have
some target relationship to daylight hours.  This debate is partly about
twice-annual offset jumps, but also partly about permanent changes to the
base offset.  The very same process, if continued in this hypothetical
situation, will result in offsets gradually jumping downwards over a
period of millennia.  After two millennia we might expect Britain's
timezone to be about TI-3h, and the west coast of North America to be
about TI-11h.

There are then two ways that this can continue.  The first way is that
offsets just continue their gradual change, with no one doing anything
more radical.  I think this is a reasonable default prediction when
forecasting politics.  By the year 5000 no one uses a positive offset
from TI.  After five millenia Britain might be on TI-65h.  The local
date gets to be substantially different from the TI date, to the same
sort of degree that the local hour-of-day currently differs from the UTC
hour-of-day.  Timezone offsets continue to grow secularly without bound.
Sounds unworkable?  Possibly, but I can't put my finger on any reason
why large offsets per se would cause the system to collapse.

The other option is that people also find large offsets from TI
sufficiently odious to do something about.  What they do is to jump
across the International Date Line.  Countries already do this from time
to time.  The IDL has already, in little over a century, drifted a couple
of timezones eastwards from its nominal position.  Kiritimati is now on
UT+14h, whereas the most negative current offsets that I see in Olson
are UT-11h.  So in this hypothetical situation, when a country has got
as far as TI-13h or so it'll skip a calendar date and jump to TI+11h.
The IDL will secularly drift eastwards, repeatedly wrapping right around
the globe.  This scheme is exactly as workable as the IDL itself, which is
an inherent feature of the civil-solar correlation that we're presuming.

If you're worried about the violence being done to the calendar in
either of these situations, bear in mind that after a few millenia
the Gregorian calendar will desynchronise from the seasons anyway.
This problem exists regardless of what we do to time of day.

Either of my scenarios still suffers from the problem that the TI-UT
difference accelerates.  These timezone offset changes would be needed
at decreasing intervals.  By the time timezones are jumping by an hour
every year, one might expect to see political pressure for a new scheme.
But I don't think anything would put a stop to the process before then.

Secular growth of timezone offsets has previously been mentioned here,
as one of the unthinkable outcomes.  But I think it's a lot more feasible
than it's been given credit for.  I've shown two viable scenarios using
only TI and existing timezone mechanisms: there is no requirement for
new technical systems, nor for deliberate international cooperation,
nor even particularly explicit public awareness of the issues.  This is
a likely outcome of adopting TI without any further planning.

-zefram

From dot at dotat.at  Tue Dec 23 14:31:53 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 23 Dec 2008 19:31:53 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <20081223163328.GF14473@fysh.org>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
Message-ID: <alpine.LSU.2.00.0812231928200.9904@hermes-1.csi.cam.ac.uk>

On Tue, 23 Dec 2008, Zefram wrote:
>
> Either of my scenarios still suffers from the problem that the TI-UT
> difference accelerates.  These timezone offset changes would be needed
> at decreasing intervals.  By the time timezones are jumping by an hour
> every year, one might expect to see political pressure for a new scheme.
> But I don't think anything would put a stop to the process before then.

My tonge-in-cheek "sunrise time" idea copes quite well with the far
future. Because it becomes normal to change timezone most days, it becomes
easy to absorb rate differences between atomic time and solar time even if
they are as large as several seconds per day. The main problem would then
be running out of digits in the standard timezone offset field...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: SOUTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE
9 IN SOUTHEAST ICELAND. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

From phk at phk.freebsd.dk  Tue Dec 23 17:56:23 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 23 Dec 2008 22:56:23 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 23 Dec 2008 08:49:54 EST."
	<4950A632.19177.1AF7BB8E@dan.tobias.name> 
Message-ID: <7479.1230072983@critter.freebsd.dk>

In message <4950A632.19177.1AF7BB8E at dan.tobias.name>, "Daniel R. Tobias" writes
:
>On 23 Dec 2008 at 8:43, Poul-Henning Kamp wrote:
>
>> The rest of us have no trouble with a tolerance of up to (at least)
>> one hour, because that's what is already the reality for 99.9..%
>> of the population.
>
>And then your distant descendants will throw a huge fit about the 
>possibility of a leap hour being imposed, which would be much more 
>noticeably disruptive than leap seconds, and will indefinitely block 
>such a thing, until some day noon comes in the middle of the night.

They would probably be about as upset, as I am that somebody ceeded
Sk?ne to Sweden about as long time ago.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 23 18:05:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 23 Dec 2008 23:05:33 +0000
Subject: [LEAPSECS] Merry Christmas!
In-Reply-To: Your message of "Tue, 23 Dec 2008 09:04:21 MST."
	<66044CA9-B04E-40F3-8AD6-37F9D5248410@noao.edu> 
Message-ID: <7565.1230073533@critter.freebsd.dk>

In message <66044CA9-B04E-40F3-8AD6-37F9D5248410 at noao.edu>, Rob Seaman writes:

>> This, again, shows that you simply don't understand what our trouble  
>> is.  We do not need to grep for DUT1, because it's not there, we  
>> don't care about DUT1.
>
>So no naive subcontractors put DUT1 in after reading the ITU UTC  
>document?  And nowhere in any of these systems does UTC meet GMT  
>derived from some legacy source?  It isn't whether you care about DUT1  
>- it is whether you are dependent on it.  If the Y2K-like strings  
>aren't there, it should be little trouble to grep for them.

I can guarantee you that none of the code I am anywhere closet to
cares the least bit about, or even knows about, DUT1.

The left, center and right issue is if computers disagree what
UTC time it is because somebody didn't get the telegram.

>You appear to believe that your argument is with me.  Rather, we're  
>all arguing with the ITU.

You seem to be the only one here who has an argument with ITU,
I'm disappointed they didn't stick to their original plan.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From mgy1912 at cox.net  Tue Dec 23 23:08:06 2008
From: mgy1912 at cox.net (Brian Garrett)
Date: Tue, 23 Dec 2008 20:08:06 -0800
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
Message-ID: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>

As interesting as the continuing theoretical discussions are (or at least, what I as an interested bystander can comprehend of them), I think it might be informative to see examples of how the leap second to be thrust upon us next week is affecting list members' current projects.  Specific examples, rather than the generalities of the ongoing debate, might suggest specific solutions that a rubber-stamp solution from ITU would not necessarily be able to address.

Happy Holidays,
Brian Garrett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081223/b8bd7c25/attachment.htm>

From sla at ucolick.org  Wed Dec 24 00:58:56 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 23 Dec 2008 21:58:56 -0800
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
Message-ID: <20081224055856.GA29455@ucolick.org>

On Tue 2008-12-23T20:08:06 -0800, Brian Garrett hath writ:
> examples of how the leap second
> to be thrust upon us next week is affecting list members' current
> projects.

On-campus we have just suffered a backplane failure in the main disk
array server, followed by a complete shutdown of power to the building
last weekend, to be followed by a transfer from the grid to the local
generator next weekend.  We're nowhere near at the .99999999 level
of reliability that we need to notice a leap second, there are a lot
of bigger issues, and we expect everything to be robust.

On-mountain we do not yet have the fully-robotic telescope which will
be driven by Windows-based software for which we won't have the source
code to tell whether it cares about leap seconds, the older telescopes
point only a little better than battleships, and the leap happens
while the sun is still up.

At Keck the leap happens so nearly at midday that the telescope
drive systems are often offline.

The most evident place for logging the leap would be if a calibration
exposure were in progress.  The recorded elapsed time would not match
the recorded start and end times, but this is common.  None of the
instrument specifications demanded a means of precise shutter event
timing.  The only such event systems in place are the ones that I've
retrofitted into the software, and the constraints of the other system
components mean that they can't guarantee one second accuracy.

In short, we took no precautions at the end of 2005, and we will take
none this year.  I expect to be sitting with my girls listening to
WWV and WWVH.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From ghane0 at gmail.com  Wed Dec 24 01:09:04 2008
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 24 Dec 2008 14:09:04 +0800
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <20081224055856.GA29455@ucolick.org>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
	<20081224055856.GA29455@ucolick.org>
Message-ID: <158106a0812232209q74982f5ay2537a82a9d5fad83@mail.gmail.com>

Folks,

Any help on how to use a Linux PC driving a large monitor/LCD projector to
show a group of school children the leap second?  It will be in daylight
hours here (Singapore).



-- 
Sanjeev Gupta
+65 98551208


On Tue 2008-12-23T20:08:06 -0800, Brian Garrett hath writ:
> > examples of how the leap second
> > to be thrust upon us next week is affecting list members' current
> > projects.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081224/e506cc05/attachment.html>

From seaman at noao.edu  Wed Dec 24 02:05:15 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 24 Dec 2008 00:05:15 -0700
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <5227070D-BE17-4F44-9B61-ADBB1F8F984E@noao.edu>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
	<5227070D-BE17-4F44-9B61-ADBB1F8F984E@noao.edu>
Message-ID: <E5C46A09-0403-451B-B97C-C560ABBA1F60@noao.edu>

Brian Garrett wrote:

> As interesting as the continuing theoretical discussions are (or at  
> least, what I as an interested bystander can comprehend of them), I  
> think it might be informative to see examples of how the leap second  
> to be thrust upon us next week is affecting list members' current  
> projects.  Specific examples, rather than the generalities of the  
> ongoing debate, might suggest specific solutions that a rubber-stamp  
> solution from ITU would not necessarily be able to address.

Another interesting exercise would be to collect and compare reports  
from different time zones.  As Steve Allen reports for example,  
observatories west of the Mississippi encounter the leap second during  
daylight - downtime for optical and IR facilities.

Other industries and activities will see the opposite behavior, with  
the leap second hitting during an active period at a particular  
longitude.  Some industries are always active, but leap second  
behavior may vary with diurnal customer load, etc.

One might anticipate a latitude effect as well, although less  
pronounced.  It may not be a coincidence that some of the more ardent  
supporters of mean solar time live in sunnier climes, and that those  
most dismissive live at high latitudes where the sun may be only a  
hypothesis through long months of the year :-)

Also a seasonal effect.  By scheduling in June and December, leap  
seconds accentuate the distinction between northern and southern  
sensitivity to their effects since one hemisphere will be midwinter  
and one midsummer.

Again - the quickest way to effectuate change is to collect data to  
demonstrate what kind of change is needed.

Rob

From zefram at fysh.org  Wed Dec 24 06:02:11 2008
From: zefram at fysh.org (Zefram)
Date: Wed, 24 Dec 2008 11:02:11 +0000
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <158106a0812232209q74982f5ay2537a82a9d5fad83@mail.gmail.com>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
	<20081224055856.GA29455@ucolick.org>
	<158106a0812232209q74982f5ay2537a82a9d5fad83@mail.gmail.com>
Message-ID: <20081224110211.GG14473@fysh.org>

Sanjeev Gupta wrote:
>Any help on how to use a Linux PC driving a large monitor/LCD projector to
>show a group of school children the leap second?

Firstly, for the Linux clock to indicate the leap second at all, you
*must* be NTP-synchronised.  As long as you have a net connection, there
are plenty of public NTP servers to synch to.  Check that your clock is
actually synched.  The "rv" command in ntpq should show "leap_add_sec"
near the start of its output, indicating that it knows about the
upcoming leap.

The difficult bit is that hardly any Unix software is leap-second-aware.
Most clock programs will glitch.  I wrote one that will tick through
leaps correctly: <http://www.fysh.org/~zefram/time/purchron>.
I suggest running it with a display formula such as
'(ymdhms,local,9,3)/(ymdhms,local,3,-1)'.

purchron produces plain text output.  To display it full screen you'll
want to run it in an xterm (or similar) with a very big font.

-zefram

From novick at nist.gov  Wed Dec 24 13:05:22 2008
From: novick at nist.gov (Andrew Novick)
Date: Wed, 24 Dec 2008 11:05:22 -0700
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <20081224055856.GA29455@ucolick.org>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
	<20081224055856.GA29455@ucolick.org>
Message-ID: <6.1.2.0.2.20081224105424.02c106b0@email.nist.gov>

At 10:58 PM 12/23/2008, Steve Allen wrote:

>In short, we took no precautions at the end of 2005, and we will take
>none this year.  I expect to be sitting with my girls listening to
>WWV and WWVH.

For the leap second on WWV/WWVH you will "hear" two omitted ticks instead 
of one at the 59th/60th seconds.  Feel free to check out www.time.gov for 
the leap second also - it should show the 23:59:60.



From jhardis at tcs.wap.org  Wed Dec 24 14:55:15 2008
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Wed, 24 Dec 2008 14:55:15 -0500
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <6.1.2.0.2.20081224105424.02c106b0@email.nist.gov>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>
	<20081224055856.GA29455@ucolick.org>
	<6.1.2.0.2.20081224105424.02c106b0@email.nist.gov>
Message-ID: <p06230902c57843982409@[192.168.0.5]>

>For the leap second on WWV/WWVH you will "hear" two omitted ticks 
>instead of one at the 59th/60th seconds.  Feel free to check out 
>www.time.gov for the leap second also - it should show the 23:59:60.

...but only if you push the tiny "UTC" button.

If you do the obvious thing and click on the graphic to set your time 
zone, it will show xx:59:60 appropriate to the time zone, e.g., 
18:59:60 on the East Coast and 15:59:60 on the West Coast.

   - Jonathan

From dan at tobias.name  Wed Dec 24 14:56:06 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Wed, 24 Dec 2008 14:56:06 -0500
Subject: [LEAPSECS] 2008-12-31T23:59:60Z
In-Reply-To: <20081224055856.GA29455@ucolick.org>
References: <6D2F24AD48EC45CD872E9BA1303FEAFA@company48fcb68>,
	<20081224055856.GA29455@ucolick.org>
Message-ID: <49524D86.6473.216D74E0@dan.tobias.name>

On 23 Dec 2008 at 21:58, Steve Allen wrote:

> On Tue 2008-12-23T20:08:06 -0800, Brian Garrett hath writ:
> > examples of how the leap second
> > to be thrust upon us next week is affecting list members' current
> > projects.
> 
> On-campus we have just suffered a backplane failure in the main disk
> array server, followed by a complete shutdown of power to the building
> last weekend, to be followed by a transfer from the grid to the local
> generator next weekend.  We're nowhere near at the .99999999 level
> of reliability that we need to notice a leap second, there are a lot
> of bigger issues, and we expect everything to be robust.

Running a script querying the system time on various servers used 
where I work, all of which periodically sync their time to a remote 
time server, this is what I get:

Wed Dec 24 14:45:05 EST 2008
Wed Dec 24 14:45:05 EST 2008
Wed Dec 24 14:45:02 EST 2008
Wed Dec 24 14:45:04 EST 2008
Wed Dec 24 14:45:04 EST 2008
Wed Dec 24 14:45:06 EST 2008
Wed Dec 24 14:45:04 EST 2008
Wed Dec 24 14:45:04 EST 2008
Wed Dec 24 14:45:01 EST 2008
Wed Dec 24 14:45:01 EST 2008
Wed Dec 24 14:45:01 EST 2008
Wed Dec 24 14:45:03 EST 2008
Wed Dec 24 14:45:02 EST 2008
Wed Dec 24 14:45:02 EST 2008
Wed Dec 24 14:45:05 EST 2008 

Clearly, the leap second will be lost in the noise when a subsequent 
re-syncing takes it into account.

As for my personal life, the clocks scattered all over my house have 
a variety of times with multiple minutes of difference, despite my 
best efforts to get them all synced to the second twice a year when I 
go around springing forward or falling back.  A few of them actually 
do some kind of auto-sync from radio or Internet signals, so they'll 
take the leap second into account fairly soon afterward (if they 
manage to connect... sometimes they can go weeks without succeeding). 
 The rest will have to wait until I do my next manual resetting.

>From these examples, regarding time-based systems I'm involved with 
(and I seem to care more about attempting precise setting of 
timepieces than the great majority of other people I know who, even 
when they are in the process of manually setting a clock, only try to 
get it within a couple of minutes at best), leap seconds are likely 
to be a non-issue to at least 99% of the public.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From seaman at noao.edu  Fri Dec 26 12:27:39 2008
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 26 Dec 2008 10:27:39 -0700
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <20081223163328.GF14473@fysh.org>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
Message-ID: <4123552C-C098-489F-9920-0C5B549FC469@noao.edu>

On Dec 23, 2008, at 9:33 AM, Zefram wrote:

> Suppose that people in the future overwhelmingly want local civil  
> time of day to continue to approximate local solar time of day.

Again, the issue is mean solar time, not local solar time.  An  
underlying timescale based on mean solar time is what allows all the  
local civil/solar issues to be resolved cleanly together.

Just to be clear, it also isn't a question of people's "preferences",  
it is a question of discovering requirements implicit in our society.   
One may or may not agree with me that mean solar time is the key, but  
at no point over the millennia will the issue just be one of what  
people want (whether overwhelmingly or not).

> [...] I think in this situation it is inevitable that the timezones  
> will shift.
>
> [...] After five millenia Britain might be on TI-65h.  The local  
> date gets to be substantially different from the TI date, to the  
> same sort of degree that the local hour-of-day currently differs  
> from the UTC hour-of-day.  Timezone offsets continue to grow  
> secularly without bound.  Sounds unworkable?  Possibly, but I can't  
> put my finger on any reason why large offsets per se would cause the  
> system to collapse.

Because time is a quantity with memory.  Historians looking backward  
want to relate events worldwide and arrange them into coherent  
timelines.  Whatever the preferences of the ITU, they will discover  
that it is simply unacceptable to allow local dates to vary secularly  
from civil timekeeping dates.

We can speculate on all sorts of systems of timekeeping, up to and  
including Star Trek style stardates.  Many different systems can be  
described that are technically workable.  Only one - standard time  
based on mean solar time - has ever been shown to be *practically*  
workable.  Before adopting another - even by so apparently subtle a  
change as omitting that first leap second in 2019 - a carefully  
crafted analysis of the consequences and a coherent plan of action  
should be developed.

Red tape?  Bah Humbug!  It is simple common sense to plan ahead.  The  
issue isn't one of a second here and there - the issue is keeping the  
definition of the word "day" straight.

Rob


From seaman at noao.edu  Fri Dec 26 12:32:59 2008
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 26 Dec 2008 10:32:59 -0700
Subject: [LEAPSECS] sunrise time is the solution!
In-Reply-To: <alpine.LSU.2.00.0812231341150.9904@hermes-1.csi.cam.ac.uk>
References: <alpine.LSU.2.00.0812231341150.9904@hermes-1.csi.cam.ac.uk>
Message-ID: <7D31A04D-4B5A-4EA2-9FF7-2180FFCBEC98@noao.edu>

One might have pointed out that the quoted Risks article was from the  
April 1st issue :-)

Rob
---

On Dec 23, 2008, at 7:10 AM, Tony Finch wrote:

> It occurs to me that my proposal for a rational replacement for  
> daylight
> saving time also provides an answer to the leap second question.
>
> http://catless.ncl.ac.uk/Risks/25.10.html#subj1
>
> The essence of sunrise time is that we reset our clocks each day to a
> fixed time when the sun rises at a benchmark location. For the UK, the
> benchmark location would be where the Greenwich meridian crosses the
> Tropic of Cancer. The fixed time is 06:44, which is the time of the  
> latest
> sunrise at that location according to mean solar time (UT1). The  
> reset is
> accomplished by adjusting your timezone offset, which you'd do a few  
> hours
> earlier than sunrise to avoid disrupting early risers, and you'd  
> round the
> offset to the nearest minute to avoid breaking things like ISO 8601.
>
> If you are setting civil time according to these rules, then civil  
> time is
> by definition coupled to the rotation of the Earth, and there can be  
> no
> accelerating secular difference between the two. This is true whatever
> time scale you use as the basis from which timezone offsets are
> calculated. You have a pretty free choice of basis timescale long as
> its length of day is not too far from the Earth's LOD.
>
> The resulting system has several useful properties:
>
> * You can use atomic time as your basis timescale, with a LOD of 86400
> SI seconds.
>
> * The only other time(s) you need to worry about are local time(s),  
> just
> like the current situation.
>
> * Both basis time and local time have fixed-length minutes and hours,
> which is much simpler than the current situation.
>
> * Basis time has fixed-length days, which is also a simplification.
>
> * Local time has variable-length days, just like the current  
> situation.
>
> * Small timezone adjustments are less disruptive than large ones.
>
> * Frequent timezone adjustments make timezone-related bugs more  
> obvious
> and therefore easier to fix.
>
> * It preserves the role of Earth location scientists in time keeping.
>
> Tony.

From dot at dotat.at  Fri Dec 26 14:06:34 2008
From: dot at dotat.at (Tony Finch)
Date: Fri, 26 Dec 2008 19:06:34 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
Message-ID: <alpine.LSU.2.00.0812261900470.10579@hermes-1.csi.cam.ac.uk>

On Fri, 26 Dec 2008, Rob Seaman wrote:
>
> Whatever the preferences of the ITU, they will discover that it is
> simply unacceptable to allow local dates to vary secularly from civil
> timekeeping dates.

Civil time *is* a form of local time.

> Only one - standard time based on mean solar time - has ever been shown
> to be *practically* workable.

Two: standard time plus daylight saving time is the other (provided DST
is applied according to national rules).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SHANNON: SOUTHEASTERLY 4 OR 5, INCREASING 6 OR 7 IN SOUTH. MODERATE OR ROUGH.
MAINLY FAIR. MODERATE OR GOOD.

From seaman at noao.edu  Sat Dec 27 03:04:41 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 27 Dec 2008 01:04:41 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
	<alpine.LSU.2.00.0812261900470.10579@hermes-1.csi.cam.ac.uk>
	<C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
Message-ID: <5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>

I wrote:

>> Whatever the preferences of the ITU, they will discover that it is  
>> simply unacceptable to allow local dates to vary secularly from  
>> civil timekeeping dates.

Tony Finch replies:

> Civil time *is* a form of local time.

The question isn't about haggling over terminology.  We've had that  
discussion before.

Rather, a clock can be deposited at any meridian on any planet, set to  
any time, running at any rate.  The question is whether a particular  
choice of parameters is useful and sustainable.  Additionally if a  
planet has populations scattered at wide longitudes, the more basic  
requirement is to organize a coherent system to manage the whole.

Identifying the length of the civil day with the length of the mean  
solar day is the key to providing that coherence.  (True now on Mars  
as well as Earth.)  The mean solar day is just the sidereal day plus  
the synodic correction for lapping the sun once a year.  The mean  
solar day is a global phenomenon.  The eccentricity of the Earth's  
orbit and the tilt of its axis (etc) add periodic terms that average  
out.  Latitude and politics overlay local variations that are a  
distraction from the central issue.  Tidal slowing, on the other hand,  
represents a global long term secular trend.  A trend with global  
implications demands a global solution.

The trend just happens to be slow enough to permit cheating.   
Consensus based planning is necessary *especially* if we decide to  
cheat.  Cheating is ultimately fruitless over the long term, no matter  
what.

The ITU has a responsibility to consider options with a long term  
future.  A permanent embargo on leap seconds does not have one.   
Whatever action the ITU takes, it should be fully and carefully  
planned and not obligate our descendants to clean up an embarrassing  
mess.

>> Only one - standard time based on mean solar time - has ever been  
>> shown to be *practically* workable.
>
> Two: standard time plus daylight saving time is the other

DST is a trivial gimmick layered on standard time.  Standard time is a  
global system layered on the mean solar day.

Ideally we will come out of this exercise with an improvement to  
standard timekeeping.  Wouldn't it be more fun to pursue that project  
rather than playing an endless game of whack-a-mole with ITU politics?

Rob


From zefram at fysh.org  Sat Dec 27 08:43:33 2008
From: zefram at fysh.org (Zefram)
Date: Sat, 27 Dec 2008 13:43:33 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
Message-ID: <20081227134333.GM2263@fysh.org>

Rob Seaman wrote:
>Again, the issue is mean solar time, not local solar time.

This sentence doesn't make sense to me.  You seem to have a different
definition of either "mean" or "local" from me.  To be clear: the
(periodic) difference between apparent and mean solar time does not
affect my argument, so I ignored it; likewise, the difference between
solar time at one's actual longitude (local solar time) and solar time
at a nearby round-numbered longitude (standard time) is small and does
not affect the psychology.

>it is a question of discovering requirements implicit in our society.   

Good point.

>                                         Historians looking backward  
>want to relate events worldwide and arrange them into coherent  
>timelines.

Yes, they'll want the Olson database.

>            Whatever the preferences of the ITU, they will discover  
>that it is simply unacceptable to allow local dates to vary secularly  
>from civil timekeeping dates.

I don't see how this follows.  Given the Olson database they'll be able
to apply the offsets correctly.

If the date drift per se really is a problem, that would be a reason
to argue for the IDL-jumping version of my scenario, rather than the
unbounded-timezone-offset version.

-zefram

From lang at unb.ca  Sat Dec 27 09:07:42 2008
From: lang at unb.ca (Richard B. Langley)
Date: Sat, 27 Dec 2008 10:07:42 -0400
Subject: [LEAPSECS] Fwd: Re: Leap second is back
Message-ID: <1230386862.495636ae4d956@webmail.unb.ca>

List members might be interested in the message below posted to the Sundial List--yes,
some of us are interested in these devices that provide "true" time ;-). Not that this
posting will likely sway current diverse and seemingly entrenched opinions of some
members (one way or the other). By the way, I must confess, that reading some of the
postings reminds me of the Dilbert cartoon strip at times. ;-) Anyway, happy holidays
to all.
-- Richard Langley 
Links to The Times items:
<http://www.timesonline.co.uk/tol/comment/leading_article/article5361349.ece>
<http://www.timesonline.co.uk/tol/comment/letters/article5385619.ece>
<http://www.timesonline.co.uk/tol/news/uk/science/article5361670.ece>
<http://www.timesonline.co.uk/tol/comment/letters/article5372021.ece>
<http://www.timesonline.co.uk/tol/news/uk/science/article5361935.ece>


----- Forwarded message from Frank King <Frank.King at cl.cam.ac.uk> -----
    Date: Sat, 27 Dec 2008 09:15:30 +0000
    From: Frank King <Frank.King at cl.cam.ac.uk>
Reply-To: Frank King <Frank.King at cl.cam.ac.uk>
 Subject: Re: Leap second is back
      To: Sundial List <sundial at uni-koeln.de>

Dear All,

On 9 December, Fred Sawyer reminded us that there
will be a leap second at the end of this month.  He
suggested that the proposal to eliminate Leap Seconds
has not been adopted.

It is true that this proposal has not yet been adopted
but the proposal has certainly not been abandoned.

There was a worrying report in the London Times newspaper
of 18 December noting that the ITU is still keen to get rid
of Leap Seconds.  The Times also printed a defence of the
Leap Second by David Rooney (Curator of timekeeping at the
Royal Greenwich Observatory) and a further defence by my
colleague Markus Kuhn (whose office is next to mine!).

I mentioned the report to my friend John Chambers who was
Head of the UK Time Service from 1993 to 1996 and prompted
him to write a letter to the Times giving his views.

His letter, as published, can be found at:

 http://www.timesonline.co.uk/tol/comment/letters/article5385619.ece

His letter, as sent (before the Letters Editor got hold of
it!), can be found below my signature.

Very diplomatically, he notes that it really is no business
of the ITU to mess about with Civil Time.

Unfortunately, the published version leaves out John's note
about sundials.  [Do Times readers have no interest in these
instruments?]

Equally unfortunately, the published version leaves out the
important comment that those who want an unchanging timescale
can use GPS time.  Moreover, GPS time is provided free!

Best wishes

Frank King
Cambridge, UK

==== Original Letter about Leap Seconds as sent to the Times ====

 Letters to the Editor, The Times -

 [This letter is sent exclusively to The Times]

 Sir,

 Any intention to interfere with the current worldwide arrangements for
 civil time by minutes, or even hours (third leader and report (page 8)
 December 18, letters December 19, 20) are surely beyond the competence
 of the International Telecommunications Union (ITU). The ITU's scope
 extends only to time signals as broadcast. Reform of civil time is as
 important as calendar reform, where the ramifications of the Vatican
 initiative in 1582 took hundreds of years to settle. 

 Coordinated Universal Time (UTC) is a compromise which has served us well
 since 1972 as the basis for time zones. It provides a timescale within one
 second of mean solar time for everyday use. It has seconds markers
 coincident with the more regular atomic timescale used, for example, in
 GPS and deep-space navigation. The two are simply related: GPS time is
 14s ahead of UTC until after the leap second at the end of this month,
 then it will be 15s ahead.

 Sundials are used worldwide to tell the time, requiring neither fuel nor
 moving parts. Some can be read to an accuracy of better than a minute.
 Traditional navigation, based on observation of sun and stars, loses less
 than 400 metres in accuracy when UTC is used. However much train time-
 keeping improves we can live within these limits in everyday life.

 Those who need to live a precise life, or whose systems depend on there
 being 60 seconds in every minute, can already use GPS time. There is no
 need for another time scale. 

 (Mr) John Chambers

 (Head of UK Time Service 1993-96)

 Koskenp??ntie 79, 42300 J?ms?nkoski, Finland



---------------------------------------------------
https://lists.uni-koeln.de/mailman/listinfo/sundial


----- End forwarded message -----


===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From seaman at noao.edu  Sat Dec 27 19:44:22 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 27 Dec 2008 17:44:22 -0700
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <2D2F05E1-4517-4FD2-8B07-060D471FFC16@noao.edu>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
	<20081227134333.GM2263@fysh.org>
	<8BEFED01-729E-4FFF-B67B-8DBAB60B50D4@noao.edu>
	<2D2F05E1-4517-4FD2-8B07-060D471FFC16@noao.edu>
Message-ID: <C44170AB-9789-4E18-BDCC-E7D7DC6872E1@noao.edu>

I wrote:

>> Historians looking backward want to relate events worldwide and  
>> arrange them into coherent timelines.

Zefram replied:

> Yes, they'll want the Olson database.

Precisely.  For a scheme such as this to have any chance of working, a  
requirement is that it be tightly coupled to a mechanism like  
zoneinfo.  This is equivalent to Steve Allen's proposal.

>> Whatever the preferences of the ITU, they will discover that it is  
>> simply unacceptable to allow local dates to vary secularly from  
>> civil timekeeping dates.
>
> I don't see how this follows.  Given the Olson database they'll be  
> able to apply the offsets correctly.

A further requirement is that there needs to be faith in that database  
and in how it is tied into the fabric (system of systems) of the world.

> If the date drift per se really is a problem, that would be a reason  
> to argue for the IDL-jumping version of my scenario, rather than the  
> unbounded-timezone-offset version.

Words like "jumping" and "unbounded" reflect that the discontinuities  
represented by leap seconds remain inherent in the system.  One way or  
another, intercalary corrections (of whatever sort) will remain  
necessary.  Since they are necessary, so is a coherent and reliable  
mechanism for managing them.  The devil-may-care ITU proposal is  
insufficient.

Rob





From dot at dotat.at  Sat Dec 27 20:29:11 2008
From: dot at dotat.at (Tony Finch)
Date: Sun, 28 Dec 2008 01:29:11 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
References: <26BB77EC-8284-4AA8-B9D5-0393DC1E69FE@noao.edu>
	<4217.1230021820@critter.freebsd.dk>
	<4950A632.19177.1AF7BB8E@dan.tobias.name>
	<20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
	<alpine.LSU.2.00.0812261900470.10579@hermes-1.csi.cam.ac.uk>
	<C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
Message-ID: <alpine.LSU.2.00.0812272320490.23685@hermes-1.csi.cam.ac.uk>

On Sat, 27 Dec 2008, Rob Seaman wrote:
>
> Rather, a clock can be deposited at any meridian on any planet, set to any
> time, running at any rate.  The question is whether a particular choice of
> parameters is useful and sustainable.

Really what it boils down to is a question of how frequently and by how
much we reset our clocks so that civil time (the time used for every-day
purposes) has a useful relation to Earth orientation.

> Additionally if a planet has populations scattered at wide longitudes,
> the more basic requirement is to organize a coherent system to manage
> the whole.

That's just a matter of quantizing timezone offsets with a reasonably
large granularity, as was established in the 19th century.

> > > Only one - standard time based on mean solar time - has ever been shown to
> > > be *practically* workable.
> >
> > Two: standard time plus daylight saving time is the other
>
> DST is a trivial gimmick layered on standard time.  Standard time is a
> global system layered on the mean solar day.

I don't think DST is trivial, nor is it a gimmick.

It's very tempting to dismiss DST as a stupidity, especially if you try to
understand it without regard to the sociology of time. (I used to think so
myself.) There is a very good reason for DST and it is entirely to do with
the way people collectively relate to clocks. The most obvious artefacts
of this relationship are timetables. Ben Franklin's article was satire,
but like all good satire it was pointing out an important failure of civic
life: that we are too strictly governed by clocks, regardless of how well
we use natural daylight.

Back when Franklin was writing, relatively few people lived in cities, and
timetables were rare - even ideas like opening hours or working hours. But
urban living naturally generates timetables: the timing of deliveries of
goods from the counryside determines the opening times of the markets,
which determines shopping hours, etc. There is an inevitable coupling of
the timing of activities between different walks of life. This became
painfully obvious in the USA when (over a period of decades) various
jurisdictions disagreed about when and where DST should be applied. The
worst chaos occurred when physically overlapping jurisdictions used
different rules, so different offices in the same city (e.g. government
vs. private) would be operating on different time. The chaos only subsided
when the US federal government set rules for how DST should be applied,
thereby establishing a consensus.

What DST teaches us is that the the most important property that civil
time must have is consensus over large areas, whether or not this makes
sense w.r.t. natural philosophy. DST is a violation of the concept of
standard time, but it is more useful to society than strict adherence to a
fixed offset from mean solar time. In fact the same lesson is taught by
the establishment of GMT as legal time across Britain. Legal precedent
said GMT is a violation of local time - despite the fact that nobody in
practice behaved as the law said they should, between the establishment of
railway time and the endorsement of GMT as legal time.

So how is this relevant to leap seconds?

Firstly: The history shows that almost any violence can be done to civil
time so long as everyone agrees to it. DST shows that sociology can trump
astronomy. (Standard time shows the same thing, but DST's arbitrariness
makes this fact much more starkly clear.) Broad agreement and consensus is
the foundation of civil time. The way that leap seconds work clearly does
not have enough consensus, in that people still produce software and
standards and specifications that are incompatible with leap seconds. That
fact is probably enough to doom them, just like Britain's local time law
was doomed to lose to GMT in the 19th century.

Secondly: The commonality between DST and UTC is that both of them require
us to reset our clocks occasionally to keep them in a convenient relation
to the position of the Earth. DST's resets exist because the way we
coordinate our activities using timetables (aligned to mean solar time)
doesn't work well with the hours of daylight. UTC's resets exist to keep
our clocks matched to mean solar time.

Can we not accomplish both goals with the same occasional resets, instead
of having two independent reset schedules? Would this also solve the
problem of leap seconds disagreeing with the practical consensus model of
time?

Is there any other way of cleaning up this mess?

My "sunrise time" suggestion is not entirely a joke. Originally its
serious purpose was to point out that there is a rational basis for DST:
our timetables work better if they are anchored to sunrise than to midday.
The point of my recent post is that if you are resetting clocks frequently
to make gross adjustments, then you do not also need a second reset
schedule to make fine adjustments.

Sunrise time has layers of satire and absurdity, as well as of astronomy
and sociology, but to explain them all would spoil the fun and keep me up
too late.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
IRISH SEA: EAST 4 OR 5, INCREASING 6 AT TIMES. SLIGHT, OCCASIONALLY MODERATE.
FAIR. GOOD.

From imp at bsdimp.com  Sat Dec 27 21:24:06 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 27 Dec 2008 19:24:06 -0700 (MST)
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <20081227134333.GM2263@fysh.org>
References: <20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
	<20081227134333.GM2263@fysh.org>
Message-ID: <20081227.192406.1683994734.imp@bsdimp.com>

In message: <20081227134333.GM2263 at fysh.org>
            Zefram <zefram at fysh.org> writes:
: >                                         Historians looking backward  
: >want to relate events worldwide and arrange them into coherent  
: >timelines.
: 
: Yes, they'll want the Olson database.

How is the Olson database fundamentally different than the historical
data that a future historian would have based on the measurements of
the delta between what we call today TAI and UT1 times?  It is just
more data for them to swizzle into their calculations?

Warner

From imp at bsdimp.com  Sat Dec 27 21:22:00 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 27 Dec 2008 19:22:00 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
References: <C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
Message-ID: <20081227.192200.-1749704408.imp@bsdimp.com>

In message: <5DE48B7A-0D30-4580-B110-7687A75A2904 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Identifying the length of the civil day with the length of the mean  
: solar day is the key to providing that coherence.  (True now on Mars  
: as well as Earth.)  The mean solar day is just the sidereal day plus  
: the synodic correction for lapping the sun once a year.  The mean  
: solar day is a global phenomenon.  The eccentricity of the Earth's  
: orbit and the tilt of its axis (etc) add periodic terms that average  
: out.  Latitude and politics overlay local variations that are a  
: distraction from the central issue.  Tidal slowing, on the other hand,  
: represents a global long term secular trend.  A trend with global  
: implications demands a global solution.

Correct.  However, the die was cast on this in 1958 when the second
was defined in terms of atomic behavior.  At that point, the game was
up, since the basic unit of time was decoupled from the day.  We
transitioned from having rubber seconds, to having rubber days.  I
suppose we could push this back further when the second was defined in
terms of the mean solar day in 1900, since that changed a division of
a day, to the day being so many seconds.  A subtle difference that
appears to have been lost on the people taking this first step, at
least at the time.

: The trend just happens to be slow enough to permit cheating.   
: Consensus based planning is necessary *especially* if we decide to  
: cheat.  Cheating is ultimately fruitless over the long term, no matter  
: what.

Yes.  First, people cheated with rubber seconds (and why not, since
that's how people cheated before the fixing of the length of the
second based on atomic behavior: seconds were always rubber since they
were defined in terms of a day that varied in length).  Doing this
similar cheating with atomic clocks presented many operational
problems...

Second, people cheated with leap seconds.  This cheat has presented
many operational problems.

: The ITU has a responsibility to consider options with a long term  
: future.  A permanent embargo on leap seconds does not have one.   
: Whatever action the ITU takes, it should be fully and carefully  
: planned and not obligate our descendants to clean up an embarrassing  
: mess.

This is both true and false.  Assuming, for the sake of argument, that
we take the position that the ITU has to have a permanent solution to
the clock skew problem, that cannot involve leap seconds.  In time,
they will be needed more than twice a year, then more than 12x a year,
and finally, more than once a day.  UTC, as defined today, dies once
the length of day is 86401 seconds[*].  With these long-term problems on
the horizon, I agree that some solution is needed.

A leap second embargo is one radical idea "don't sync the clocks:
publish the delta."  The psychological aspects of this are nice, since
time won't drift more than a few minutes in anybody's lifetime for
several dozen generations yet.  This is as long term as other
'permanent' solutions the ITU has promulgated.  So I'm not sure I
understand this criticism.

: >> Only one - standard time based on mean solar time - has ever been  
: >> shown to be *practically* workable.
: >
: > Two: standard time plus daylight saving time is the other
: 
: DST is a trivial gimmick layered on standard time.  Standard time is a  
: global system layered on the mean solar day.

But UTC isn't layered on top of the mean solar day.  It is merely
synchronized to the mean solar day.  It is based on the atomic
second.  And many legal times are being transitioned to UTC.

There is a subtle difference between your statement and mine, but an
important one.

: Ideally we will come out of this exercise with an improvement to  
: standard timekeeping.  Wouldn't it be more fun to pursue that project  
: rather than playing an endless game of whack-a-mole with ITU politics?

Warner

[*] Well, it would fail when the day was ~86400.033s since that's when
we'd cross the once a month threshold for when the leap seconds can
happen.  When it crosses 86401, though, we're no longer able to use
the same notation we're using today with 23:59:60 although I suppose
it could be extended to any hour, then any minute, etc.  At some point
it becomes totally unworkable, and I arbitrarily selected "once a day"
although my hunch is that it is somewhat before then.

From sla at ucolick.org  Sat Dec 27 21:40:22 2008
From: sla at ucolick.org (Steve Allen)
Date: Sat, 27 Dec 2008 18:40:22 -0800
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <20081227.192200.-1749704408.imp@bsdimp.com>
References: <C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
	<20081227.192200.-1749704408.imp@bsdimp.com>
Message-ID: <20081228024022.GB17710@ucolick.org>

On Sat 2008-12-27T19:22:00 -0700, M. Warner Losh hath writ:
> Correct.  However, the die was cast on this in 1958 when the second
> was defined in terms of atomic behavior.  At that point, the game was
> up, since the basic unit of time was decoupled from the day.  We
> transitioned from having rubber seconds, to having rubber days.  I
> suppose we could push this back further when the second was defined in
> terms of the mean solar day in 1900, since that changed a division of
> a day, to the day being so many seconds.  A subtle difference that
> appears to have been lost on the people taking this first step, at
> least at the time.

The cesium chronometer was created in the UK 1955, and within only a
few months Markowitz of the USNO was rushing to start comparing it
with the lunar observations of the dual rate moon camera, and the
results of that intercomparison were reported before the experiment
was really over.

Markowitz in his role as chair of IAU 31 was in a tremendous race to
see that the cesium would be calibrated with ephemeris time.  There
was barely enough time to reduce the observations they had made let
alone to comprehend their meaning for either the short term or long
term.  During that experiment they noted that the rate of earth
rotation was in a particularly fast phase of variation.

I believe there is a memoir by Markowitz where he indicated the
pressure he felt he was under to get an astronomically based
definition before the physicists simply chose a number.  I haven't yet
seen it, and I can't cite it off the top of my head.

I have seen no references which indicate that anyone had then
recognized that ephemeris time was roughly in agreement with
the mean solar day of 1820.  There are a number of places where
astronomers incorrectly stated that ephemeris time matched the
mean solar day of 1900.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Sun Dec 28 01:55:30 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 27 Dec 2008 23:55:30 -0700
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <20081227.192406.1683994734.imp@bsdimp.com>
References: <20081223163328.GF14473@fysh.org>
	<4123552C-C098-489F-9920-0C5B549FC469@noao.edu>
	<20081227134333.GM2263@fysh.org>
	<20081227.192406.1683994734.imp@bsdimp.com>
Message-ID: <C43E1C7D-F4ED-43BC-8B3E-3F7E62950B9D@noao.edu>

M. Warner Losh wrote:

> How is the Olson database fundamentally different than the  
> historical data that a future historian would have based on the  
> measurements of the delta between what we call today TAI and UT1  
> times?  It is just more data for them to swizzle into their  
> calculations?

Because a mean solar clock is automatically a stable subdivision of  
the calendar - stable over long periods of time as well as  
geographically.  Noon on two different days is separated by an  
integral number of days no matter what period of time separates the  
two dates and how the length of day may have varied in the interim.

There is no swizzling needed if civil timekeeping remains tied to the  
Sun.

Rob


From phk at phk.freebsd.dk  Sun Dec 28 03:04:55 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 08:04:55 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 01:29:11 GMT."
	<alpine.LSU.2.00.0812272320490.23685@hermes-1.csi.cam.ac.uk> 
Message-ID: <32626.1230451495@critter.freebsd.dk>

In message <alpine.LSU.2.00.0812272320490.23685 at hermes-1.csi.cam.ac.uk>, Tony F
inch writes:

>> DST is a trivial gimmick layered on standard time.  Standard time is a
>> global system layered on the mean solar day.
>
>I don't think DST is trivial, nor is it a gimmick.

Seconded.

In addition to what it was designed to, DST changes have taken on
an unanticipated role of high-level low frequency public scheduling.

Emperical evidence shows that fewer people miss their trains right
after a DST change, even accounting for those who get it wrong by
one hour.


This indicates that DST changes actually make people adjust their
clocks.

At least in Denmark, the public safety administration is actively
advocating using the DST change to test the residual current
protection relay (RCCB), "since you have to set all the clocks anyway".

We know from electricians purchases of new RCCBs that this advice
is widely taken.

I would keep DST, even if it confers no other benefits, simply because
from a societal point of view, it is beneficial to have the populations
almost undivided attention twice a year.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Sun Dec 28 03:06:12 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 08:06:12 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: Your message of "Sat, 27 Dec 2008 19:24:06 MST."
	<20081227.192406.1683994734.imp@bsdimp.com> 
Message-ID: <32641.1230451572@critter.freebsd.dk>

In message <20081227.192406.1683994734.imp at bsdimp.com>, "M. Warner Losh" writes
:
>In message: <20081227134333.GM2263 at fysh.org>
>            Zefram <zefram at fysh.org> writes:
>: >                                         Historians looking backward  
>: >want to relate events worldwide and arrange them into coherent  
>: >timelines.
>: 
>: Yes, they'll want the Olson database.
>
>How is the Olson database fundamentally different than the historical
>data that a future historian would have based on the measurements of
>the delta between what we call today TAI and UT1 times?  It is just
>more data for them to swizzle into their calculations?

In addition to the Olsen database, the book "Calendrical Calculations"
is probably required.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Sun Dec 28 03:13:04 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 08:13:04 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sat, 27 Dec 2008 19:22:00 MST."
	<20081227.192200.-1749704408.imp@bsdimp.com> 
Message-ID: <32684.1230451984@critter.freebsd.dk>

In message <20081227.192200.-1749704408.imp at bsdimp.com>, "M. Warner Losh" write
s:

>: The ITU has a responsibility to consider options with a long term  
>: future.

ITU has no such responsibility:

  	1 The purposes of the Union are:

		a) to maintain and extend international cooperation
		among all its Member States for the improvement and
		rational use of telecommunications of all kinds;

		[...]

(http://www.itu.int/net/about/basic-texts/constitution/chapteri.aspx)

If leap-seconds impeede telecommunications, ITU has a responsibility
to get rid of them.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From jhardis at tcs.wap.org  Sun Dec 28 09:00:31 2008
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Sun, 28 Dec 2008 09:00:31 -0500
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <20081227.192200.-1749704408.imp@bsdimp.com>
References: <C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
	<20081227.192200.-1749704408.imp@bsdimp.com>
Message-ID: <p06230903c57d33a35913@[192.168.0.5]>

>Correct.  However, the die was cast on this in 1958 when the second 
>was defined in terms of atomic behavior.

It was 1967.

>At that point, the game was up, since the basic unit of time was 
>decoupled from the day.  We transitioned from having rubber seconds, 
>to having rubber days.  I suppose we could push this back further 
>when the second was defined in terms of the mean solar day in 1900

...which happened in 1956 (ratified in 1960).


References:

    http://physics.nist.gov/cuu/Units/second.html
    http://tycho.usno.navy.mil/leapsec.html

   - Jonathan

From seaman at noao.edu  Sun Dec 28 09:45:27 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 07:45:27 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <32684.1230451984@critter.freebsd.dk>
References: <32684.1230451984@critter.freebsd.dk>
Message-ID: <0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>

I wrote:

>> The ITU has a responsibility to consider options with a long term  
>> future.

Poul-Henning Kamp writes:

> ITU has no such responsibility:
>
>  	1 The purposes of the Union are:
>
> 		a) to maintain and extend international cooperation
> 		among all its Member States for the improvement and
> 		rational use of telecommunications of all kinds;
>
> 		[...]
>
> (http://www.itu.int/net/about/basic-texts/constitution/chapteri.aspx)
>
> If leap-seconds impeede telecommunications, ITU has a responsibility
> to get rid of them.


1) An organization with a limited scope (telecommunications) should  
not control a standard with a much broader scope (timekeeping).

2) All organizations have an implicit responsibility not to pursue  
shortsighted agendas.  If an option has no long term future, the ITU  
certainly has no business considering it.

Rob


From seaman at noao.edu  Sun Dec 28 09:57:19 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 07:57:19 -0700
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <32641.1230451572@critter.freebsd.dk>
References: <32641.1230451572@critter.freebsd.dk>
Message-ID: <E0B169D4-ACC0-4479-90CD-7097EDB48D0B@noao.edu>

Poul-Henning Kamp wrote:

> In addition to the Olsen database, the book "Calendrical  
> Calculations" is probably required.

Good point.

To count days and align international timelines using the current  
civil timescale, civilians (e.g., historians) need none of this.

Under the ITU's plan to degrade UTC, civilians will need to hire  
experts like us to perform this simple task.

Rob


From phk at phk.freebsd.dk  Sun Dec 28 09:57:41 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 14:57:41 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 07:45:27 MST."
	<0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu> 
Message-ID: <34738.1230476261@critter.freebsd.dk>

In message <0B4062CC-0E7E-407F-A856-37F9C74DC081 at noao.edu>, Rob Seaman writes:
>I wrote:
>
>>> The ITU has a responsibility to consider options with a long term  
>>> future.
>
>Poul-Henning Kamp writes:
>
>> ITU has no such responsibility:

>1) An organization with a limited scope (telecommunications) should  
>not control a standard with a much broader scope (timekeeping).

People should not kill, machines should not fail, intelligent
discourse should not use should in passive form.

50 years ago, I might have agreed with you (NB: cheap claim, I'm not
that old).

But in the networked global village of this age, I do not: timekeeping
is very much a telecoms issue.

In fact, that is why we even debate leap seconds now:  They are a
bump in the digital road.

Poul-Henning



-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sun Dec 28 11:30:41 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 09:30:41 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <34738.1230476261@critter.freebsd.dk>
References: <34738.1230476261@critter.freebsd.dk>
Message-ID: <BF590D36-97C8-49FE-A6E3-1E4634C5B472@noao.edu>

I wrote:

> An organization with a limited scope (telecommunications) should not  
> control a standard with a much broader scope (timekeeping).

Poul-Henning Kamp writes:

> 50 years ago, I might have agreed with you (NB: cheap claim, I'm not  
> that old).
>
> But in the networked global village of this age, I do not:  
> timekeeping is very much a telecoms issue.

A global village implies global citizens.  People have complex needs  
that place more stringent timekeeping requirements of all sorts now  
than 50 years ago.  Telecommunication issues are only part of that -  
an important part, but limited in scope.  Timekeeping requirements  
will only broaden moving forward into the future.

The issue is general purpose civil timekeeping, not some wonky issue  
about a technical timescale.  The diverse requirements of civilians  
are preeminent.  In any event, the specific needs of  
telecommunications infrastructure are not necessarily at odds with the  
more general needs of civilians.  Systems engineering provides tools  
for accommodating both.

The ITU proposal is simply a bad proposal.  Improve the proposal.   
Seek consensus before voting on the next one.

Rob


From phk at phk.freebsd.dk  Sun Dec 28 11:33:01 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 16:33:01 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 09:30:41 MST."
	<BF590D36-97C8-49FE-A6E3-1E4634C5B472@noao.edu> 
Message-ID: <35176.1230481981@critter.freebsd.dk>

In message <BF590D36-97C8-49FE-A6E3-1E4634C5B472 at noao.edu>, Rob Seaman writes:

>A global village implies global citizens.  People have complex needs  
>that place more stringent timekeeping requirements of all sorts now  
>than 50 years ago.

Rob, you keep making these claims that a lot of 'needs' and 'requirements'
are being overlooked.

Why is it that you never offer a single concrete example ?

>The ITU proposal is simply a bad proposal.  Improve the proposal.   
>Seek consensus before voting on the next one.

I think it is a pretty good proposal and I hope nobody get killed
by leap seconds before it takes effect.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From imp at bsdimp.com  Sun Dec 28 11:42:06 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 09:42:06 -0700 (MST)
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <C43E1C7D-F4ED-43BC-8B3E-3F7E62950B9D@noao.edu>
References: <20081227134333.GM2263@fysh.org>
	<20081227.192406.1683994734.imp@bsdimp.com>
	<C43E1C7D-F4ED-43BC-8B3E-3F7E62950B9D@noao.edu>
Message-ID: <20081228.094206.-1648695711.imp@bsdimp.com>

In message: <C43E1C7D-F4ED-43BC-8B3E-3F7E62950B9D at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > How is the Olson database fundamentally different than the  
: > historical data that a future historian would have based on the  
: > measurements of the delta between what we call today TAI and UT1  
: > times?  It is just more data for them to swizzle into their  
: > calculations?
: 
: Because a mean solar clock is automatically a stable subdivision of  
: the calendar - stable over long periods of time as well as  
: geographically.  Noon on two different days is separated by an  
: integral number of days no matter what period of time separates the  
: two dates and how the length of day may have varied in the interim.
:
: There is no swizzling needed if civil timekeeping remains tied to the  
: Sun.

Actually, they do need to do this now for leap seconds.  Plus they
need it for sub-second accuracy.

Also, mean solar time doesn't mean that all days are 1.0000000000000d
long.  In actuality, there's day to day variations in the length of
the day.  Since civil time is tied to the atomic scales, this means
that noon(local time) is almost never going to be an integral number
of days apart due to this variation.  It will only be an average.

So this argument is flawed from that perspective.

So if we keep UTC as is, all we're doing is keeping this variation
below a second.  Do historians really care if this variation is below
a second, below a minute or below an hour?  No evidence has been
presented as to what level historians care about, the number that
care, and why an extra little swizzle at the end would be a burdon.

Finally, civil time today is atomic based.  It is based on the second
as defined by the oscillations of the atoms, not as defined by the
rotation of the earth.  UTC today includes leap seconds to
periodically resynchronize the time scale to the earth's rotation, but
it is not based on the earth's rotation.  We all know a time will come
that this won't be possible.

Warner

From imp at bsdimp.com  Sun Dec 28 11:43:47 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 09:43:47 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <32626.1230451495@critter.freebsd.dk>
References: <alpine.LSU.2.00.0812272320490.23685@hermes-1.csi.cam.ac.uk>
	<32626.1230451495@critter.freebsd.dk>
Message-ID: <20081228.094347.-1572286992.imp@bsdimp.com>

In message: <32626.1230451495 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <alpine.LSU.2.00.0812272320490.23685 at hermes-1.csi.cam.ac.uk>, Tony F
: inch writes:
: 
: >> DST is a trivial gimmick layered on standard time.  Standard time is a
: >> global system layered on the mean solar day.
: >
: >I don't think DST is trivial, nor is it a gimmick.
: 
: Seconded.
: 
: In addition to what it was designed to, DST changes have taken on
: an unanticipated role of high-level low frequency public scheduling.
: 
: Emperical evidence shows that fewer people miss their trains right
: after a DST change, even accounting for those who get it wrong by
: one hour.
: 
: 
: This indicates that DST changes actually make people adjust their
: clocks.
: 
: At least in Denmark, the public safety administration is actively
: advocating using the DST change to test the residual current
: protection relay (RCCB), "since you have to set all the clocks anyway".
: 
: We know from electricians purchases of new RCCBs that this advice
: is widely taken.
: 
: I would keep DST, even if it confers no other benefits, simply because
: from a societal point of view, it is beneficial to have the populations
: almost undivided attention twice a year.

In the US, many fire departments have similar public safety
campaigns.  Change your fire detector batteries when you change your
clock.

Warner

From imp at bsdimp.com  Sun Dec 28 11:47:17 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 09:47:17 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>
References: <32684.1230451984@critter.freebsd.dk>
	<0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>
Message-ID: <20081228.094717.1120059156.imp@bsdimp.com>

In message: <0B4062CC-0E7E-407F-A856-37F9C74DC081 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: I wrote:
: 
: >> The ITU has a responsibility to consider options with a long term  
: >> future.
: 
: Poul-Henning Kamp writes:
: 
: > ITU has no such responsibility:
: >
: >  	1 The purposes of the Union are:
: >
: > 		a) to maintain and extend international cooperation
: > 		among all its Member States for the improvement and
: > 		rational use of telecommunications of all kinds;
: >
: > 		[...]
: >
: > (http://www.itu.int/net/about/basic-texts/constitution/chapteri.aspx)
: >
: > If leap-seconds impeede telecommunications, ITU has a responsibility
: > to get rid of them.
: 
: 
: 1) An organization with a limited scope (telecommunications) should  
: not control a standard with a much broader scope (timekeeping).
: 
: 2) All organizations have an implicit responsibility not to pursue  
: shortsighted agendas.  If an option has no long term future, the ITU  
: certainly has no business considering it.

Leap seconds was a short-sighted agenda.  The goal was noble, but the
implementation was flawed.  Changing things to be less flawed is
better.  But in any such change there will be winners and losers.

Warner

From imp at bsdimp.com  Sun Dec 28 11:50:15 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 09:50:15 -0700 (MST)
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <E0B169D4-ACC0-4479-90CD-7097EDB48D0B@noao.edu>
References: <32641.1230451572@critter.freebsd.dk>
	<E0B169D4-ACC0-4479-90CD-7097EDB48D0B@noao.edu>
Message-ID: <20081228.095015.1573373309.imp@bsdimp.com>

In message: <E0B169D4-ACC0-4479-90CD-7097EDB48D0B at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Poul-Henning Kamp wrote:
: 
: > In addition to the Olsen database, the book "Calendrical  
: > Calculations" is probably required.
: 
: Good point.
: 
: To count days and align international timelines using the current  
: civil timescale, civilians (e.g., historians) need none of this.
: 
: Under the ITU's plan to degrade UTC, civilians will need to hire  
: experts like us to perform this simple task.

No need to hire experts.

A simple table needs no expert assistance.  Historians who care,
which would likely be a vanishly small minority, can do the extra
swizzle.  Since the volume of such calculations would be very small,
this doesn't seem to be a compelling argument.

Especially since time is already based on an atomic time scale.  As
its rate of ticking continues to diverge from the earth, we will have
to abandon such synchronization.

Warner

From seaman at noao.edu  Sun Dec 28 13:48:14 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 11:48:14 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <35176.1230481981@critter.freebsd.dk>
References: <35176.1230481981@critter.freebsd.dk>
Message-ID: <5C82ABF9-E6CD-4D3E-9012-E2772B681EC9@noao.edu>

Poul-Henning Kamp wrote:

> Rob, you keep making these claims that a lot of 'needs' and  
> 'requirements' are being overlooked.
>
> Why is it that you never offer a single concrete example ?

1) Read the archives.  The astronomers and astronomical software  
engineers here have done the best job of analyzing the concrete  
implications of the ITU proposal for the systems under our care.  Send  
me source code and project documentation and pay me for my time and  
I'll take a whack at vetting your systems.

2) That isn't how system requirements work.  Whether or not anybody  
ever writes down a list, a broad set of interlocking requirements  
exists underlying every system.  For fundamental infrastructure such  
as timekeeping this set is particularly extensive.

3) The burden of proof rests elsewhere:

	http://www.nizkor.org/features/fallacies/burden-of-proof.html

> I think it is a pretty good proposal

The goodness (completeness and consistency) of a proposal is not  
determined by opinion:

	http://www.nizkor.org/features/fallacies/appeal-to-belief.html

This is why peer review subjects assertions to vigorous and rigorous  
challenge.

In my opinion, at a minimum the proposal needs to 1) explain why the  
Torino consensus should be rejected, 2) offer a viable mechanism for  
handling the inevitable intercalary adjustments (of whatever sort),  
and 3) describe in detail how access to UT1 will be provided in the  
absence of DUT1.

That's my opinion.  The goodness of any proposal needs to be  
rigorously established via a process transparent to all.  This is the  
quickest way to reach consensus, that is, to refine opinions on all  
sides.  When the ITU votes it should simply be ratifying consensus.

> and I hope nobody get killed by leap seconds before it takes effect.

Our decisions should not be driven by unsupported fears:

	http://www.nizkor.org/features/fallacies/appeal-to-fear.html

Risks are notoriously hard to characterize.  System engineering  
methodology provides the best tools to do the job.

A good start would be to list concrete examples of risks for projects  
that inappropriately selected UTC when an interval timescale like GPS  
was clearly required.

Rob

From dot at dotat.at  Sun Dec 28 14:20:52 2008
From: dot at dotat.at (Tony Finch)
Date: Sun, 28 Dec 2008 19:20:52 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <20081227.192200.-1749704408.imp@bsdimp.com>
References: <C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
	<20081227.192200.-1749704408.imp@bsdimp.com>
Message-ID: <alpine.LSU.2.00.0812281913170.16108@hermes-1.csi.cam.ac.uk>

On Sat, 27 Dec 2008, M. Warner Losh wrote:
>
> However, the die was cast on this in 1958 when the second was defined in
> terms of atomic behavior.  At that point, the game was up, since the
> basic unit of time was decoupled from the day.

The decoupling occurred before then, when the second was defined in terms
of the length of the tropical year established by Newcomb. The atomic
second was calibrated to match this older definition.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FISHER GERMAN BIGHT: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6 IN GERMAN BIGHT.
SLIGHT OR MODERATE. FAIR. GOOD.

From dwmalone at maths.tcd.ie  Sun Dec 28 14:38:47 2008
From: dwmalone at maths.tcd.ie (David Malone)
Date: Sun, 28 Dec 2008 19:38:47 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 01:29:11 GMT."
	<alpine.LSU.2.00.0812272320490.23685@hermes-1.csi.cam.ac.uk> 
Message-ID: <200812281938.aa48502@walton.maths.tcd.ie>

> Firstly: The history shows that almost any violence can be done to civil
> time so long as everyone agrees to it. DST shows that sociology can trump
> astronomy. (Standard time shows the same thing, but DST's arbitrariness
> makes this fact much more starkly clear.) Broad agreement and consensus is
> the foundation of civil time. The way that leap seconds work clearly does
> not have enough consensus, in that people still produce software and
> standards and specifications that are incompatible with leap seconds.

This is not a particularly good metric. A lot of people (and systems)
are incompatible with the Gregorian calendar and make every fourth
year a leap year. Similarly, an amount of software was incompatible
with the twenty first century, but we went ahead with that anyway ;-)

(Also, you probably don't need people to agree - you probably only
need people to be able to claim that they agree and have the
disagreement lost in the fuzz. Poul-Henning has pointed out how
this is important in the EU, and I assume it is equally important
in all standards bodies.)

	David.

From dot at dotat.at  Sun Dec 28 14:49:37 2008
From: dot at dotat.at (Tony Finch)
Date: Sun, 28 Dec 2008 19:49:37 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <200812281938.aa48502@walton.maths.tcd.ie>
References: <200812281938.aa48502@walton.maths.tcd.ie>
Message-ID: <alpine.LSU.2.00.0812281940240.16108@hermes-1.csi.cam.ac.uk>

On Sun, 28 Dec 2008, David Malone wrote:

> > Broad agreement and consensus is the foundation of civil time. The way
> > that leap seconds work clearly does not have enough consensus, in that
> > people still produce software and standards and specifications that
> > are incompatible with leap seconds.
>
> This is not a particularly good metric. A lot of people (and systems)
> are incompatible with the Gregorian calendar and make every fourth
> year a leap year. Similarly, an amount of software was incompatible
> with the twenty first century, but we went ahead with that anyway ;-)

I don't think hese are good counter-examples. The Y2K1 bug is beyond the
design lifetime of a lot of systems - in fact the next big breakage is
much sooner, in 2036, and there's still not much sign of work to fix it.
Short design lifetimes were also a major reason for the Y2K bug, and in
that case everyone agreed that it was a bug and agreed to fix or retire
the broken software. However not everyone agrees that being incompatible
with leap seconds is a bug, and they often deliberately design systems
fully aware that they are incompatible. That is, design teams and
standards committees repeatedly reach a consensus to ignore leap seconds.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
THAMES DOVER: EAST 5 OR 6, DECREASING 3 OR 4. SMOOTH OR SLIGHT, OCCASIONALLY
MODERATE AT FIRST. FAIR. GOOD, OCCASIONALLY MODERATE LATER.

From dot at dotat.at  Sun Dec 28 14:57:27 2008
From: dot at dotat.at (Tony Finch)
Date: Sun, 28 Dec 2008 19:57:27 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <32641.1230451572@critter.freebsd.dk>
References: <32641.1230451572@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0812281951150.16108@hermes-1.csi.cam.ac.uk>

On Sun, 28 Dec 2008, Poul-Henning Kamp wrote:
>
> In addition to the Olsen database, the book "Calendrical Calculations"
> is probably required.

"Calendrical Calculations" isn't a reliable source for historians in the
way that the Olson database tries to be. CC is a mechanized description of
how calendars are supposed to work, not a record of how they are actually
used. This is particularly important for observational calendars such as
the Islamic calendar where practice can and does differ from theory. The
tz database attempts to record what timezones were actually used in
different places at different times.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTHEAST ICELAND: SOUTH OR SOUTHWEST 5 OR 6, DECREASING 4 AT TIMES. MODERATE
OR ROUGH. OCCASIONAL DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.

From zefram at fysh.org  Sun Dec 28 16:49:38 2008
From: zefram at fysh.org (Zefram)
Date: Sun, 28 Dec 2008 21:49:38 +0000
Subject: [LEAPSECS] civil-solar correlation with TI
In-Reply-To: <alpine.LSU.2.00.0812281951150.16108@hermes-1.csi.cam.ac.uk>
References: <32641.1230451572@critter.freebsd.dk>
	<alpine.LSU.2.00.0812281951150.16108@hermes-1.csi.cam.ac.uk>
Message-ID: <20081228214938.GN2263@fysh.org>

Tony Finch wrote:
>"Calendrical Calculations" isn't a reliable source for historians in the
>way that the Olson database tries to be. CC is a mechanized description of
>how calendars are supposed to work,

Actually it doesn't even fully achieve that.  The numerical algorithms
are correct, as far as I can see, but the descriptions of the underlying
theory are often muddled, riddled with errors and critical omissions.
(Count how many different quantities go by the name "RD".)  Rather
importantly for our purposes, CC ignores the existence of timezones (or,
for that matter, longitude).

>tz database attempts to record what timezones were actually used in
>different places at different times.

It would be nice to have the analogous database for calendar usage.

-zefram

From seaman at noao.edu  Sun Dec 28 17:40:02 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 15:40:02 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <81805A57-5977-4164-8F7C-78354E68BD21@noao.edu>
References: <C48AB2AB-E2CB-4E6C-985E-C4DC64E65A3B@noao.edu>
	<875588B9-09A7-465D-890E-90E3DD8B91BF@noao.edu>
	<5DE48B7A-0D30-4580-B110-7687A75A2904@noao.edu>
	<20081227.192200.-1749704408.imp@bsdimp.com>
	<81805A57-5977-4164-8F7C-78354E68BD21@noao.edu>
Message-ID: <1FB1C7F7-95F4-450A-B823-349ABA3B8A77@noao.edu>

M. Warner Losh wrote:

> the die was cast on this in 1958 when the second was defined in  
> terms of atomic behavior.

This may not be the best choice of idiom.  "The die is cast" is what  
Caesar is supposed to have said as he crossed the Rubicon (another  
phrase you could use in the sentence above).  It is a metaphor for  
committing to an outcome, yes, but in particular to committing to a  
chance outcome (with further implications of a looming battle).   
Rather, you are asserting that a specific, albeit implicit, decision  
has already been reached.

(Perhaps a better metaphor would be "reaching a tipping point" or  
"passing the point of no return".  There's also the one about the  
camel's back :-)

However, nobody has been arguing for rubber seconds.  (Except on  
extremely long timescales exceeding the current age of civilization on  
Earth.)  Your assertion is a straw man:

	http://www.nizkor.org/features/fallacies/straw-man.html

Meanwhile, the length of day has been malleable since before the  
Cambrian Explosion, let alone over any modern human timescale.  We are  
saying nothing new here.

The real observation is the familiar one of dual timescales.  Focus on  
the SI second and we see the world through atomic eyeballs.  Focus on  
the primacy of the definition of the day in civil timekeeping, and  
Earth orientation pops out.

Both timescales are necessary.

Rob

From phk at phk.freebsd.dk  Sun Dec 28 18:05:19 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 28 Dec 2008 23:05:19 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 15:40:02 MST."
	<1FB1C7F7-95F4-450A-B823-349ABA3B8A77@noao.edu> 
Message-ID: <36594.1230505519@critter.freebsd.dk>

In message <1FB1C7F7-95F4-450A-B823-349ABA3B8A77 at noao.edu>, Rob Seaman writes:

>The real observation is the familiar one of dual timescales.  Focus on  
>the SI second and we see the world through atomic eyeballs.  Focus on  
>the primacy of the definition of the day in civil timekeeping, and  
>Earth orientation pops out.
>
>Both timescales are necessary.

It is well documented that the SI second based timescale has precision
and stability requirements on the order of microseconds for telecoms
and 10 orders of magnitude smaller for scientific tasks.

In contrast to this, nobody, including you, seem to be willing to
even hazard a guess what level of presision is required or sufficient
for the "earth orientation clock".

The current UTC definition says "better than one second", but relative
to an abstract definition of earth rotation angle which 
only astronomers can figure out.

Emperical evidence show that most of the earths human population is
perfectly happy with local time that is within a couple of hours
of "proper" earth rotation time.

The fact that almost all people who have one, trust and rely on the
clock in their mobile phone, certainly much more than they do on
the lengths of shadows and shadows on sun-dials, is a credible
argument that no such requirement really exists, and that the
mechanism proposed bu ITU combined with country-by-country timezone
adjustments is a valid and solid solution.

Now, stop the red-tape machine Rob, and put some facts on the table.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Sun Dec 28 18:12:40 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 16:12:40 -0700
Subject: [LEAPSECS] We can all be winners
In-Reply-To: <20081228.094717.1120059156.imp@bsdimp.com>
References: <32684.1230451984@critter.freebsd.dk>
	<0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>
	<20081228.094717.1120059156.imp@bsdimp.com>
Message-ID: <1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>

M. Warner Losh wrote:

> Leap seconds was a short-sighted agenda.  The goal was noble,

Wow!  Even I wouldn't ascribe nobility to leap seconds :-)

> but the implementation was flawed.

Yes.  Many shortsighted technical projects adopted UTC when they had  
no business doing so.  The fundamental fix is to relayer these  
nonconforming projects on timescale(s) better suited to their purpose,  
not to fundamentally redefine UTC to no longer represent universal time.

> Changing things to be less flawed is better.

This is a tautology by the definition of "less flawed".  However, if a  
system is permitted to evolve blindly it may well end up stranded at a  
local flaw minimum, with a much better design elsewhere in parameter  
space.

> But in any such change there will be winners and losers.


This is yet another assertion that we're engaged in a zero-sum game:

	http://www.nizkor.org/features/fallacies/middle-ground.html

Rather, the nine years spent ankle-biting at the ponderous  
machinations of the ITU could have been better spent actually  
discovering a full set of requirements for civil timekeeping.   
Blinkered thinking could have been replaced with a structured design  
process.  We would all have benefited.

Rob


From msokolov at ivan.Harhan.ORG  Sun Dec 28 18:16:43 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Sun, 28 Dec 2008 23:16:43 GMT
Subject: [LEAPSECS] Cheating means more planning, not less
Message-ID: <0812282316.AA15987@ivan.Harhan.ORG>

Rob Seaman <seaman at noao.edu> wrote:

> However, nobody has been arguing for rubber seconds.

I have consistently been arguing for rubber seconds!

MS

From imp at bsdimp.com  Sun Dec 28 18:57:08 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 16:57:08 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <1FB1C7F7-95F4-450A-B823-349ABA3B8A77@noao.edu>
References: <20081227.192200.-1749704408.imp@bsdimp.com>
	<81805A57-5977-4164-8F7C-78354E68BD21@noao.edu>
	<1FB1C7F7-95F4-450A-B823-349ABA3B8A77@noao.edu>
Message-ID: <20081228.165708.1641579405.imp@bsdimp.com>

In message: <1FB1C7F7-95F4-450A-B823-349ABA3B8A77 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: However, nobody has been arguing for rubber seconds.  (Except on  
: extremely long timescales exceeding the current age of civilization on  
: Earth.)  Your assertion is a straw man:
: 
: 	http://www.nizkor.org/features/fallacies/straw-man.html

Actually, it isn't.  Your arguments are so full of logical fallacies
that I don't even bother any more.

I know that nobody is proposing rubber seconds today.  You know I know
that.  I'm saying that the second used to be a measure of the change
in the earth, since it was a subdivision of the day.  By its very
nature, it was rubber, since it was a subdivision of something that
was rubber.  It is called historical perspective, and is quite
relevant to your assertions that there's something inherently 'mean
solar time' about UTC.  There isn't.  It is an atomic scale that is
presently kept in sync with mean solar time.

And there were rubber seconds from 1961 until 1972.  The clocks were
ticking at slight offsets to the atomic time to keep the atomic time
scale (UTC) in sync with the mean solar time.  This, I was arguing,
was an extension of the prior 'rubber seconds' which were a division
of the day, which was by its very nature rubber in length for a very
long time.

: Meanwhile, the length of day has been malleable since before the  
: Cambrian Explosion, let alone over any modern human timescale.  We are  
: saying nothing new here.

Correct.

: The real observation is the familiar one of dual timescales.  Focus on  
: the SI second and we see the world through atomic eyeballs.  Focus on  
: the primacy of the definition of the day in civil timekeeping, and  
: Earth orientation pops out.
:
: Both timescales are necessary.

I think we disagree about what is primary in the civil time keeping.
I don't think it has to be mean solar time, except in a very gross
sense of the terms.  I think it can vary quite a bit from mean local
solar time, and it will still work.  I believe that the tolerance of
local time is on the order of 10000 times less strict than the current
practice of inserting a leap second when UT1 and UTC differ by too
much (typically by more than .5s).  It can easily tolerate a large
variance and people are still cool with it.  10000x translates to
something just over an hour.

Warner


From msokolov at ivan.Harhan.ORG  Sun Dec 28 19:02:22 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 29 Dec 2008 00:02:22 GMT
Subject: [LEAPSECS] Cheating means more planning, not less
Message-ID: <0812290002.AA16091@ivan.Harhan.ORG>

M. Warner Losh <imp at bsdimp.com> wrote:

> I know that nobody is proposing rubber seconds today.

Wrong!  I am!

MS

From imp at bsdimp.com  Sun Dec 28 19:03:29 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 17:03:29 -0700 (MST)
Subject: [LEAPSECS] We can all be winners
In-Reply-To: <1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>
References: <0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>
	<20081228.094717.1120059156.imp@bsdimp.com>
	<1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>
Message-ID: <20081228.170329.-116097799.imp@bsdimp.com>

In message: <1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > Leap seconds was a short-sighted agenda.  The goal was noble,
: 
: Wow!  Even I wouldn't ascribe nobility to leap seconds :-)

Well, not in how they were thrust upon the world.  However, the goal
of keeping astronomical and atomic time in sync was a worthy one.

: > but the implementation was flawed.
: 
: Yes.  Many shortsighted technical projects adopted UTC when they had  
: no business doing so.  The fundamental fix is to relayer these  
: nonconforming projects on timescale(s) better suited to their purpose,  
: not to fundamentally redefine UTC to no longer represent universal time.

Experience has shown that multiple time scales lead to confusion.
Look at the problems that have been enumerated here when a GPS
receiver starts up cold.  It knows right away what the GPS time is,
but takes as long as about 20 minutes to know what the UTC time is.
This causes grief for those systems that want to start faster than
that to display UTC time.  Other examples have been proffered.

: > Changing things to be less flawed is better.
: 
: This is a tautology by the definition of "less flawed".  However, if a  
: system is permitted to evolve blindly it may well end up stranded at a  
: local flaw minimum, with a much better design elsewhere in parameter  
: space.

This isn't a tautology.  This is an argument based on the merits of
the flaws of the different proposals.  "less flawed" and "better" are
both pejorative phrases, and I was hoping to show that all proposals
are flawed in some way.

: > But in any such change there will be winners and losers.
: 
: 
: This is yet another assertion that we're engaged in a zero-sum game:
: 
: 	http://www.nizkor.org/features/fallacies/middle-ground.html

Not it isn't.  It is a simple acknowledgment that some folks will win
and some lose.  The winners might win a lot more than the losers, or
vice versa.

: Rather, the nine years spent ankle-biting at the ponderous  
: machinations of the ITU could have been better spent actually  
: discovering a full set of requirements for civil timekeeping.   
: Blinkered thinking could have been replaced with a structured design  
: process.  We would all have benefited.

I'm not sure that the ITU would have produced anything that's
significantly more functional and robust than the proposal on the
table today.

Warner

From imp at bsdimp.com  Sun Dec 28 19:03:57 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 17:03:57 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0812282316.AA15987@ivan.Harhan.ORG>
References: <0812282316.AA15987@ivan.Harhan.ORG>
Message-ID: <20081228.170357.-165198730.imp@bsdimp.com>

In message: <0812282316.AA15987 at ivan.Harhan.ORG>
            msokolov at ivan.Harhan.ORG (Michael Sokolov) writes:
: Rob Seaman <seaman at noao.edu> wrote:
: 
: > However, nobody has been arguing for rubber seconds.
: 
: I have consistently been arguing for rubber seconds!

Just like rubber bullets, they are less lethal than real seconds :)

Warner

From imp at bsdimp.com  Sun Dec 28 19:10:17 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 17:10:17 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0812290002.AA16091@ivan.Harhan.ORG>
References: <0812290002.AA16091@ivan.Harhan.ORG>
Message-ID: <20081228.171017.387191281.imp@bsdimp.com>

In message: <0812290002.AA16091 at ivan.Harhan.ORG>
            msokolov at ivan.Harhan.ORG (Michael Sokolov) writes:
: M. Warner Losh <imp at bsdimp.com> wrote:
: 
: > I know that nobody is proposing rubber seconds today.
: 
: Wrong!  I am!

I don't think that's a viable thing to do.  It would play havoc with
anything except the most low-precision timing applications.  And if
you don't solve the problem for high-precision timing applications,
I'm not sure that it is a viable solution.

Warner

From msokolov at ivan.Harhan.ORG  Sun Dec 28 19:17:24 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 29 Dec 2008 00:17:24 GMT
Subject: [LEAPSECS] Cheating means more planning, not less
Message-ID: <0812290017.AA16164@ivan.Harhan.ORG>

M. Warner Losh <imp at bsdimp.com> wrote:

> I don't think that's a viable thing to do.  It would play havoc with
> anything except the most low-precision timing applications.

But civil time *is* a low-precision timing application!

> And if
> you don't solve the problem for high-precision timing applications,
> I'm not sure that it is a viable solution.

Those need to use a diffirent time scale decoupled from civil time,
i.e., TAI, GPS, TT, whatever.  There need to be two different seconds,
a civil second and a scientific second.  The latter would be better
renamed to essen.

MS

From imp at bsdimp.com  Sun Dec 28 19:21:08 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 17:21:08 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0812290017.AA16164@ivan.Harhan.ORG>
References: <0812290017.AA16164@ivan.Harhan.ORG>
Message-ID: <20081228.172108.1605901973.imp@bsdimp.com>

In message: <0812290017.AA16164 at ivan.Harhan.ORG>
            msokolov at ivan.Harhan.ORG (Michael Sokolov) writes:
: M. Warner Losh <imp at bsdimp.com> wrote:
: 
: > I don't think that's a viable thing to do.  It would play havoc with
: > anything except the most low-precision timing applications.
: 
: But civil time *is* a low-precision timing application!

Not really.  It is used for timing transactions on exchange boards to
the millisecond to ensure proper pricing in fast changing markets...

: > And if
: > you don't solve the problem for high-precision timing applications,
: > I'm not sure that it is a viable solution.
: 
: Those need to use a diffirent time scale decoupled from civil time,
: i.e., TAI, GPS, TT, whatever.  There need to be two different seconds,
: a civil second and a scientific second.  The latter would be better
: renamed to essen.

Right.  Good luck with that one...

Warner

From dan at tobias.name  Sun Dec 28 20:30:55 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Sun, 28 Dec 2008 20:30:55 -0500
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0812290002.AA16091@ivan.Harhan.ORG>
References: <0812290002.AA16091@ivan.Harhan.ORG>
Message-ID: <4957E1FF.11222.7E26927@dan.tobias.name>

On 29 Dec 2008 at 0:02, Michael Sokolov wrote:

> M. Warner Losh <imp at bsdimp.com> wrote:
> 
> > I know that nobody is proposing rubber seconds today.
> 
> Wrong!  I am!

To the tune of the Rubber Duckie Song:
http://rubaduck.com/articles/rubber-duckie-song.htm

Rubber Second you?re the one,
You make timekeeping lots of fun,
Rubber Second I?m awfully fond of you
Vo-vo-dee-o!


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From seaman at noao.edu  Sun Dec 28 20:31:02 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 18:31:02 -0700
Subject: [LEAPSECS] We can all be winners
In-Reply-To: <20081228.170329.-116097799.imp@bsdimp.com>
References: <0B4062CC-0E7E-407F-A856-37F9C74DC081@noao.edu>
	<20081228.094717.1120059156.imp@bsdimp.com>
	<1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>
	<20081228.170329.-116097799.imp@bsdimp.com>
Message-ID: <3BF733CC-BCAB-4B42-ACB1-C903E98EA40F@noao.edu>

M. Warner Losh wrote:

> Experience has shown that multiple time scales lead to confusion.

The confusion is inherent in the system requirements.  There are two  
different kinds of timescale.  That is a simple fact.  How do we deal  
with that reality?  Wishing one away won't work.

> Look at the problems that have been enumerated here when a GPS
> receiver starts up cold.  It knows right away what the GPS time is,
> but takes as long as about 20 minutes to know what the UTC time is.
> This causes grief for those systems that want to start faster than
> that to display UTC time.

Surely the GPS receiver should be fed into an NTP server and the  
systems you describe should be receiving their time from the normal  
ensemble of servers?

Your comment is a simple observation about how GPS works.

> I'm not sure that the ITU would have produced anything that's
> significantly more functional and robust than the proposal on the
> table today.

The ITU doesn't have to go it alone.  As rousing as the discussions on  
the NTP WG can get, I proffer it as a example of a better process.

Rob


From seaman at noao.edu  Sun Dec 28 20:44:12 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 18:44:12 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <20081228.171017.387191281.imp@bsdimp.com>
References: <0812290002.AA16091@ivan.Harhan.ORG>
	<20081228.171017.387191281.imp@bsdimp.com>
Message-ID: <67C8553C-1504-495B-AC99-6E006E0CC01B@noao.edu>

  M. Warner Losh wrote:

> Michael Sokolov writes
>
> : M. Warner Losh <imp at bsdimp.com> wrote:
> :
> : > I know that nobody is proposing rubber seconds today.
> :
> : Wrong!  I am!
>
> I don't think that's a viable thing to do.  It would play havoc with
> anything except the most low-precision timing applications.  And if
> you don't solve the problem for high-precision timing applications,
> I'm not sure that it is a viable solution.

I figured I'd grab a chance to agree wholeheartedly with Warner :-)

Just one comment.  The requirements for "timing applications" (of  
whatever precision) are distinct from the requirements for civil clock  
applications.

Rob


From seaman at noao.edu  Sun Dec 28 21:47:30 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 19:47:30 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <0812290017.AA16164@ivan.Harhan.ORG>
References: <0812290017.AA16164@ivan.Harhan.ORG>
Message-ID: <05ED4E1C-DC79-4F30-BD03-69A48940DE9C@noao.edu>

Michael Sokolov wrote:

> But civil time *is* a low-precision timing application!

Civil time is not a timing application.  It is not an application at  
all.  Whatever the past or future of civil timescales, these form  
infrastructure that applications are built upon.  Precision is one of  
many requirements incumbent on applications.  How the necessary level  
of precision is obtained may drive choice of one or another or several  
different timekeeping technologies and standards.

M. Warner Losh wrote:

>> And if you don't solve the problem for high-precision timing  
>> applications, I'm not sure that it is a viable solution.
>
> Those need to use a diffirent time scale decoupled from civil time,  
> i.e., TAI, GPS, TT, whatever.

This is often true now, and will often be true in the future.   
Requirements driving this will tend to split into clock requirements  
versus interval timing requirements.  (Search the archive for  
"chronometer" to track down our previous discussions on similar topics.)

> There need to be two different seconds, a civil second and a  
> scientific second.  The latter would be better renamed to essen.

Well, as Warner might say, "that boat has sailed".  We would certainly  
have more clarity of understanding if the SI second had been called  
something else, and especially if it had been chosen to have no  
relation to 1/86,400 of the length of the solar day.

Maybe we can just call it "Celsius time" and make a Celsius second  
equal to 9/5 of a civil second (as of 1820).

Rob


From imp at bsdimp.com  Sun Dec 28 22:29:49 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 20:29:49 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <05ED4E1C-DC79-4F30-BD03-69A48940DE9C@noao.edu>
References: <0812290017.AA16164@ivan.Harhan.ORG>
	<05ED4E1C-DC79-4F30-BD03-69A48940DE9C@noao.edu>
Message-ID: <20081228.202949.-165353418.imp@bsdimp.com>

In message: <05ED4E1C-DC79-4F30-BD03-69A48940DE9C at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Maybe we can just call it "Celsius time" and make a Celsius second  
: equal to 9/5 of a civil second (as of 1820).

hahahhahaha...  Of course, the unit of time would have to be the
Newcomb..

Warner

From imp at bsdimp.com  Sun Dec 28 22:27:47 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 28 Dec 2008 20:27:47 -0700 (MST)
Subject: [LEAPSECS] We can all be winners
In-Reply-To: <3BF733CC-BCAB-4B42-ACB1-C903E98EA40F@noao.edu>
References: <1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>
	<20081228.170329.-116097799.imp@bsdimp.com>
	<3BF733CC-BCAB-4B42-ACB1-C903E98EA40F@noao.edu>
Message-ID: <20081228.202747.1079620836.imp@bsdimp.com>

In message: <3BF733CC-BCAB-4B42-ACB1-C903E98EA40F at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > Experience has shown that multiple time scales lead to confusion.
: 
: The confusion is inherent in the system requirements.  There are two  
: different kinds of timescale.  That is a simple fact.  How do we deal  
: with that reality?  Wishing one away won't work.

I contend we don't actually need a mean solar time to the sub-second
time scale for civil time.  A mean solar time to the hour is likely
sufficient for that.

: > Look at the problems that have been enumerated here when a GPS
: > receiver starts up cold.  It knows right away what the GPS time is,
: > but takes as long as about 20 minutes to know what the UTC time is.
: > This causes grief for those systems that want to start faster than
: > that to display UTC time.
: 
: Surely the GPS receiver should be fed into an NTP server and the  
: systems you describe should be receiving their time from the normal  
: ensemble of servers?

Except that these boxes aren't on any kind of network that have a
source of time.  They are the source of time for this closed
network...

: Your comment is a simple observation about how GPS works.

Yes.  It illustrates one of the many problems of having multiple time
scales that are off by an integral number of seconds.  The problems
likely get worse when seconds don't align (either because they are
different sizes or have a different offset or both).

: > I'm not sure that the ITU would have produced anything that's
: > significantly more functional and robust than the proposal on the
: > table today.
: 
: The ITU doesn't have to go it alone.  As rousing as the discussions on  
: the NTP WG can get, I proffer it as a example of a better process.

Maybe, but many of the folks on the NTP WG are in the high precision
time community...  The ITU member nations likely are a more diverse
group...

Warner

From seaman at noao.edu  Sun Dec 28 23:10:38 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 21:10:38 -0700
Subject: [LEAPSECS] We can all be winners
In-Reply-To: <20081228.202747.1079620836.imp@bsdimp.com>
References: <1062ADB7-49B9-4374-9FA1-A0E0BABB6D1C@noao.edu>
	<20081228.170329.-116097799.imp@bsdimp.com>
	<3BF733CC-BCAB-4B42-ACB1-C903E98EA40F@noao.edu>
	<20081228.202747.1079620836.imp@bsdimp.com>
Message-ID: <98F92F01-DEC2-4705-8817-EBE62021A1E6@noao.edu>

Impossible to keep up with all the messages.  Presumably it will calm  
down when the leap second turns out to be a non-issue yet again ;-)

M. Warner Losh wrote:

> I contend we don't actually need a mean solar time to the sub-second  
> time scale for civil time.  A mean solar time to the hour is likely  
> sufficient for that.

The key issue is the stability of the civil timescale, not its  
precision.  However, degrading the precision by 5 orders of magnitude  
in one gulp seems rather...excessive.  The actual proposal on the  
table, of course, simply denies the existence of the Sun in the sky.

Rob


From seaman at noao.edu  Mon Dec 29 01:45:07 2008
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 28 Dec 2008 23:45:07 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <DC36F13E-99C8-4964-A928-A78A45C4BCDD@noao.edu>
References: <36594.1230505519@critter.freebsd.dk>
	<C09A1879-2B9F-47BE-81EE-626083683FC2@noao.edu>
	<DC36F13E-99C8-4964-A928-A78A45C4BCDD@noao.edu>
Message-ID: <78F76698-B873-42F2-9D22-E11513189793@noao.edu>

Poul-Henning Kamp wrote:

> Rob Seaman writes:
>
>> Focus on the SI second and we see the world through atomic  
>> eyeballs.  Focus on the primacy of the definition of the day in  
>> civil timekeeping, and Earth orientation pops out.
>>
>> Both timescales are necessary.
>
> It is well documented that the SI second based timescale has  
> precision and stability requirements on the order of microseconds  
> for telecoms and 10 orders of magnitude smaller for scientific tasks.

So I guess we're agreed that this is one of the necessary timescales.   
Good thing it is already widely available in GPS.  (The 10^-16 is a  
bit extreme :-)  A lot of good science happens at a precision less  
than a second, for that matter.

> In contrast to this, nobody, including you, seem to be willing to  
> even hazard a guess what level of presision is required or  
> sufficient for the "earth orientation clock".

The current UTC standard is precise to 0.1 SI seconds.  I will hazard  
a guess that this is sufficient.  I believe we both have long since  
expressed the opinion that this could be relaxed a bit.  If the ITU  
proposal didn't explicitly deprecate DUT1, a new-and-improved UTC  
could even improve the precision for corrected values while loosening  
the fit for uncorrected values.

> The current UTC definition says "better than one second",

Well, 0.9s.

> but relative to an abstract definition of earth rotation angle which  
> only astronomers can figure out.

I'll spare everybody my familiar harangue on the mean solar day just  
corresponding to the sidereal day plus a little bit extra to correct  
for the Earth lapping the Sun once a year.

Oh!  I guess I won't.  Raise your hand if you can't figure out what I  
just said.

> Emperical evidence show that most of the earths human population is  
> perfectly happy with local time that is within a couple of hours of  
> "proper" earth rotation time.

And I really will spare folks my other screed on civil timekeeping  
having nothing to do with local apparent solar time.  Since everybody  
seems to agree on this point, I'm not sure why it keeps coming up.

Rob


From phk at phk.freebsd.dk  Mon Dec 29 03:01:59 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 29 Dec 2008 08:01:59 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Sun, 28 Dec 2008 18:44:12 MST."
	<67C8553C-1504-495B-AC99-6E006E0CC01B@noao.edu> 
Message-ID: <38318.1230537719@critter.freebsd.dk>

In message <67C8553C-1504-495B-AC99-6E006E0CC01B at noao.edu>, Rob Seaman writes:

>Just one comment.  The requirements for "timing applications" (of  
>whatever precision) are distinct from the requirements for civil clock  
>applications.

You seem to think "civil clock applications" is little old ladies
walking to church once a week.

A modern passengerplane moves approximately 300 meters per second.
Are you willing to to accept a +/- 300 meter tolerance on the radar
track during final approach in Cat3 conditions, if you are on the
plane ?

How much havoc do you think a one second difference makes in a
modern robotic car-production facility ?  Have you ever wondered
why the car industry is so interested in IEEE-1588 ?

Having to classify applications into "timing" and "civil" in the
first place is what brought us here.

A lot of people didn't know that their applications were "timing"
so they didn't add code for the leap-second-polka.

>The key issue is the stability of the civil timescale, not its  
>precision.  However, degrading the precision by 5 orders of magnitude  
>in one gulp seems rather...excessive.

Rob, we could take you a whole lot more serious if you didn't spew
bull-shit like this.

The earth is not going to jump 15 degrees of rotation on jan 2nd
2018, so any talk about "degrading precision by 5 orders of magnitude"
is disinginuous and deliberately misleading.

As has been well documented, it will take several hundred years
before the difference approaches an hour.

Second, the ITU proposal decentralizes the time-of-day vs. solar
position tolerance to national issue.

I think is very proper, considering the very different policies
adopted with respect to timezones (EU vs China for instance)
and different durations of sunrise/sunset (Van Mayen vs. Congo for
instance).

> Rather, the nine years spent ankle-biting at the ponderous  
> machinations of the ITU could have been better spent actually  
> discovering a full set of requirements for civil timekeeping.   

So Rob, why didn't you ?

Ankle-biting is the best description for your disinformation
campaign I have seen yet.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Mon Dec 29 11:05:59 2008
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 29 Dec 2008 09:05:59 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <38318.1230537719@critter.freebsd.dk>
References: <38318.1230537719@critter.freebsd.dk>
Message-ID: <3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>

My apologies for the long reply.  The personal attacks reached a  
tipping point.  Others should feel free to skip this (as I'm sure they  
do all my messages :-)

Poul-Henning Kamp wrote:

> Rob Seaman writes:
>
>> Just one comment.  The requirements for "timing applications" (of  
>> whatever precision) are distinct from the requirements for civil  
>> clock applications.
>
> You seem to think "civil clock applications" is little old ladies  
> walking to church once a week.

My parenthetical remark about precision seems to have been  
insufficient disclaimer.  Apologies for yet another Strother Martin  
moment.

That is one use case, yes.

But the real point I'm failing to communicate is simply the  
distinction between clocks and timers.  Since it is a truism that  
every thread on leapsecs has been discussed previously, you can find  
some insightful comments from folks like Steve Allen in the archives  
on this topic.  The two different types of timekeepers may previously  
have been referred to as clocks and chronometers.

A timer keeps interval time - highly precise, but perhaps only  
accurate in a relative sense.

A clock keeps Earth orientation time (or other fundamental reference)  
- accurate in an absolute sense, but not necessarily very precise.

The point is system engineering again.  The requirements for an  
interval timer are simply distinct from the requirements for a clock.   
They may overlap, they may not.  One or the other set of requirements  
may be more important for a particular application.

As all within reach of my keyboard surely know, I believe civil  
timekeeping to be fundamentally dependent on requirements pertaining  
to Earth orientation.  I am well aware that others here (where "here"  
is a place to be understood metaphorically, see Steven Pinker),  
believe that interval timekeeping requirements are more critical, at  
least since the invention of the computer.

In the statement above I was trying to separate the two in a  
noncontroversial way.  Apparently I failed.  Let's see.  Is the  
distinction clearer if I say that an egg timer and the "clock drive"  
of a telescope have different requirements?

Anyway, to resolve the requirements for such divergent applications, I  
have been recommending that well-known system engineering techniques  
be followed.  Techniques that are eminently applicable to situations  
in which diverse entrenched positions have been taken.  On the other  
hand, Warner, for instance, has simply suggested that one or another  
party steel themselves to lose.  If we assume somebody has to lose,  
then perhaps that will become a self-fulfilling prophesy.  I don't  
assume anybody has to lose.

In any event, UTC has always provided access to interval time much  
more precisely (milliseconds or better via radio signals, microseconds  
or better via NTP) than to Earth orientation time (0.9s uncorrected,  
0.1s corrected).  At any point have I suggested that interval time  
should be degraded?

Rather, the ITU is unilaterally proposing to dramatically degrade  
access to the Earth orientation related features of clocks worldwide.   
As I believe you should know by now, I don't appreciate this and have  
been trying to argue against it.  For some reason, this appears to  
upset you.  For some reason, the subject of the discussion keeps being  
changed.

Leap seconds are simply a facet of an engineering solution.  A  
different solution could involve other engineering choices.  The ITU  
is not pursuing a different solution, they have been relentlessly  
pursuing the destruction of the current solution.  I believe they have  
taken this path because they have skipped important steps of standard  
system engineering methodology.  Central to this is a rush to  
judgement, the familiar human quality of failing to explore the  
problem space sufficiently before seizing on a specific solution.   
Perhaps there is an evolutionary argument for this human behavior -  
something about fleeing lions on the savannah.  How do you say "look  
before you leap" in Danish?

Each problem has many solutions.  If we didn't have to keep fending  
off the ITU's "deliberations", we could flesh out some high priority  
use cases (on all sides), utilize these to discover the underlying  
requirements shared by those use cases, and dispassionately consider  
alternative solutions that have the likelihood of making everybody  
happier with the ultimate consensus.

This is not only a better decision pathway, it is most assuredly a  
pathway that will be traversed much quicker than the nine years that  
the ITU has squandered.

> A modern passengerplane moves approximately 300 meters per second.   
> Are you willing to to accept a +/- 300 meter tolerance on the radar  
> track during final approach in Cat3 conditions, if you are on the  
> plane ?
>
> How much havoc do you think a one second difference makes in a  
> modern robotic car-production facility ?  Have you ever wondered why  
> the car industry is so interested in IEEE-1588 ?

These are excellent use cases.  Whether the assembly line of an  
automated factory has a strong requirement for synchronization with  
Earth orientation is unclear.  I suspect we would both deem this not  
to be the case.  I would infer that they ought to consider relying on  
something other than UTC.  (Say!  GPS is quite easily available!)  The  
implicit argument is often made on this list, rather, that UTC should  
be modified to lose its unique features.  Square pegs and round holes  
and all that.

In the case of the airplane, a better appeal to fear (http://www.nizkor.org/features/fallacies/appeal-to-fear.html 
) would feature having my child alone on the plane and needing  
emergency medical treatment, during that hurricane when the insidious  
leap second sneaks up on the pilot.

Yes, there are risks associated with every technological solution.   
System engineering provides the best tools for properly characterizing  
and mitigating these.  Since day one, the ITU has assumed that the  
wide world over there is not a single risk associated with systems  
expecting Earth orientation and receiving nadda.  Astronomers have  
pointed out several risks in our own systems.  So, of course, as a  
result we are accused of not characterizing them in other people's  
systems.

> Having to classify applications into "timing" and "civil" in the  
> first place is what brought us here.

Someday perhaps we will learn to forgive our ancestors for having the  
audacity to be born on a planet with a large moon.  See "Rare Earth:  
Why complex life is uncommon in the universe", by Peter Ward and  
Donald Brownlee (http://www.worldcat.org/oclc/57026195&ht=edition) for  
an argument regarding why it might be inevitable that all intelligent  
life (multicellular, for that matter) arises on planets with large  
moons.  The need for leap seconds (or their equivalent) may therefore  
be built-in.

I often include modifiers like "or their equivalent".  For some  
reason, this is not sufficient to impress the very real fact that I'm  
willing to entertain alternatives.  My apologies for failing to find  
the right language yet again.

Simply abandoning leap seconds is goofy.  There are many non-goofy  
options.  For instance, you and I have agreed in principle in the past  
on finding it acceptable to lengthen the leap second scheduling  
algorithm in some fashion.  What exactly is the current state of the  
art for predicting Earth orientation?  It is a shame that there are no  
lurkers here who could answer that question.

> A lot of people didn't know that their applications were "timing" so  
> they didn't add code for the leap-second-polka.

Sounds like you've discovered a significant educational requirement.

>> The key issue is the stability of the civil timescale, not its  
>> precision.  However, degrading the precision by 5 orders of  
>> magnitude in one gulp seems rather...excessive.

[Ad Hominem attack excised: http://www.nizkor.org/features/fallacies/ad-hominem.html 
]

> The earth is not going to jump 15 degrees of rotation on jan 2nd  
> 2018, so any talk about "degrading precision by 5 orders of  
> magnitude" is disinginuous and deliberately misleading.

This is another one of the 42 fallacies from http://www.nizkor.org/features/fallacies 
, but I'm tired of paging through them to find it.

The issue here is the meaning of the word precision.  As I said in  
some other recent message, "precision" isn't a simple concept in  
timekeeping.  Others here know much more about this than I do.

Whatever precision means, however, a reasonable interpretation of my  
secondary point in the informal argument above would be that if the  
controls are removed from some system that will inevitably permit  
error terms to grow to that magnitude, that it is reasonable to refer  
to it as such a magnitude.

For example, pick a bound much larger than the current 0.1s (or 0.9s),  
say 100s.  It should take us a century or so to reach that.  And yet -  
the ITU proposal could not make the claim that the new-and-degraded  
UTC will remain bounded at 100s, which is 2 or 3 (depending on how  
you're counting) orders of magnitude worse "precision" than is  
currently true.

> As has been well documented, it will take several hundred years  
> before the difference approaches an hour.

Yes, but the system isn't bounded.  One could infer that it is  
"disingenuous and deliberately misleading" of the ITU to pursue an  
agenda that is quite unsupportable over the long term.

> Second, the ITU proposal decentralizes the time-of-day vs. solar  
> position tolerance to national issue.

You assert this.  I disagree.  It is more productive to haggle over  
requirements describing the problem space in this area, than it is  
over whether a single proposed solution has such a feature.  Work  
characterizing the problem space will inform all candidate solutions  
that are later entertained.  Work to characterize a single proposed  
solution only helps in the evaluation of that solution, but also may  
fail to converge simply because the diverse stakeholders never took  
the time to find common ground for describing the problem.

> I think is very proper, considering the very different policies  
> adopted with respect to timezones (EU vs China for instance) and  
> different durations of sunrise/sunset (Van Mayen vs. Congo for  
> instance).

Again, these are good use cases to fold into the process.

>> Rather, the nine years spent ankle-biting at the ponderous  
>> machinations of the ITU could have been better spent actually  
>> discovering a full set of requirements for civil timekeeping.
>
> So Rob, why didn't you ?

Again, read the archives.  I assayed several attempts.  You have  
frequently been a noise generator (http://www.naturestapestry.com/whitenoise2.html 
) when I have done so.

As with most things, it is also a question of funding.  Long since,  
some working group associated with the ITU could have sought funding  
for an initial design phase.  It is commonplace that projects are  
funded early simply to write a proposal.  Sometimes this passes  
through several iterations.

> Ankle-biting is the best description for your disinformation  
> campaign I have seen yet.

And yet you have spent this entire message sniping at some other  
member of the mailing list when you could simply ignore that  
contributor's messages.  One might infer (rightly or wrongly) that if  
the arguments I make here were so easy to dismiss, you would have  
dismissed them (and me) long ago.

I have no authority and presumably little influence of any sort over  
the ITU.  I argue my position as best I see it with the hope that some  
of it might stick.  It concerns me that you think otherwise, but I  
choose to keep trying.

Once more from the top:

	There are two kinds of time, interval and Earth orientation.
	The ITU proposal addresses only one.

Rob

From lang at unb.ca  Mon Dec 29 11:31:44 2008
From: lang at unb.ca (Richard B. Langley)
Date: Mon, 29 Dec 2008 12:31:44 -0400
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>
References: <38318.1230537719@critter.freebsd.dk>
	<3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>
Message-ID: <1230568304.4958fb709c20b@webmail.unb.ca>

I think IERS Bulletin A might represent the current state of the art for predicting
Earth orientation. It is produced by USNO. Latest bulletin is here:
<http://www.iers.org/products/6/11769/orig/bulletina-xxi-052.txt>.
It provides a table of UT1-UTC values to the end of 2009. It also provides an estimated
function and its standard deviation that can be used to extend the table. How accurate
are the predictions (especially the long-term ones) really? One would have to compare
one of the historical empirical functions with actual UT1 data. Not sure if anyone has
done that recently. Perhaps Demetrios knows?
-- Richard Langley
P.S. For those wanting to refresh their memories on the details of the history of the
leap-second business, have a look at <http://tycho.usno.navy.mil/leapsec.html>.

Quoting Rob Seaman <seaman at noao.edu>:

> What exactly is the current state of the  
> art for predicting Earth orientation?  It is a shame that there are no  
> lurkers here who could answer that question.
===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From zefram at fysh.org  Mon Dec 29 11:52:02 2008
From: zefram at fysh.org (Zefram)
Date: Mon, 29 Dec 2008 16:52:02 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <1230568304.4958fb709c20b@webmail.unb.ca>
References: <38318.1230537719@critter.freebsd.dk>
	<3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>
	<1230568304.4958fb709c20b@webmail.unb.ca>
Message-ID: <20081229165202.GP2263@fysh.org>

Richard B. Langley wrote:
>How accurate
>are the predictions (especially the long-term ones) really?
>One would have to compare
>one of the historical empirical functions with actual UT1 data.

We discussed this in 2007-01 in a thread titled "UT1 confidence".
No firm answers were forthcoming regarding present IERS capability.

PHK noted that the accuracy estimation formula in Bulletin A gives
unbelievable results if applied to periods of decades.  We don't know
how far out that formula, or the DUT1 estimation formula, are intended
to be applied.

Steve Allen pointed at some interesting papers, of which the most relevant
was <http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf>.  This paper
looks at (retrospectively) predicting UT1-TAI two and three years ahead,
and how well those predictions match reality.  These predictions were
made with a fairly naive algorithm, which in the short term performs
much more poorly than what IERS does.  The three year predictions were
all correct to within 1.0 s.

-zefram

From imp at bsdimp.com  Mon Dec 29 12:41:16 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 29 Dec 2008 10:41:16 -0700 (MST)
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <20081229165202.GP2263@fysh.org>
References: <3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>
	<1230568304.4958fb709c20b@webmail.unb.ca>
	<20081229165202.GP2263@fysh.org>
Message-ID: <20081229.104116.-861032459.imp@bsdimp.com>

In message: <20081229165202.GP2263 at fysh.org>
            Zefram <zefram at fysh.org> writes:
: Richard B. Langley wrote:
: >How accurate
: >are the predictions (especially the long-term ones) really?
: >One would have to compare
: >one of the historical empirical functions with actual UT1 data.
: 
: We discussed this in 2007-01 in a thread titled "UT1 confidence".
: No firm answers were forthcoming regarding present IERS capability.
: 
: PHK noted that the accuracy estimation formula in Bulletin A gives
: unbelievable results if applied to periods of decades.  We don't know
: how far out that formula, or the DUT1 estimation formula, are intended
: to be applied.

Yes.  I think he said that they worked well out about 10 years, but
that we should graph the actual vs historical predictions to make
sure...

: Steve Allen pointed at some interesting papers, of which the most relevant
: was <http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf>.  This paper
: looks at (retrospectively) predicting UT1-TAI two and three years ahead,
: and how well those predictions match reality.  These predictions were
: made with a fairly naive algorithm, which in the short term performs
: much more poorly than what IERS does.  The three year predictions were
: all correct to within 1.0 s.

I'd note that Bullitin A data is available, and one could graph the
performance of different time lines vs actual over a period of the
last few years.  I was thinking of doing this data crunching myself,
but time has gotten away from me...

Warner

From sla at ucolick.org  Mon Dec 29 14:46:27 2008
From: sla at ucolick.org (Steve Allen)
Date: Mon, 29 Dec 2008 11:46:27 -0800
Subject: [LEAPSECS] rubber seconds in Japan!
Message-ID: <20081229194627.GA27010@ucolick.org>

100 of them, just before the leap

http://www.yomiuri.co.jp/dy/national/20081230TDY03104.htm

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From mgy1912 at cox.net  Mon Dec 29 15:08:02 2008
From: mgy1912 at cox.net (Brian Garrett)
Date: Mon, 29 Dec 2008 12:08:02 -0800
Subject: [LEAPSECS] CHU frequency change
Message-ID: <B3A5AA3A58754829802D29E9AACFB133@company48fcb68>

This may be old news, but anyone listening for the leap second (or using CHU as a time reference) needs to be aware that the transmission on 7335kHz is going away as of 2009-01-01.  Apparently, the leap second will be 7335's last.

They will still be broadcasting on three frequencies, but 7850 kHz will replace 7335.  If receiving the leap second broadcast over CHU is important to you or your boxen, you'll want to choolse 3335 kHz or 14670 kHz instead.

Source: http://inms-ienm.nrc-cnrc.gc.ca/time_services/shortwave_broadcasts_e.html


Happy leaping,
Brian Garrett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081229/7dfff218/attachment.htm>

From zefram at fysh.org  Mon Dec 29 15:09:04 2008
From: zefram at fysh.org (Zefram)
Date: Mon, 29 Dec 2008 20:09:04 +0000
Subject: [LEAPSECS] rubber seconds in Japan!
In-Reply-To: <20081229194627.GA27010@ucolick.org>
References: <20081229194627.GA27010@ucolick.org>
Message-ID: <20081229200904.GQ2263@fysh.org>

Steve Allen wrote:
>100 of them, just before the leap

This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
with Smoothed Leap Seconds), but over a shorter period.  One might well
suppose that if they'd heard of UTC-SLS then they'd have used it, and so
this is probably an independent invention.  Presumably they're working
with the same objective: to provide a timescale that usually matches UTC
exactly but also does not violate the fixed 60-seconds-per-minute model.

Interesting that they're only doing that for some users (those connecting
by copper, apparently).  Users connecting by fibre get a visible (well,
audible) leap.  Assumptions about the precision required by different
classes of user?

-zefram

From imp at bsdimp.com  Mon Dec 29 15:12:25 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 29 Dec 2008 13:12:25 -0700 (MST)
Subject: [LEAPSECS] rubber seconds in Japan!
In-Reply-To: <20081229200904.GQ2263@fysh.org>
References: <20081229194627.GA27010@ucolick.org>
	<20081229200904.GQ2263@fysh.org>
Message-ID: <20081229.131225.-4053691.imp@bsdimp.com>

In message: <20081229200904.GQ2263 at fysh.org>
            Zefram <zefram at fysh.org> writes:
: Steve Allen wrote:
: >100 of them, just before the leap
: 
: This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
: with Smoothed Leap Seconds), but over a shorter period.  One might well
: suppose that if they'd heard of UTC-SLS then they'd have used it, and so
: this is probably an independent invention.  Presumably they're working
: with the same objective: to provide a timescale that usually matches UTC
: exactly but also does not violate the fixed 60-seconds-per-minute model.
: 
: Interesting that they're only doing that for some users (those connecting
: by copper, apparently).  Users connecting by fibre get a visible (well,
: audible) leap.  Assumptions about the precision required by different
: classes of user?

I imagine that the fiber folks derive their clock from the fiber
carrier frequency, which can't be off by 1e-2.  The usual specs for
those start closer to 1e-12...

Warner

From phk at phk.freebsd.dk  Mon Dec 29 17:30:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 29 Dec 2008 22:30:30 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: Your message of "Mon, 29 Dec 2008 09:05:59 MST."
	<3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu> 
Message-ID: <40853.1230589830@critter.freebsd.dk>

In message <3326254A-DD7A-40E6-A014-3958344AA4E7 at noao.edu>, Rob Seaman writes:

>My apologies for the long reply.

No apologies for the short reply.

http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From tvb at LeapSecond.com  Mon Dec 29 18:01:41 2008
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Mon, 29 Dec 2008 15:01:41 -0800
Subject: [LEAPSECS] rubber seconds in Japan!
References: <20081229194627.GA27010@ucolick.org>
	<20081229200904.GQ2263@fysh.org>
Message-ID: <160D52CAF1094214B83EE1B08D02A539@pc52>

>>100 of them, just before the leap
> 
> This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
> with Smoothed Leap Seconds), but over a shorter period.  One might well
> suppose that if they'd heard of UTC-SLS then they'd have used it, and so

I think we covered this back when we debated UTS.

The idea of speeding up and slowing down ticks to handle leap
seconds (or other timing discontinuities) is not new. It is one of
several practical ways to avoid a clock reading :59:60. It's also
not unlike how a PLL works.

The problem with UTC-SLS, last I read it, was that it demanded
a smoothing factor of 1000. This rate change is unnecessarily
high for many applications and unacceptably low for others.

One can imagine perfectly workable smoothed leap second
solutions using not just 1000, but instead 100, or 1024, or 60,
or 30, or 10, or 2, or 1/2. Or if you're perverse, 86400.

In every case it is simply a trade-off between the magnitude of
frequency excursion and the duration of smoothed leaping event.
Some systems have frequency limits; others may have time limits.
There is no one solution, nor should there be. There may also be
hardware considerations. For example, if a 32 kHz-based clock
were to re-synchronize smoothly it would be more convenient to
use a binary factor like 16 or 1024 rather than a decimal factor
like 100 or 1000.

I like their centisecond solution. Do we have anyone from Japan
on the list -- it would be nice to add a recording of this event to
my leapsecond collection.

/tvb
http://www.LeapSecond.com





From jhein at timing.com  Mon Dec 29 18:25:31 2008
From: jhein at timing.com (John Hein)
Date: Mon, 29 Dec 2008 16:25:31 -0700
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <40853.1230589830@critter.freebsd.dk>
References: <3326254A-DD7A-40E6-A014-3958344AA4E7@noao.edu>
	<40853.1230589830@critter.freebsd.dk>
Message-ID: <18777.23659.674222.623096@gromit.timing.com>

Poul-Henning Kamp wrote at 22:30 +0000 on Dec 29, 2008:
 > http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

Love that site.  Steve's and Tom's sites (among others) come in handy,
but that one made me laugh.

John - lurker

From nimh at pipe.nl  Mon Dec 29 18:46:19 2008
From: nimh at pipe.nl (Nero Imhard)
Date: Tue, 30 Dec 2008 00:46:19 +0100
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <4217.1230021820@critter.freebsd.dk>
References: <4217.1230021820@critter.freebsd.dk>
Message-ID: <774B1BAC-3AA2-454E-A141-7FA77D31488B@pipe.nl>

Late reaction. Was still in my outbox. The current discussions are  
sufficiently annoying to send it anyway:

On 2008-12-23, at 09:43, Poul-Henning Kamp wrote:
>
> The rest of us have no trouble with a tolerance of up to (at least)
> one hour, because that's what is already the reality for 99.9..%
> of the population.

> I'm still looking for the "poster boy" reason for your 1sec tolerance
> claim.

You don't need such a reason. It's up to the people (ITU?) who want to  
change an existing definition to make their case. "Although we hear  
protests, we don't see any objection we deem valid" doesn't quite cut  
it, does it?

I still don't get why you are insisting that UTC could be changed. To  
get rid of leap seconds in broadcast time scales, switching to  
something like TI would buy you your solution AND will not upset  
anyone using UTC. As for civil time, it's up to *legislators* to  
decide what civil time should be. Most have chosen (a derivative of)  
UTC, quite probably because it follows UT. Overriding such a decision  
by changing the reference frame is foul play.

What keeps bothering me is that the prospect of *changing a  
definition* (of UTC) doesn't seem to make you (phk) blink at all. A  
stated property of UTC is that it follows UT to within one second, and  
changing UTC in this respect is an insult to its users. It is  
betrayal, and undermines the timescale's authority.

If leap seconds are bugging you, then change you choice of time scale.

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081230/f14768ec/attachment-0001.htm>

From dot at dotat.at  Mon Dec 29 21:07:40 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 30 Dec 2008 02:07:40 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <36594.1230505519@critter.freebsd.dk>
References: <36594.1230505519@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0812300200000.25321@hermes-1.csi.cam.ac.uk>

On Sun, 28 Dec 2008, Poul-Henning Kamp wrote:
>
> In contrast to this, nobody, including you, seem to be willing to
> even hazard a guess what level of presision is required or sufficient
> for the "earth orientation clock".

Well we obviously need to know earth orientation to quite high precision
in order for satellite navigation to work, which implies that we know UT0
to fairly high precision - the surface rotates about 1m every 2ms. However
I doubt we need this information for setting our clocks.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
ROCKALL MALIN: SOUTHEASTERLY 4 OR 5, INCREASING 5 OR 6, OCCASIONALLY 7 IN
ROCKALL. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN SOUTH ROCKALL. RAIN OR
SHOWERS. MODERATE OR GOOD.

From mgy1912 at cox.net  Mon Dec 29 21:08:49 2008
From: mgy1912 at cox.net (Brian Garrett)
Date: Mon, 29 Dec 2008 18:08:49 -0800
Subject: [LEAPSECS] And now, your moment of FAIL
Message-ID: <AE3A9AE3BFE74630BFFA243800302DB6@company48fcb68>

Let's hope your cesium clock's nine-digit display isn't showing what this banner does come Dec. 31:

http://www.nytimes.com/2008/12/28/weekinreview/28vinciguerra.html


Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20081229/6a9bd84c/attachment.htm>

From dot at dotat.at  Mon Dec 29 21:19:01 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 30 Dec 2008 02:19:01 +0000
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <78F76698-B873-42F2-9D22-E11513189793@noao.edu>
References: <36594.1230505519@critter.freebsd.dk>
	<C09A1879-2B9F-47BE-81EE-626083683FC2@noao.edu>
	<DC36F13E-99C8-4964-A928-A78A45C4BCDD@noao.edu>
	<78F76698-B873-42F2-9D22-E11513189793@noao.edu>
Message-ID: <alpine.LSU.2.00.0812300155480.25321@hermes-1.csi.cam.ac.uk>

On Sun, 28 Dec 2008, Rob Seaman wrote:
>
> And I really will spare folks my other screed on civil timekeeping
> having nothing to do with local apparent solar time.  Since everybody
> seems to agree on this point, I'm not sure why it keeps coming up.

I don't agree. I think the sun in the sky is what people actually care
about, and the astronomical details are irrelevant for practical purposes.
Civil time needs to be within a couple of hours of local solar time. The
differences between mean solar time and apparent solar time are too small
to matter - in fact the variation of sunrise matters much more than the
variation of midday.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6 IN NORTH, VEERING
NORTHERLY 6 LATER IN NORTH. MODERATE, BECOMING ROUGH AT TIMES. SHOWERS, SNOW
LATER IN NORTH. MODERATE OR GOOD, OCCASIONALLY POOR LATER IN NORTH.

From dot at dotat.at  Mon Dec 29 21:42:55 2008
From: dot at dotat.at (Tony Finch)
Date: Tue, 30 Dec 2008 02:42:55 +0000
Subject: [LEAPSECS] Calendrical Calculations
In-Reply-To: <20081228214938.GN2263@fysh.org>
References: <32641.1230451572@critter.freebsd.dk>
	<alpine.LSU.2.00.0812281951150.16108@hermes-1.csi.cam.ac.uk>
	<20081228214938.GN2263@fysh.org>
Message-ID: <alpine.LSU.2.00.0812300221190.25321@hermes-1.csi.cam.ac.uk>

On Sun, 28 Dec 2008, Zefram wrote:
>
> The numerical algorithms are correct, as far as I can see, but the
> descriptions of the underlying theory are often muddled, riddled with
> errors and critical omissions. (Count how many different quantities go
> by the name "RD".)  Rather importantly for our purposes, CC ignores the
> existence of timezones (or, for that matter, longitude).

A lot of the book is only concerned with labelling days, so it's a
legitimate simplification to ignore time of day. However they do take some
care to explain the simplification and how it relates to the way different
calendars choose different times of day to change their dates.

The rest of the book is concerned with modelling observational calendars,
and for those it does require a more detailed idea of time of day and
location, including longitude. There is also a brief discussion of time
zones, which are mostly used when converting civil time at a place to
universal time for use by the algorithms.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FITZROY SOLE: SOUTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH.
RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From phk at phk.freebsd.dk  Tue Dec 30 03:40:34 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 08:40:34 +0000
Subject: [LEAPSECS] rubber seconds in Japan!
In-Reply-To: Your message of "Mon, 29 Dec 2008 15:01:41 PST."
	<160D52CAF1094214B83EE1B08D02A539@pc52> 
Message-ID: <42633.1230626434@critter.freebsd.dk>

In message <160D52CAF1094214B83EE1B08D02A539 at pc52>, "Tom Van Baak" writes:

>The idea of speeding up and slowing down ticks to handle leap
>seconds (or other timing discontinuities) is not new. It is one of
>several practical ways to avoid a clock reading :59:60.

And arguably, no more or no less kludgy than simply replaying
a second to cover the "gap".

But there is a big difference in papering over the leap-second
with rubber seconds, and defining the leap second as rubber seconds.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 03:57:11 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 08:57:11 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 00:46:19 +0100."
	<774B1BAC-3AA2-454E-A141-7FA77D31488B@pipe.nl> 
Message-ID: <42836.1230627431@critter.freebsd.dk>

In message <774B1BAC-3AA2-454E-A141-7FA77D31488B at pipe.nl>, Nero Imhard writes:

>You don't need such a reason. It's up to the people (ITU?) who want to  
>change an existing definition to make their case. "Although we hear  
>protests, we don't see any objection we deem valid" doesn't quite cut  
>it, does it?

That's how the ITU works.

Look at how the V.90 was ratified for instance.

>I still don't get why you are insisting that UTC could be changed.

It was changed in 1958 and 1972, I see nothing preventing it from
being changed in 2008, -9, -10 or any other year.

>switching to something like TI [...]

We have millions of documents which mandate, directly or indirectly,
the usage of UTC.  Starting with legislation about local timezones
over POSIX to international treaties about transport, communication
and power-generation.

Taking leap seconds out of UTC has a clear implementation plan, it
is one document that needs changed and ratified in a UN forum and
we are done with the problem.

Changing all the other documents and teaching people about proper
choice of timescales is a proven path to failure.

>What keeps bothering me is that the prospect of *changing a  
>definition* (of UTC) doesn't seem to make you (phk) blink at all.

Not only does it not make me blink, I shake my head in wonder at
people like you, who seem to think that UTC is sacred in some
sense.

Did you also complain when the length of the meter was redefined ?
wasnt that equally an insult to the users of the meter, who
relied on it being a metal bar i Paris ?

UTC is a definition for the advancement of international communications
not one of the 10 commandments.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From zefram at fysh.org  Tue Dec 30 06:57:45 2008
From: zefram at fysh.org (Zefram)
Date: Tue, 30 Dec 2008 11:57:45 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <42836.1230627431@critter.freebsd.dk>
References: <774B1BAC-3AA2-454E-A141-7FA77D31488B@pipe.nl>
	<42836.1230627431@critter.freebsd.dk>
Message-ID: <20081230115745.GR2263@fysh.org>

Poul-Henning Kamp wrote:
>Did you also complain when the length of the meter was redefined ?
>wasnt that equally an insult to the users of the meter, who
>relied on it being a metal bar i Paris ?

Users of the metre don't rely on the form in which its definition
is expressed.  They rely on its length being consistent.  The various
redefinitions of the metre have all preserved its length, to the precision
measurable at the time.

The fact that UTC is a close approximation to UT is a visible feature on
which users can rely.  We might be able to loosen the target bound on
DUT1 a bit (though that's a tricky business), but making it completely
unbounded would be a gross violation of the concept and visible behaviour.

The kind of places you're talking about that refer to "UTC" by name,
the ones that don't really need UTC, are the same kind of places that
refer to "GMT" by name and then actually use UTC.  We've talked about
this kind of confusion quite a bit.  In non-technical discourse, "UTC",
"GMT", and "UT" are effectively synonymous and all vague.  So if TI is
defined by that name, we can expect that this pattern will continue:
"UTC", "GMT", "UT", and "TI" will (in those contexts) be effectively
synonymous, and even vaguer, covering all flavours of UT and also TI.
If, as you suggest, TI is defined but takes over the name "UTC", the
terms (in non-technical contexts) will still widen thus in meaning,
there'll just be one fewer term being used vaguely.

You can't fix this problem of incorrect nomenclature usage by changing
the meaning of one of the names.  Please don't damage the nomenclature
for those who use it successfully.

-zefram

From phk at phk.freebsd.dk  Tue Dec 30 07:11:35 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 12:11:35 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 11:57:45 GMT."
	<20081230115745.GR2263@fysh.org> 
Message-ID: <43600.1230639095@critter.freebsd.dk>

In message <20081230115745.GR2263 at fysh.org>, Zefram writes:

>The fact that UTC is a close approximation to UT is a visible feature on
>which users can rely.

The crucial question, which nobody seems to be able to give an example
of, is users who _DO_ rely on this being the case, and if any such
users do exist, what their DUT1 tolerance is.

>The kind of places you're talking about that refer to "UTC" by name,
>the ones that don't really need UTC, are the same kind of places that
>refer to "GMT" by name and then actually use UTC.

A lot of these places use UTC (or GMT) because of laws, regulations,
standards and requirement documents.

We can argue until the cows come home, if that constitutes a "valid 
need for UTC" seem from a scientific point of view, but that would
not change their legal need one iota.

>You can't fix this problem of incorrect nomenclature usage by changing
>the meaning of one of the names.

There used to be (probably still is) a regulation that mandated that
London cabs carry a bale of hay for the horses and which allowed the
driver to relive himself in the shadow of his vehicle so as to not
leave the horse unattended.

The requirement that UTC track earth rotation to within 1 second has
the same level of relevance and can be abolished with the same level
of consequences.

And as for confusion, adding yet another timescale would certainly
not lessen the confusion any.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Tue Dec 30 07:17:00 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 07:17:00 -0500
Subject: [LEAPSECS] And now, your moment of FAIL
In-Reply-To: <AE3A9AE3BFE74630BFFA243800302DB6@company48fcb68>
References: <AE3A9AE3BFE74630BFFA243800302DB6@company48fcb68>
Message-ID: <4959CAEC.11542.F5863A2@dan.tobias.name>

On 29 Dec 2008 at 18:08, Brian Garrett wrote:

> Let's hope your cesium clock's nine-digit display isn't showing what this banner does come Dec. 31:
> 
> http://www.nytimes.com/2008/12/28/weekinreview/28vinciguerra.html

If the display starts at "000" on the first day of the year, then it 
should show "365" on the last day of this year given that it is a 
leap year.  If it starts at "001", then it should have "366" then.  
The article's display of "364" would be wrong in either case.


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From dan at tobias.name  Tue Dec 30 07:20:07 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 07:20:07 -0500
Subject: [LEAPSECS] Cheating means more planning, not less
In-Reply-To: <alpine.LSU.2.00.0812300155480.25321@hermes-1.csi.cam.ac.uk>
References: <36594.1230505519@critter.freebsd.dk>,
	<78F76698-B873-42F2-9D22-E11513189793@noao.edu>,
	<alpine.LSU.2.00.0812300155480.25321@hermes-1.csi.cam.ac.uk>
Message-ID: <4959CBA7.22257.F5B3E28@dan.tobias.name>

On 30 Dec 2008 at 2:19, Tony Finch wrote:

> in fact the variation of sunrise matters much more than the
> variation of midday.

And the use of daylight saving / summer time actually brings the time 
of sunrise closer to constancy in places that use it, so in a sense 
this actually underscores the relationship of civil time to solar 
time even though in the technical sense of agreement with the time of 
midday it causes the local time to diverge further from precise solar 
mean time.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From dan at tobias.name  Tue Dec 30 07:22:05 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 07:22:05 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <42836.1230627431@critter.freebsd.dk>
References: <Your message of "Tue, 30 Dec 2008 00:46:19 +0100."
	<774B1BAC-3AA2-454E-A141-7FA77D31488B@pipe.nl> >,
	<42836.1230627431@critter.freebsd.dk>
Message-ID: <4959CC1D.6231.F5D0BD3@dan.tobias.name>

On 30 Dec 2008 at 8:57, Poul-Henning Kamp wrote:

> We have millions of documents which mandate, directly or indirectly,
> the usage of UTC.  Starting with legislation about local timezones
> over POSIX to international treaties about transport, communication
> and power-generation.

And plenty more that mandate GMT, or some other meridian-based time 
that can be calculated as an offset of GMT.  But you seem to only 
care about the documents that mandate UTC in particular, regarding 
them as sacrosanct, while the ones that mandate something else are 
merely quaint relics that can safely be ignored.


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From dan at tobias.name  Tue Dec 30 07:28:28 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 07:28:28 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230115745.GR2263@fysh.org>
References: <774B1BAC-3AA2-454E-A141-7FA77D31488B@pipe.nl>,
	<42836.1230627431@critter.freebsd.dk>,
	<20081230115745.GR2263@fysh.org>
Message-ID: <4959CD9C.9209.F62E446@dan.tobias.name>

On 30 Dec 2008 at 11:57, Zefram wrote:

> You can't fix this problem of incorrect nomenclature usage by changing
> the meaning of one of the names.  Please don't damage the nomenclature
> for those who use it successfully.

Steven Pinker (who's been cited on this list before) had an 
interesting discussion in his book "The Stuff of Thought" about 
whether a thing referred to by a word in human language preserves its 
basic nature if the underlying technical definition changes, using 
thought experiments such as an alternate world that uses the label 
"water" for a substance that isn't H2O but serves all the same 
functions water does here on Earth; or the case where people suddenly 
realize that the creatures they call "cats" are actually sentient 
aliens; would they still be cats then?  It seems like the varous 
scientific redefinitions of the second, and other units like days and 
years that are ultimately defined in terms of it, are a similar sort 
of thing.  Non-scientists will be surprised to learn that a "day" is 
no longer the length of time it takes the earth to complete a 
rotation; so, is a day still a day?  Those were the days, my friend.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From phk at phk.freebsd.dk  Tue Dec 30 07:36:53 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 12:36:53 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 07:22:05 EST."
	<4959CC1D.6231.F5D0BD3@dan.tobias.name> 
Message-ID: <43700.1230640613@critter.freebsd.dk>

In message <4959CC1D.6231.F5D0BD3 at dan.tobias.name>, "Daniel R. Tobias" writes:

>And plenty more that mandate GMT, or some other meridian-based time 
>that can be calculated as an offset of GMT.  But you seem to only 
>care about the documents that mandate UTC in particular, regarding 
>them as sacrosanct, while the ones that mandate something else are 
>merely quaint relics that can safely be ignored.

I don't ignore any in-force document, no matter what it says.

Most of the population would consider UTC a fancy way to spell GMT
and therefore, it is widely understood that outside england the
latter should be read as the former.

The most important document in this respect is POSIX btw.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 07:40:17 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 12:40:17 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 07:28:28 EST."
	<4959CD9C.9209.F62E446@dan.tobias.name> 
Message-ID: <43722.1230640817@critter.freebsd.dk>

In message <4959CD9C.9209.F62E446 at dan.tobias.name>, "Daniel R. Tobias" writes:
>On 30 Dec 2008 at 11:57, Zefram wrote:

>Steven Pinker (who's been cited on this list before) had an 
>interesting discussion in his book "The Stuff of Thought" about 
>whether a thing referred to by a word in human language preserves its 
>basic nature if the underlying technical definition changes, [...]

An interesting pursuit of the mind.

But given that "a computer" went from being a (semi-)autistic
homonuculus to a "respectable profession for a young woman" to huge
military monsters and now 'are in everything', I think we can leave
it out of this discussion :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Tue Dec 30 08:00:57 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 08:00:57 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <43700.1230640613@critter.freebsd.dk>
References: <Your message of "Tue,
	30 Dec 2008 07:22:05 EST." <4959CC1D.6231.F5D0BD3@dan.tobias.name>
	>, <43700.1230640613@critter.freebsd.dk>
Message-ID: <4959D539.9250.F80A007@dan.tobias.name>

On 30 Dec 2008 at 12:36, Poul-Henning Kamp wrote:

> The most important document in this respect is POSIX btw.

That's a kind of geek-centrism on your part to elevate a computer 
technical standard over all the millennia of legislation and cultural 
practices regarding timekeeping... I'm pretty geeky myself, but I 
still find it to be putting the cart before the horse.


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From phk at phk.freebsd.dk  Tue Dec 30 08:26:21 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 13:26:21 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 08:00:57 EST."
	<4959D539.9250.F80A007@dan.tobias.name> 
Message-ID: <43878.1230643581@critter.freebsd.dk>

In message <4959D539.9250.F80A007 at dan.tobias.name>, "Daniel R. Tobias" writes:
>On 30 Dec 2008 at 12:36, Poul-Henning Kamp wrote:
>
>> The most important document in this respect is POSIX btw.
>
>That's a kind of geek-centrism on your part to elevate a computer 
>technical standard over all the millennia of legislation and cultural 
>practices regarding timekeeping... I'm pretty geeky myself, but I 
>still find it to be putting the cart before the horse.


Yes, it is geekcentric view, and that is because it is the geeks
who have the trouble with the leap seconds, everybody else just
ignores them.

You upset the smooth running of the intertubes at your own peril...

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Tue Dec 30 08:57:18 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 08:57:18 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <43878.1230643581@critter.freebsd.dk>
References: <Your message of "Tue,
	30 Dec 2008 08:00:57 EST." <4959D539.9250.F80A007@dan.tobias.name>
	>, <43878.1230643581@critter.freebsd.dk>
Message-ID: <4959E26E.8004.FB438CD@dan.tobias.name>

On 30 Dec 2008 at 13:26, Poul-Henning Kamp wrote:

> Yes, it is geekcentric view, and that is because it is the geeks
> who have the trouble with the leap seconds, everybody else just
> ignores them.

The non-geeks ignore them because they're at too fine a level of 
granularity to matter to people who just care about longer time spans 
like minutes and hours.  But get rid of them, and the seconds will 
add up into minutes and hours eventually, and be noticeable even by 
the mythical little old lady who goes to church once a week and 
doesn't care what the clock says any other time; she might start 
complaining that when she started this weekly trip as a little girl 
it was always light enough outside to walk to church, but now 80 
years later it's too dark at this time in the winter months and she 
might trip and hurt herself (I've fallen and I can't get up!) because 
the accumulated leap seconds have added up to minutes.  The 
divergence between solar days and atomic days, and the human life 
span, are both increasing, so this will be an increasing problem.

People can get away now with using UTC even in places where the 
relevant documents say to use GMT, because the difference between the 
two is less than a second, and only geeks care about this difference; 
everybody else just accepts whatever interpretation the geeks put on 
it, so that if the geeks say "That really means UTC", they just say 
"Whatever".  This will no longer be true if the two time scales 
diverge.

You seem to be hoping for a stealth redefinition of the standard 
under the noses of people who won't care until it's too late to do 
anything about it.  This is a time-honored method of trying to get 
one's way in a dispute where there are vocal camps supporting two or 
more different positions, and no solid consensus is ever likely to 
develop, but the majority of the public doesn't care one way or the 
other; in such a situation, the status quo, whatever it may be, has a 
great advantage in that an impossible-to-achieve consensus is needed 
to ever change from it.  Thus, the way to get change in the direction 
you want is not through a straightforward above-the-board process, 
but by coming up with some sneaky way of getting your change 
indetectably incorporated into the current status quo in a way that 
nobody notices for a long time, so that when they finally do, it will 
already be a long-established position that's the current status quo 
which requires an impossible consensus to change.

That's the way to get controversial policy changes enacted on 
Wikipedia, for instance... sneak them in using seemingly innocuous 
wording so people won't realize what they mean until they're already 
established policy, skipping the whole "consensus" thing that their 
policies are supposedly based on.  But it's a lot older than that; 
the British show "Yes Minister" outlines the many ways the entrenched 
bureaucrats get things to go their way by baffling the politicians 
with bullshit... and a venerable old document, "Action Comics #1" 
(June 1938) has a crooked senator saying "There's no doubt about it! 
The bill will be passed before its full implications are realized.  
Before any remedial steps can be taken, our country will be embroiled 
with Europe!"

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From imp at bsdimp.com  Tue Dec 30 11:50:25 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 09:50:25 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <4959D539.9250.F80A007@dan.tobias.name>
References: <4959CC1D.6231.F5D0BD3@dan.tobias.name>
	<43700.1230640613@critter.freebsd.dk>
	<4959D539.9250.F80A007@dan.tobias.name>
Message-ID: <20081230.095025.514364522.imp@bsdimp.com>

In message: <4959D539.9250.F80A007 at dan.tobias.name>
            "Daniel R. Tobias" <dan at tobias.name> writes:
: On 30 Dec 2008 at 12:36, Poul-Henning Kamp wrote:
: 
: > The most important document in this respect is POSIX btw.
: 
: That's a kind of geek-centrism on your part to elevate a computer 
: technical standard over all the millennia of legislation and cultural 
: practices regarding timekeeping... I'm pretty geeky myself, but I 
: still find it to be putting the cart before the horse.

Actually, it is quite relevant, because that's where most of the cost
of implementing leap seconds comes from.

The reason to have standards is to lower costs, not to raise them.
Leap seconds raise costs and have unproven benefits (eg, a low DUT1 is
a feature, but who really cares about that feature)?

Warner

From greg.hennessy at cox.net  Tue Dec 30 11:58:49 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 11:58:49 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.095025.514364522.imp@bsdimp.com>
References: <4959CC1D.6231.F5D0BD3@dan.tobias.name>	<43700.1230640613@critter.freebsd.dk>	<4959D539.9250.F80A007@dan.tobias.name>
	<20081230.095025.514364522.imp@bsdimp.com>
Message-ID: <495A5349.9020609@cox.net>


> The reason to have standards is to lower costs, not to raise them.

Aren't standards there to help what is produced matches what is needed?

From nimh at pipe.nl  Tue Dec 30 12:14:06 2008
From: nimh at pipe.nl (Nero Imhard)
Date: Tue, 30 Dec 2008 18:14:06 +0100
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <42836.1230627431@critter.freebsd.dk>
References: <42836.1230627431@critter.freebsd.dk>
Message-ID: <EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>

On 2008-12-30, at 09:57, Poul-Henning Kamp wrote:

> In message <774B1BAC-3AA2-454E-A141-7FA77D31488B at pipe.nl>, Nero  
> Imhard writes:
>
>> "Although we hear
>> protests, we don't see any objection we deem valid" doesn't quite cut
>> it, does it?
>
> That's how the ITU works.

Is the ITU sacred in some way? Do these three letters imply that  
common sense is suddenly irrelevant?

>> I still don't get why you are insisting that UTC could be changed.
>
> It was changed in 1958 and 1972, I see nothing preventing it from
> being changed in 2008, -9, -10 or any other year.

Like the redefinition of the meter that you mention, these were not  
such fundamental changes as the one now proposed.

>> switching to something like TI [...]
>
> We have millions of documents which mandate, directly or indirectly,
> the usage of UTC.  Starting with legislation about local timezones
> over POSIX to international treaties about transport, communication
> and power-generation.

And if I understand you well, you are saying that it is reasonable to  
second-guess the motivation behind all these documents (and those we  
haven't thought of) and conclude that it is safe to change a  
fundamental property of UTC.

> Taking leap seconds out of UTC has a clear implementation plan, it
> is one document that needs changed and ratified in a UN forum and
> we are done with the problem.

Keeping civil time in line with mean solar time is the key issue that  
brought forth various schemes of rubber seconds, leap seconds, etc.  
These mechanisms testify that closely following UT has always been the  
very goal of UTC. Redefinitions of UTC that refine or reform the  
mechnism for following UT may be reasonable. Abandoning the  
relationship completely just isn't.

> Changing all the other documents and teaching people about proper
> choice of timescales is a proven path to failure.

Making a proper and deliberate choice will be quite impossible once  
the idea is accepted that time scales can be fundamentally altered in  
mid-flight.

> UTC is a definition for the advancement of international  
> communications
> not one of the 10 commandments.

If "the advancement of international communications" were the only  
goal and use of UTC, I would have no objection at all. Let the ITU  
have a ball with it! But that's just not realistically the case. UTC  
always seemed, and has been used, like something from a standards body.

--B

From phk at phk.freebsd.dk  Tue Dec 30 12:30:44 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 17:30:44 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 18:14:06 +0100."
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl> 
Message-ID: <44644.1230658244@critter.freebsd.dk>

In message <EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA at pipe.nl>, Nero Imhard writes:

>> That's how the ITU works.
>
>Is the ITU sacred in some way? Do these three letters imply that  
>common sense is suddenly irrelevant?

ITU is far from perfect, but it is what we have.

>>> I still don't get why you are insisting that UTC could be changed.
>>
>> It was changed in 1958 and 1972, I see nothing preventing it from
>> being changed in 2008, -9, -10 or any other year.
>
>Like the redefinition of the meter that you mention, these were not  
>such fundamental changes as the one now proposed.

I would argue that it is *exactly* like the meter redefinition:  We
move from using a random artifact of questionable stability to a
"pure" definition based on stable quantum-mechanical properties.

>And if I understand you well, you are saying that it is reasonable to  
>second-guess the motivation behind all these documents (and those we  
>haven't thought of) and conclude that it is safe to change a  
>fundamental property of UTC.

Having seen a fair number of these documents myself, and despite
9 years of "ankel-biting" having still not seen a single example
of a document where the absense of leap seconds would matter: yes.

>> Taking leap seconds out of UTC has a clear implementation plan, it
>> is one document that needs changed and ratified in a UN forum and
>> we are done with the problem.
>
>Keeping civil time in line with mean solar time is the key issue that  
>brought forth various schemes of rubber seconds, leap seconds, etc.  

No, keeping "scientific time" in line with mean solar time was the
issue, civil time had nothing to do with it.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 12:37:02 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 17:37:02 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 08:57:18 EST."
	<4959E26E.8004.FB438CD@dan.tobias.name> 
Message-ID: <44709.1230658622@critter.freebsd.dk>

In message <4959E26E.8004.FB438CD at dan.tobias.name>, "Daniel R. Tobias" writes:
>On 30 Dec 2008 at 13:26, Poul-Henning Kamp wrote:

>The non-geeks ignore them because they're at too fine a level of 
>granularity to matter to people who just care about longer time spans 
>like minutes and hours.  But get rid of them, and the seconds will 
>add up into minutes and hours eventually, and be noticeable even by 
>the mythical little old lady who goes to church once a week and 
>doesn't care what the clock says any other time; she might start 
>complaining that when she started this weekly trip as a little girl 
>it was always light enough outside to walk to church, but now 80 
>years later it's too dark at this time in the winter months and she 
>might trip and hurt herself (I've fallen and I can't get up!) because 
>the accumulated leap seconds have added up to minutes.  The 
>divergence between solar days and atomic days, and the human life 
>span, are both increasing, so this will be an increasing problem.

But the good thing about ITUs proposal is that she can vote for
a government that will move the civil time to fit whatever use
of daylight that country prefers.

With leap seconds, she cannot vote anywhere to prevent random
problems with computers that control her life.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Tue Dec 30 14:28:07 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 12:28:07 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <4FC8900D-67E6-44CB-AFED-79647932F553@noao.edu>
References: <43600.1230639095@critter.freebsd.dk>
	<F58517E8-68D6-44E5-9C4B-70E44274D85E@noao.edu>
	<4FC8900D-67E6-44CB-AFED-79647932F553@noao.edu>
Message-ID: <CA98D228-C36E-4E2A-838E-76F83C1435D3@noao.edu>

Fascinating.

On Dec 30, 2008, at 1:57 AM, Poul-Henning Kamp wrote:

> Changing all the other documents and teaching people about proper
> choice of timescales is a proven path to failure.

  `The aide said that guys like me were "in what we call
   the reality-based community," which he defined as people
   who "believe that solutions emerge from your judicious
   study of discernible reality.'
     - an aide to GW Bush, quoted by Ron Suskind, NYTimes

(http://en.wikipedia.org/wiki/Reality-based_community)


...and at 5:11 AM:

> We can argue until the cows come home, if that constitutes a "valid
> need for UTC" seem from a scientific point of view, but that would
> not change their legal need one iota.

The SI second is sacred because it is "scientific".  But UTC is  
profane because it is of interest only to scientists.

(http://www.youtube.com/watch?v=2IlHgbOWj4o)


...and at 5:36 AM:

> Most of the population would consider UTC a fancy way to spell GMT
> and therefore, it is widely understood that outside england the
> latter should be read as the former.

Not only is the meaning of UTC to change, but GMT is to be redefined  
as a result.

Also, it's unacceptable to use "universal" in a purely metaphorical  
sense, but it's ok that "mean" will no longer have its familiar  
definition as a measure of central tendency.


...and at 6:26 AM:

> Yes, it is geekcentric view, and that is because it is the geeks
> who have the trouble with the leap seconds, everybody else just
> ignores them.

Nobody other than geeks has a problem with leap seconds.  Geeks are  
competent to deal with what residual problems there may be.  Therefore  
leap seconds must die.


Rather than getting tangled into logical pretzels, why don't we simply  
seek a better solution than the ITU's slipshod proposal?  Though some  
might want to, we can't just redefine the problem out of existence.   
Personally, I suggest we start with a careful characterization of how  
civil timekeeping fits into the society of people, not just the  
society of geeks.

Rob


From imp at bsdimp.com  Tue Dec 30 14:57:06 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 12:57:06 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
Message-ID: <20081230.125706.-1622602191.imp@bsdimp.com>

In message: <EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA at pipe.nl>
            Nero Imhard <nimh at pipe.nl> writes:
: >> I still don't get why you are insisting that UTC could be changed.
: >
: > It was changed in 1958 and 1972, I see nothing preventing it from
: > being changed in 2008, -9, -10 or any other year.
: 
: Like the redefinition of the meter that you mention, these were not  
: such fundamental changes as the one now proposed.

Why is it a fundamental change?  Only one parameter of UTC is being
changed, and we all knew that this day was coming when the length of
the second was fixed in 1956 to be the mean second as of 1900 (well,
it turned out to be as of 1820, but I digress).

Time used to be strongly coupled to the earth.  Each day was divided
into hours minutes and seconds.  The earth used to rotate through a
fixed angle each second, because of the definition of the second as
1/86400th of a day.

However, that is no longer the case.  We now know that each day is
86400.002 seconds long.  Part of this is that the length of the second
was poorly chosen, but it really doesn't matter: the earth is slowing
down and the length of the second will continue to degrade as a
measure of the earth's rotation.

: >> switching to something like TI [...]
: >
: > We have millions of documents which mandate, directly or indirectly,
: > the usage of UTC.  Starting with legislation about local timezones
: > over POSIX to international treaties about transport, communication
: > and power-generation.
: 
: And if I understand you well, you are saying that it is reasonable to  
: second-guess the motivation behind all these documents (and those we  
: haven't thought of) and conclude that it is safe to change a  
: fundamental property of UTC.

As an expert in the time keeping field, I believe that it is.  DUT1
only matter to astronomers, satellite trackers and ocean navigators.
Since GPS has replaces almost all celestial navigation, the primary
motive for DUT1 to be kept small is now gone.

: > Taking leap seconds out of UTC has a clear implementation plan, it
: > is one document that needs changed and ratified in a UN forum and
: > we are done with the problem.
: 
: Keeping civil time in line with mean solar time is the key issue that  
: brought forth various schemes of rubber seconds, leap seconds, etc.  
: These mechanisms testify that closely following UT has always been the  
: very goal of UTC. Redefinitions of UTC that refine or reform the  
: mechnism for following UT may be reasonable. Abandoning the  
: relationship completely just isn't.

Actually, the human race has been moving away from mean solar time for
some time now.  First the timezones decoupled man from local solar
mean to a mean time around an arbitrary meridian.  Next, daylight
savings time has shown that we can shift that about by an hour and
people cope.  Finally, now that we can measure the second more
accurately, we can see the slow drift.

Put another way, who would care if clocks were 34s ahead of where they
are today.

: > Changing all the other documents and teaching people about proper
: > choice of timescales is a proven path to failure.
: 
: Making a proper and deliberate choice will be quite impossible once  
: the idea is accepted that time scales can be fundamentally altered in  
: mid-flight.
: 
: > UTC is a definition for the advancement of international  
: > communications
: > not one of the 10 commandments.
: 
: If "the advancement of international communications" were the only  
: goal and use of UTC, I would have no objection at all. Let the ITU  
: have a ball with it! But that's just not realistically the case. UTC  
: always seemed, and has been used, like something from a standards body.

So what's so important about having small DUT1 anyway?

Warner

From phk at phk.freebsd.dk  Tue Dec 30 15:25:36 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 20:25:36 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 12:28:07 MST."
	<CA98D228-C36E-4E2A-838E-76F83C1435D3@noao.edu> 
Message-ID: <45259.1230668736@critter.freebsd.dk>

In message <CA98D228-C36E-4E2A-838E-76F83C1435D3 at noao.edu>, Rob Seaman writes:

>Nobody other than geeks has a problem with leap seconds.  Geeks are  
>competent to deal with what residual problems there may be.  Therefore  
>leap seconds must die.

We in the "realitybased community" know this to be not true.

>Rather than getting tangled into logical pretzels, why don't we simply  
>seek a better solution than the ITU's slipshod proposal?

Because ITU's proposal is fine for our needs, only too bad the implementation
will be delayed a decade relative to the initial proposal.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From blb8 at po.cwru.edu  Tue Dec 30 15:41:31 2008
From: blb8 at po.cwru.edu (blb8 at po.cwru.edu)
Date: Tue, 30 Dec 2008 12:41:31 -0800 (PST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <43600.1230639095@critter.freebsd.dk>
References: <43600.1230639095@critter.freebsd.dk>
Message-ID: <Pine.BSO.4.58.0812301235420.19777@www.blarfy.net>

> Date: Tue, 30 Dec 2008 12:11:35 +0000
> From: Poul-Henning Kamp <phk at phk.freebsd.dk>

Greetings one and all.  I didn't know this list existed until recently, have been reading the archives, and probably have little substantive to add.  It is interesting to note that the arguments have changed little over the years (as far as I can tell from the archives).

> In message <20081230115745.GR2263 at fysh.org>, Zefram writes:
> 
> >The fact that UTC is a close approximation to UT is a visible feature on
> >which users can rely.
> 
> The crucial question, which nobody seems to be able to give an example
> of, is users who _DO_ rely on this being the case, and if any such
> users do exist, what their DUT1 tolerance is.

I thought astronomy was the first easy example of this.  If we have any IT concerns about functioning backup systems, then I would think the importance of something useable in the absence of a GPS signal would be important too.

> >The kind of places you're talking about that refer to "UTC" by name,
> >the ones that don't really need UTC, are the same kind of places that
> >refer to "GMT" by name and then actually use UTC.
> 
> A lot of these places use UTC (or GMT) because of laws, regulations,
> standards and requirement documents.
> 
> We can argue until the cows come home, if that constitutes a "valid 
> need for UTC" seem from a scientific point of view, but that would
> not change their legal need one iota.

I certainly have no data to dispute Poul-Henning here regarding how ATC functions and the like, but one question that I haven't seen answered:  Why do they use UTC is this problem is known?  As I understand it, we're talking about something that is internationally controlled, meaning that the ATC system, for example, _chose_ to use UTC, with the knowledge that it had leap seconds.  They same can be said for all of these laws and regulations.  They chose to use something with leap seconds.  Am I completely wrong here?

It seems strange to me that a locality could embrace something via its laws and then complain for failure to read the documentation.  I think that's some measure of embrace and destroy.



Brian Blackmore
blb8 at po.cwru.edu
http://home.cwru.edu/~blb8
PGP keys not at http://cheese.cwru.edu/PGP/PGP.html
(ask me for them)

From phk at phk.freebsd.dk  Tue Dec 30 15:49:37 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 20:49:37 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 12:41:31 PST."
	<Pine.BSO.4.58.0812301235420.19777@www.blarfy.net> 
Message-ID: <45404.1230670177@critter.freebsd.dk>

In message <Pine.BSO.4.58.0812301235420.19777 at www.blarfy.net>, blb8 at po.cwru.edu
 writes:

>I certainly have no data to dispute Poul-Henning here regarding
>how ATC functions and the like, but one question that I haven't
>seen answered:  Why do they use UTC is this problem is known? 

Really quick counter-question:

What else would they have used ?

Slightly longer answer:

They, like everybody else, were sold the idea that UTC was the
international agreed master timescale, so of course they used it.

And today like every other major distributed computer network, they
get caught by this random "gottcha" like everybody else.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From nimh at pipe.nl  Tue Dec 30 17:41:11 2008
From: nimh at pipe.nl (Nero Imhard)
Date: Tue, 30 Dec 2008 23:41:11 +0100
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.125706.-1622602191.imp@bsdimp.com>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
Message-ID: <59376122-0FF2-4EDE-9618-3700BD51CD3E@pipe.nl>

On 2008-12-30, at 20:57, M. Warner Losh wrote:

> Why is it a fundamental change?

Because the coupling between UTC and UT is abandoned.

> Only one parameter of UTC is being
> changed, and we all knew that this day was coming when the length of
> the second was fixed in 1956 to be the mean second as of 1900 (well,
> it turned out to be as of 1820, but I digress).

Of course. And that's why we have a time scale (actually several) that  
counts SI seconds, and one that follows UT. The latter is a  
compromise. It counts SI seconds and sometimes seconds have to be  
inserted (or skipped) to keep it in sync. Kind of kludgy, but the best  
solution we have come up with so far. Better solutions would be  
welcomed.

> Time used to be strongly coupled to the earth.  Each day was divided
> into hours minutes and seconds.  The earth used to rotate through a
> fixed angle each second, because of the definition of the second as
> 1/86400th of a day.
>
> However, that is no longer the case.  We now know that each day is
> 86400.002 seconds long.  Part of this is that the length of the second
> was poorly chosen, but it really doesn't matter: the earth is slowing
> down and the length of the second will continue to degrade as a
> measure of the earth's rotation.

It hurts that bad huh? Well, there may be ample reason to base telco  
or geek time on something else than UTC. Fine. What about TAI? I mean,  
it's a familiar and established time scale, and has just the  
properties the ITU seems to be after. Really, why not TAI?

> As an expert in the time keeping field, I believe that it is.  DUT1
> only matter to astronomers, satellite trackers and ocean navigators.
> Since GPS has replaces almost all celestial navigation, the primary
> motive for DUT1 to be kept small is now gone.

How big can DUT1 become then? Would it be reasonable to wish for the  
upper bound to stay below the accuracy of a sundial? What does the ITU  
proposal say about the new limit of DUT1? I haven't seen any mention  
of it (but I do tend to overlook things).

> Put another way, who would care if clocks were 34s ahead of where they
> are today.

Probably nobody. Although it would definitely require an adjustment to  
a Bernhardt-type sundial. I'm not sure about the interval over which  
these sundials (which last eternally) can safely be adjusted (if at  
all). Proper adjustment would require a rotating scale, which they  
don't have.

> So what's so important about having small DUT1 anyway?

Hell, I don't know. It's just that UTC is the time scale that promised  
it in the first place.

N

From phk at phk.freebsd.dk  Tue Dec 30 18:02:15 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 30 Dec 2008 23:02:15 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 23:41:11 +0100."
	<59376122-0FF2-4EDE-9618-3700BD51CD3E@pipe.nl> 
Message-ID: <45973.1230678135@critter.freebsd.dk>


>It hurts that bad huh? Well, there may be ample reason to base telco  
>or geek time on something else than UTC. Fine. What about TAI? I mean,  
>it's a familiar and established time scale, and has just the  
>properties the ITU seems to be after. Really, why not TAI?

Because the time-lords get a rather fetching crimson face-color
whenever somebody proposes that ?

TAI is only a paperclock and I gather the time-lords are afraid to
loose control of it or something.

>How big can DUT1 become then? Would it be reasonable to wish for the  
>upper bound to stay below the accuracy of a sundial? 

DUT1 is unlimited.

Sundials run on local civil time, not on UTC.

>What does the ITU proposal say about the new limit of DUT1?

It does not mention a limit, as there will be none.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Tue Dec 30 18:41:09 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 18:41:09 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <45973.1230678135@critter.freebsd.dk>
References: <Your message of "Tue, 30 Dec 2008 23:41:11 +0100."
	<59376122-0FF2-4EDE-9618-3700BD51CD3E@pipe.nl> >,
	<45973.1230678135@critter.freebsd.dk>
Message-ID: <495A6B45.19314.11CAC963@dan.tobias.name>

On 30 Dec 2008 at 23:02, Poul-Henning Kamp wrote:

> Sundials run on local civil time, not on UTC.

And, in most jurisdictions, local civil time is an offset of UTC.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From dan at tobias.name  Tue Dec 30 18:45:08 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 18:45:08 -0500
Subject: [LEAPSECS] Schedule for success
Message-ID: <495A6C34.26550.11CE6F05@dan.tobias.name>

On 30 Dec 2008 at 9:50, M. Warner Losh wrote:

> The reason to have standards is to lower costs, not to raise them.
> Leap seconds raise costs and have unproven benefits (eg, a low DUT1
> is a feature, but who really cares about that feature)? 

And, if the standards were enacted after 1972, whoever promulgated 
them knew, or should have known, that the UTC standard on which they 
were basing their standards was one which included leap seconds.  If 
this fact was unacceptable to the cost-effectiveness of the proposed 
standard, they should have chosen a different time scale as their 
basis, as in fact GPS did when they chose to create a new time scale 
themselves.

It's the height of arrogance to expect the rest of the world to 
change how it does things to suit some technical standard makers who 
made a bad choice years ago that they don't want to continue living 
with.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From phk at phk.freebsd.dk  Tue Dec 30 19:12:26 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 00:12:26 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 18:45:08 EST."
	<495A6C34.26550.11CE6F05@dan.tobias.name> 
Message-ID: <46273.1230682346@critter.freebsd.dk>


I have repeatedly made the assertion that the finer points of
timekeeping escapes the average engineer or programmer and that
leap-seconds are a fine point to be avoided for that reason.


NASA has released a brand new report about Crew survival in Columbias
disintegration:  http://www.nasa.gov/news/reports/index.html


Page XVII, the glossary has an entry

		GMT Greenwich Mean Time

But it has no entry for UTC, UT1 any other UT (or leap seconds).


Throughout the report, GMT is used for time reference.

For instance: page 2-12 has the following figure label:

	Figure 2.1-13. Entry simulation snapshot sequence. Times
	are in Greenwich Mean Time.


Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Tue Dec 30 19:19:47 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 30 Dec 2008 19:19:47 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46273.1230682346@critter.freebsd.dk>
References: <Your message of "Tue, 30 Dec 2008 18:45:08 EST."
	<495A6C34.26550.11CE6F05@dan.tobias.name> >,
	<46273.1230682346@critter.freebsd.dk>
Message-ID: <495A7453.29508.11EE2652@dan.tobias.name>

On 31 Dec 2008 at 0:12, Poul-Henning Kamp wrote:

> Page XVII, the glossary has an entry
> 
> 		GMT Greenwich Mean Time
> 
> But it has no entry for UTC, UT1 any other UT (or leap seconds).

So the solution is to cause the civil-time standard to have no 
resemblance to actual GMT, so that when the ignorant masses continue 
to mistakenly call it GMT they'll be even more wrong than they now 
are?


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From seaman at noao.edu  Tue Dec 30 19:25:41 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 17:25:41 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <9E002901-EB52-4E75-B140-8CC63CBC65E5@noao.edu>
References: <45259.1230668736@critter.freebsd.dk>
	<57BBDC56-5810-4D1F-A38C-B2124F968401@noao.edu>
	<9E002901-EB52-4E75-B140-8CC63CBC65E5@noao.edu>
Message-ID: <C8FFBFC7-D9B8-4DB4-8F07-A69A6BAC6B54@noao.edu>

On Dec 30, 2008, at 1:25 PM, Poul-Henning Kamp wrote:

> Rob Seaman writes:
>
>> Nobody other than geeks has a problem with leap seconds.  Geeks are
>> competent to deal with what residual problems there may be.   
>> Therefore
>> leap seconds must die.
>
> We in the "realitybased community" know this to be not true.

Um.  It's the rest of us (whatever our positions) who are reality  
based.  You are in the other category.  The quote continues:

"That's not the way the world really works anymore," he continued.  
"We're an empire now, and when we act, we create our own reality. And  
while you're studying that reality?judiciously, as you will?we'll act  
again, creating other new realities, which you can study too, and  
that's how things will sort out. We're history's actors?and you, all  
of you, will be left to just study what we do."

The assertion has almost literally been that the Earth and Moon, Sun  
and stars bow down before the mighty ITU.

Some of us are skeptical.  (Google "Ozymandias".)

The ITU proposal is insufficient - as a concept and as a document.   
For those who may like the concept, the best way to sell it is to  
improve the document.  If this were a NASA or NSF proposal, the  
referees would reject it as incomplete.

Others might have additional suggestions for improvement, but I would  
like to see 1) a convincing explanation of why the Torino consensus  
was rejected, 2) an improved mechanism for conveying DUT1 (since the  
proposal makes the need much more critical), rather than  
decommissioning the mechanism we have now, and 3) a clear analysis of  
how the inevitable intercalary corrections will be handled.

(Maybe some of this text already exist as internal work products of  
the WP7A, USNO, BIPM, IERS or other organization?)

In particular, those who like the entertainment value of the  
perpetually circulating carousel of timezones would be well advised to  
document how this might work in practice.  This could be a tool to  
help convince the holdouts in the working party to change their votes  
in your direction.

It is to the ITU's benefit to demonstrate a little humility.  Would a  
coherent analysis of how the proposal mitigates risks hurt so much to  
generate?  After all, the announced motivation for making a change is  
that leap seconds are risky.  Document how they are risky and how  
their absence is not.  If you think a paragraph is sufficient to the  
task, then just add it under the heading "Risks mitigated by this  
proposal".  No proposal avoids issues simply by failing to note them.   
On the other hand, if an issue is truly trivial, it should be trivial  
to discuss it.

I will still dislike the concept, but why do you care so much about  
that?  I'm not a member of WP7A.

Rob



From phk at phk.freebsd.dk  Tue Dec 30 19:28:43 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 00:28:43 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 19:19:47 EST."
	<495A7453.29508.11EE2652@dan.tobias.name> 
Message-ID: <46318.1230683323@critter.freebsd.dk>

In message <495A7453.29508.11EE2652 at dan.tobias.name>, "Daniel R. Tobias" writes
:
>On 31 Dec 2008 at 0:12, Poul-Henning Kamp wrote:

>> Page XVII, the glossary has an entry
>> 
>> 		GMT Greenwich Mean Time
>> 
>> But it has no entry for UTC, UT1 any other UT (or leap seconds).
>
>So the solution is to cause the civil-time standard to have no 
>resemblance to actual GMT, so that when the ignorant masses continue 
>to mistakenly call it GMT they'll be even more wrong than they now 
>are?

I don't think you are entirely up to speed here.

What would NASA have done, had the British Parliament done something
silly to GMT in the middle of the shuttle landing ?

(You *do* know that GMT is a local British Timescale, right ?)


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 19:32:00 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 00:32:00 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 17:25:41 MST."
	<C8FFBFC7-D9B8-4DB4-8F07-A69A6BAC6B54@noao.edu> 
Message-ID: <46350.1230683520@critter.freebsd.dk>

In message <C8FFBFC7-D9B8-4DB4-8F07-A69A6BAC6B54 at noao.edu>, Rob Seaman writes:
>On Dec 30, 2008, at 1:25 PM, Poul-Henning Kamp wrote:
>
>> Rob Seaman writes:
>>
>>> Nobody other than geeks has a problem with leap seconds.  Geeks are
>>> competent to deal with what residual problems there may be.   
>
>>> Therefore
>>> leap seconds must die.
>>
>> We in the "realitybased community" know this to be not true.
>
>Um.  It's the rest of us (whatever our positions) who are reality  
>based.  You are in the other category.

	"There are 10 kinds of people, those who understand binary
	and those who dont"

With NASA just having made the above point for me, do you conceede it ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From greg.hennessy at cox.net  Tue Dec 30 19:53:40 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 19:53:40 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46318.1230683323@critter.freebsd.dk>
References: <46318.1230683323@critter.freebsd.dk>
Message-ID: <495AC294.8020809@cox.net>


> What would NASA have done, had the British Parliament done something
> silly to GMT in the middle of the shuttle landing ?

Nothing, since they use UTC, even though many people incorrectly call it GMT.


From imp at bsdimp.com  Tue Dec 30 19:57:27 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 17:57:27 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495A7453.29508.11EE2652@dan.tobias.name>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>
	<46273.1230682346@critter.freebsd.dk>
	<495A7453.29508.11EE2652@dan.tobias.name>
Message-ID: <20081230.175727.1306326652.imp@bsdimp.com>

In message: <495A7453.29508.11EE2652 at dan.tobias.name>
            "Daniel R. Tobias" <dan at tobias.name> writes:
: On 31 Dec 2008 at 0:12, Poul-Henning Kamp wrote:
: 
: > Page XVII, the glossary has an entry
: > 
: > 		GMT Greenwich Mean Time
: > 
: > But it has no entry for UTC, UT1 any other UT (or leap seconds).
: 
: So the solution is to cause the civil-time standard to have no 
: resemblance to actual GMT, so that when the ignorant masses continue 
: to mistakenly call it GMT they'll be even more wrong than they now 
: are?

I think you may have missed a subtle aspect of phk's point.

If rocket-scientists can't get the relatively simple nomenclature of
this topic right, what hope is there for the average engineer?

Warner

From greg.hennessy at cox.net  Tue Dec 30 20:24:24 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 20:24:24 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.175727.1306326652.imp@bsdimp.com>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>	<46273.1230682346@critter.freebsd.dk>	<495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
Message-ID: <495AC9C8.9010601@cox.net>


> If rocket-scientists can't get the relatively simple nomenclature of
> this topic right, what hope is there for the average engineer?

Point 1 would be we don't know if that report was written by "rocket-scientists" 
or some technical writer, but that's an important point.

Point 2 is that while as an astronomer I can say that GMT *should* be referring
to UT1, in practice it is UTC. I have no idea what the legal codes of
England say it is, nor do I particularly care. Thus I'm not going
to concede they got the nomenclature of the topic incorrect.

If you wish to make an argument that they did get it incorrect, please
do so.


From sla at ucolick.org  Tue Dec 30 20:24:33 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 30 Dec 2008 17:24:33 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.175727.1306326652.imp@bsdimp.com>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>
	<46273.1230682346@critter.freebsd.dk>
	<495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
Message-ID: <20081231012433.GA14690@ucolick.org>

On Tue 2008-12-30T17:57:27 -0700, M. Warner Losh hath writ:
> If rocket-scientists can't get the relatively simple nomenclature of
> this topic right, what hope is there for the average engineer?

Not enough in the current scenario, given that the ITU-R docs are
proprietary to the point of inaccessability and the IERS is not well
designed to communicate it's own structure let alone the operations of
its individual bureaus nor how the division of responsibility was
decided.

Note the currently-available IERS document about leap seconds
ftp://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE
which still mentions the standard as CCIR Rec. 460-4 from 1986.
That is from when the BIH and IPMS still existed -- for IPMS see
http://adsabs.harvard.edu/abs/2000ASPC..208..147Y
before the BIH timing duties were transferred to the BIPM, and the
rest of the BIH duties combined with IPMS to become IERS.

The name UTC itself originates from internal use by the international
timing bureaus, not from the CCIR.  The first publication using
UTC was from the BIH in 1964, and until 1970 the CCIR only
referred to UT2, not UTC.
And all of this is from before the CCIR reorganized into ITU-R.

In short, much of the dysfunctionality of the current scenario is a
result of NOBODY being in charge of UTC.  To say that the ITU-R is
actually the owner of UTC is somewhat of a fiction, both in history
and current practice.

I see the news coverage for this leap second as far, far better than
the stories from 2005.  If nothing else, this ITU-R WP7A process has
done a tremendous amount of education.  Yes, people continue to use
old terminology like GMT, but now they are much more aware many of
those uses are a matter of tradition.

I think that education does work, and that things can get better.
I prefer hope over despair and denial.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Tue Dec 30 20:32:35 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 01:32:35 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 19:53:40 EST."
	<495AC294.8020809@cox.net> 
Message-ID: <46683.1230687155@critter.freebsd.dk>

In message <495AC294.8020809 at cox.net>, Greg Hennessy writes:
>
>> What would NASA have done, had the British Parliament done something
>> silly to GMT in the middle of the shuttle landing ?
>
>Nothing, since they use UTC, even though many people incorrectly call it GMT.


But which "many people" are we talking about here ?

It makes a big difference is it is "Joe the Plumber" or "John der Rocket
Scientist", doesn't it ?


Lets not jump to conclusions, lets (for once) take Robs advice and
do this systematically: 

Why is the report using GMT ?


A) Not everybody at NASA got the memo, and even some rocket scientists
   don't know or care about the difference between UTC and GMT.


B) It was translated from UTC to GMT in editing, because somebody
   along the way assumed that the readers would not understand UTC ?


C) Ditto, but some style manual mandated it.


Given that you get 1840 hits in google if you search for

	utc gmt site:nasa.gov

I find theory C entirely unpersuasive: NASA is clearly not afraid
to lecture the public about the difference between UTC and GMT.

If, for the argument, we assume theory A to be false, then it follows
that whichever editor or secretary did the vandalism in theory B,
(or for that matter: C) would have gotten a scolding lecture by one
of the involved rocket scientist, who would have insisted that the
change to GMT be backed out immediately.

Obviously, this did not happen, and it follows that whoever changed
it from UTC to GMT did not get a lecture by a rocket scientist.

QED: rocket scientists are not educated well enough to, or can not
be bothered to, react when they see a national british timescale
used instead of a the proper UTC timescale.


Now, do you belive me when I say that 99+% of all programmers
wouldn't get a leap-second right if they even knew what it was ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 20:33:45 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 01:33:45 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 20:24:24 EST."
	<495AC9C8.9010601@cox.net> 
Message-ID: <46725.1230687225@critter.freebsd.dk>

In message <495AC9C8.9010601 at cox.net>, Greg Hennessy writes:

>If you wish to make an argument that they did get it incorrect, please
>do so.

GMT is a timescale owned and defined by the British Parliament.

I rest my case.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Tue Dec 30 20:42:46 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 01:42:46 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 17:24:33 PST."
	<20081231012433.GA14690@ucolick.org> 
Message-ID: <46756.1230687766@critter.freebsd.dk>

In message <20081231012433.GA14690 at ucolick.org>, Steve Allen writes:
>On Tue 2008-12-30T17:57:27 -0700, M. Warner Losh hath writ:
>> If rocket-scientists can't get the relatively simple nomenclature of
>> this topic right, what hope is there for the average engineer?
>
>Not enough in the current scenario, given that the ITU-R docs are
>proprietary to the point of inaccessability [...]

We're clawing for straws now, aren't we ?  :-)


http://science.nasa.gov/realtime/rocket_sci/clocks/time-gmt.html

States:

	Greenwich Mean Time (GMT) became a time standard in the
	19th century for British maritime navigation.   [...]. In
	1970 the Coordinated Universal Time (UTC) system was devised
	by an international advisory group of technical experts
	within the International Telecommunication Union (ITU).

Notice the little tidbit in the grey box:

	Actually, GMT is measured from noon whereas UTC is measured
	from midnight.  However, few use the noon measurement and
	refer to GMT as if it were actually UTC.

Given that GMT traditionally is a 12h clock, I wonder if that is still
the case...

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From imp at bsdimp.com  Tue Dec 30 21:01:00 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 19:01:00 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495AC9C8.9010601@cox.net>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<495AC9C8.9010601@cox.net>
Message-ID: <20081230.190100.-1916658631.imp@bsdimp.com>

In message: <495AC9C8.9010601 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: If you wish to make an argument that they did get it incorrect, please
: do so.

GMT is officially deprecated as the term for what is now UTC.  To
continue to use the old terminology over three and a half decades
after it was deprecated is a mistake.

See for example:

http://tf.nist.gov/timefreq/general/enc-g.htm

>> Greenwich Mean Time (GMT)

>> A 24-hour time keeping system whose hours, minutes, and seconds
>> represent the time-of-day at the Earth's prime meridian (0?
>> longitude) located near Greenwich, England. Technically speaking,
>> GMT no longer exists, since it was replaced by other astronomical
>> time scales many years ago, and those astronomical times scales
>> were subsequently replaced by the atomic time scale UTC. However,
>> the term GMT is still incorrectly used by the general public. When
>> heard today, it should be considered as a synonym for UTC.

Clearly, NIST believe that the use of the term GMT is incorrect and
they provide the 'common mistake' translation to UTC.

They got it wrong.  Just because it is a common mistake makes it no
less incorrect.

Warner

From imp at bsdimp.com  Tue Dec 30 21:12:19 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 19:12:19 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46756.1230687766@critter.freebsd.dk>
References: <20081231012433.GA14690@ucolick.org>
	<46756.1230687766@critter.freebsd.dk>
Message-ID: <20081230.191219.-532680072.imp@bsdimp.com>

In message: <46756.1230687766 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <20081231012433.GA14690 at ucolick.org>, Steve Allen writes:
: >On Tue 2008-12-30T17:57:27 -0700, M. Warner Losh hath writ:
: >> If rocket-scientists can't get the relatively simple nomenclature of
: >> this topic right, what hope is there for the average engineer?
: >
: >Not enough in the current scenario, given that the ITU-R docs are
: >proprietary to the point of inaccessability [...]
: 
: We're clawing for straws now, aren't we ?  :-)
: 
: 
: http://science.nasa.gov/realtime/rocket_sci/clocks/time-gmt.html

But the MET link from this page
(http://science.nasa.gov/realtime/rocket_sci/clocks/time-met.html)
says:

"There are MET clocks on board; the other on-board clock is the GMT
clock."

So it appears the confusion might be pervasive...

Warner


From sla at ucolick.org  Tue Dec 30 21:22:13 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 30 Dec 2008 18:22:13 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.190100.-1916658631.imp@bsdimp.com>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<495AC9C8.9010601@cox.net>
	<20081230.190100.-1916658631.imp@bsdimp.com>
Message-ID: <20081231022213.GA14795@ucolick.org>

On Tue 2008-12-30T19:01:00 -0700, M. Warner Losh hath writ:
> See for example:
>
> http://tf.nist.gov/timefreq/general/enc-g.htm

The NIST web pages also make the wikipedia-cited claim that the ITU
chose the apellation "UTC".

http://tf.nist.gov/general/misc.htm#Anchor-14550

I can find no evidence to support this, and much evidence to refute
it.  Perhaps the evidence is buried in one of the private documents
shelved in Geneva, but I find those NIST statements to be about as
accurate as the NIST press release this month which indicates that
their less-stable-than-quartz-crystal ammonia molecule clock was the
first atomic clock.

In order to find the truth in all this mess it's first necessary to
strip away a lot of self-serving pride.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Tue Dec 30 21:31:57 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 19:31:57 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.175727.1306326652.imp@bsdimp.com>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>
	<46273.1230682346@critter.freebsd.dk>
	<495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
Message-ID: <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>

M. Warner Losh wrote:

> I think you may have missed a subtle aspect of phk's point.
>
> If rocket-scientists can't get the relatively simple nomenclature of
> this topic right, what hope is there for the average engineer?

And the non-subtle aspect is that since everybody uses the terms GMT  
and UTC interchangeably, changing UTC will change GMT.  But GMT has a  
clear definition tied to - Hush my mouth! - the position of the mean  
sun in the sky.  It's anybody's guess how this divertissement will  
play out.

BTW, it is unsurprising that people use UTC and GMT interchangeably,  
since the original CCIR standard said:

	"GMT may be regarded as the general equivalent of UT."

This equivalence predates the ITU, and may well outlive the ITU.

Rob

(Engineers are quite good, actually, at following clear instructions.   
It has been the ITU's clear responsibility to provide those  
instructions.)


From sla at ucolick.org  Tue Dec 30 21:33:33 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 30 Dec 2008 18:33:33 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.191219.-532680072.imp@bsdimp.com>
References: <20081231012433.GA14690@ucolick.org>
	<46756.1230687766@critter.freebsd.dk>
	<20081230.191219.-532680072.imp@bsdimp.com>
Message-ID: <20081231023333.GB14795@ucolick.org>

On Tue 2008-12-30T19:12:19 -0700, M. Warner Losh hath writ:
> But the MET link from this page
> (http://science.nasa.gov/realtime/rocket_sci/clocks/time-met.html)
> says:
>
> "There are MET clocks on board; the other on-board clock is the GMT
> clock."
>
> So it appears the confusion might be pervasive...

It gets worse.  JPL would have us believe that UTC (a coordinate time
scale which is defined only on the surface of the earth and which gets
really wobbly with respect to proper time even out as close as GEO
orbit) can be propagated linearly around the solar system such that it
is defined at Jupiter and Saturn

http://www2.jpl.nasa.gov/basics/bsf2-3.html

This is enough to send a special relativist running away screaming,
let alone a general relativist.

But this sort of discussion is not aimed in the direction of helping
make the choice of whether or not the broadcast time scale keeps
leaping, nor whether the broadcast time scale keeps the name UTC if it
stops leaping.

Yes, there's a lot of misinformation out there -- more than enough to
call into question whether and how there can actually be anything like
international agreement on what time it is.  But tearing down is not
useful, the overall state of knowledge can and does get better, and
as a technological society we do *have to agree* on what time it is.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Tue Dec 30 21:38:59 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 19:38:59 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46725.1230687225@critter.freebsd.dk>
References: <46725.1230687225@critter.freebsd.dk>
Message-ID: <91B3DDF4-BEA1-4A59-BA9B-66FA02FDF1BA@noao.edu>

Poul-Henning Kamp wrote:

> I rest my case.

Finally!  Time for the defense to present its case.

I honestly thought we were still in voir dire.


From imp at bsdimp.com  Tue Dec 30 21:46:08 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 19:46:08 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
Message-ID: <20081230.194608.1172766174.imp@bsdimp.com>

In message: <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: BTW, it is unsurprising that people use UTC and GMT interchangeably,  
: since the original CCIR standard said:
: 
: 	"GMT may be regarded as the general equivalent of UT."
: 
: This equivalence predates the ITU, and may well outlive the ITU.

But UT and UTC aren't the same thing...  So this confusion is between
what we call UT1 and UTC, which differ by hundreds of milliseconds
most of the time...

Warner

From greg.hennessy at cox.net  Tue Dec 30 22:41:28 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 22:41:28 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46683.1230687155@critter.freebsd.dk>
References: <46683.1230687155@critter.freebsd.dk>
Message-ID: <495AE9E8.7000608@cox.net>


>> Nothing, since they use UTC, even though many people incorrectly call it GMT.
> 
> But which "many people" are we talking about here ?

Doesn't matter in my view.

> Why is the report using GMT ?

Probably because it is a more recognizable term than UTC.


> I find theory C entirely unpersuasive: NASA is clearly not afraid
> to lecture the public about the difference between UTC and GMT.

I find your logic unpersuasive.

> If, for the argument, we assume theory A to be false, then it follows
> that whichever editor or secretary did the vandalism in theory B,
> (or for that matter: C) would have gotten a scolding lecture by one
> of the involved rocket scientist, who would have insisted that the
> change to GMT be backed out immediately.

If you think that a scientist can change the contents of a report after
the policitaly appointed staff at NASA has edited it, you don't understand
how NASA works.


> QED: rocket scientists are not educated well enough to, or can not
> be bothered to, react when they see a national british timescale
> used instead of a the proper UTC timescale.

False conclusion due to faulty logic.

> Now, do you belive me when I say that 99+% of all programmers
> wouldn't get a leap-second right if they even knew what it was ?

Then my advice is to work on getting better programmers rather
than messing with leap seconds.

1

From greg.hennessy at cox.net  Tue Dec 30 22:42:46 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 22:42:46 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46725.1230687225@critter.freebsd.dk>
References: <46725.1230687225@critter.freebsd.dk>
Message-ID: <495AEA36.7080608@cox.net>



Poul-Henning Kamp wrote:
> In message <495AC9C8.9010601 at cox.net>, Greg Hennessy writes:
> 
>> If you wish to make an argument that they did get it incorrect, please
>> do so.
> 
> GMT is a timescale owned and defined by the British Parliament.
> 
> I rest my case.

Excuse me, I don't see a case.

You seem to be asserting that the use of GMT is an
error. What is the error that you see?



From greg.hennessy at cox.net  Tue Dec 30 22:47:34 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Tue, 30 Dec 2008 22:47:34 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.190100.-1916658631.imp@bsdimp.com>
References: <495A7453.29508.11EE2652@dan.tobias.name>	<20081230.175727.1306326652.imp@bsdimp.com>	<495AC9C8.9010601@cox.net>
	<20081230.190100.-1916658631.imp@bsdimp.com>
Message-ID: <495AEB56.4080806@cox.net>


> GMT is officially deprecated as the term for what is now UTC.  To
> continue to use the old terminology over three and a half decades
> after it was deprecated is a mistake.

Who officially depreciated it? If Paul is correct
and GMT is owned by the British, why would
a NIST web site should be belived?


From seaman at noao.edu  Tue Dec 30 22:41:45 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 20:41:45 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.194608.1172766174.imp@bsdimp.com>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
	<20081230.194608.1172766174.imp@bsdimp.com>
Message-ID: <ED8B39FB-5F33-451B-9907-7D06B14F903D@noao.edu>

M. Warner Losh writes:

>  Rob Seaman wrote:
>
>> BTW, it is unsurprising that people use UTC and GMT  
>> interchangeably, since the original CCIR standard said:
>>
>> 	"GMT may be regarded as the general equivalent of UT."
>>
>> This equivalence predates the ITU, and may well outlive the ITU.
>>>
>>
>
> But UT and UTC aren't the same thing...  So this confusion is  
> between what we call UT1 and UTC, which differ by hundreds of  
> milliseconds most of the time...


An academic point, since we've just thoroughly established that actual  
current usage mixes UTC and GMT willy-nilly.

However, I've appended a longer excerpt of the text of ITU-R-TF. 
460-4.  In addition to the general equivalence of GMT and UT, we also  
learn that "Universal Time (UT) is the general designation of time  
scales based on the rotation of the Earth."

Different flavors of UT are described that differ only at the level of  
hundredths of a second.  We learn that leap seconds exist to  
"unsure" [sic] approximate agreement of UTC with UT1.  (A rather  
amusing typo :-)  And further, that DUT1 exists to improve that  
approximation.

This is a coherent and close equivalence of 5 different timescales,  
plus the general purpose alias "UT", that are all explicitly stated to  
reflect the rotation of the Earth.

If we were to actively seek consensus here, a good place to start  
would be the word "approximation".  Eradicating both leap seconds and  
DUT1 would destroy any possible interpretation commensurate with  
approximation.

Rob
---

> A. Universal Time (UT)
> Universal Time (UT) is the general designation of time scales based  
> on the rotation of the Earth.
>
> In applications in which an imprecision of a few hundredths of a  
> second cannot be tolerated, it is necessary to specify the form of  
> UT which should be used:
>
> UT0 is the mean solar time of the prime meridian obtained from  
> direct astronomical observation;
>
> UT1 is UT0 corrected for the effects of small movements of the Earth  
> relative to the axis of rotation (polar variation);
>
> UT2 is UT1 corrected for the effects of a small seasonal fluctuation  
> in the rate of rotation of the Earth;
>
> UT1 is used in this document, since it corresponds directly with the  
> angular position of the Earth around its axis of diurnal rotation.  
> (GMT may be regarded as the general equivalent of UT.)
>
> Concise definitions of the above terms and the concepts involved are  
> available in the glossary of the annual publication, The  
> Astronomical Almanac (US Government Printing Office, Washington DC  
> and H.M. Stationery Office, London).
>
> [...]
>
> C. Coordinated Universal Time (UTC)
>
> UTC is the time-scale maintained by the BIPM, with assistance from  
> the International Earth Rotation Service (IERS), which forms the  
> basis of a coordinated dissemination of standard frequencies and  
> time signals. It corresponds exactly in rate with TAI but differs  
> from it by an integral number of seconds.
>
> The UTC scale is adjusted by the insertion or deletion of seconds  
> (positive or negative leap-seconds) to unsure approximate agreement  
> with UT1.
>

> D. DUT1
>
> The value of the predicted difference UT1 ? UTC, as disseminated  
> with the time signals is denoted DUT1; thus DUT1 ? UT1 ? UTC.  
> DUT1 may be regarded as a correction to be added to UTC to obtain a  
> better approximation to UT1.  [...]

From jhardis at tcs.wap.org  Tue Dec 30 23:25:14 2008
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Tue, 30 Dec 2008 23:25:14 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231022213.GA14795@ucolick.org>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>	<495AC9C8.9010601@cox.net>
	<20081230.190100.-1916658631.imp@bsdimp.com>
	<20081231022213.GA14795@ucolick.org>
Message-ID: <p06230907c5809b279ff1@[192.168.0.5]>

>The NIST web pages also make the wikipedia-cited claim that the ITU
>chose the apellation "UTC".
>
>http://tf.nist.gov/general/misc.htm#Anchor-14550
>
>I can find no evidence to support this, and much evidence to refute
>it.  Perhaps the evidence is buried in one of the private documents
>shelved in Geneva...

Steve,

We're talking about a technical decision made in 1970, not 1790. 
Many of the people involved then are still around, active in the 
field.  If this story were not true, don't you think that SOMEONE 
would have spoken up about it by now?

'Fess up.  Do you think the moon landing the year earlier (1969) also 
lacks evidence to support it?

>I find those NIST statements to be about as accurate as the NIST 
>press release this month which indicates that their 
>less-stable-than-quartz-crystal ammonia molecule clock was the first 
>atomic clock.

I'm not entirely sure what you're fussing about.  That ammonia is a 
molecule and not an atom?  That the first clock system based on 
discrete quantum states turned out to be not as good as cesium would 
ultimately be?

I have no problem referring to it as an "atomic" clock since all the 
action is in the nitrogen atom, which moves back and forth between 
the two minima of its double-well (at least in superpositions of such 
states).  I remind you that Charles Townes built his first maser -- 
an ammonia maser -- in 1954.  It was a nice prototype system of its 
day.

   - Jonathan

From jhardis at tcs.wap.org  Tue Dec 30 23:32:27 2008
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Tue, 30 Dec 2008 23:32:27 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231012433.GA14690@ucolick.org>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>
	<46273.1230682346@critter.freebsd.dk>
	<495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<20081231012433.GA14690@ucolick.org>
Message-ID: <p06230908c580a4dfe71c@[192.168.0.5]>

>In short, much of the dysfunctionality of the current scenario is a
>result of NOBODY being in charge of UTC.  To say that the ITU-R is
>actually the owner of UTC is somewhat of a fiction, both in history
>and current practice.

Please rest assured that the same group of experts show up to both 
the ITU WG7A meetings and the BIPM CCTF meetings.  If for whatever 
historical reason they have opted to seek consensus first within the 
ITU, so be it.  I really can't imagine them making a decision within 
one body that they wouldn't also make in the other.

   - Jonathan

From jhardis at tcs.wap.org  Tue Dec 30 23:39:58 2008
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Tue, 30 Dec 2008 23:39:58 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <ED8B39FB-5F33-451B-9907-7D06B14F903D@noao.edu>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
	<20081230.194608.1172766174.imp@bsdimp.com>
	<ED8B39FB-5F33-451B-9907-7D06B14F903D@noao.edu>
Message-ID: <p06230909c580a7166c0a@[192.168.0.5]>

>we also learn that "Universal Time (UT) is the general designation 
>of time scales based on the rotation of the Earth."

Then it's not very "Universal," now is it?

You can still consider it an oxymoron, if you'd like.

   - Jonathan

From imp at bsdimp.com  Tue Dec 30 23:54:22 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 21:54:22 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495AE9E8.7000608@cox.net>
References: <46683.1230687155@critter.freebsd.dk>
	<495AE9E8.7000608@cox.net>
Message-ID: <20081230.215422.2140533317.imp@bsdimp.com>

In message: <495AE9E8.7000608 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: > Now, do you belive me when I say that 99+% of all programmers
: > wouldn't get a leap-second right if they even knew what it was ?
: 
: Then my advice is to work on getting better programmers rather
: than messing with leap seconds.

Even really good programmers have problems with leap seconds.  Plus,
you've ignored the practical issues that I've raised with using an
additional time scale that isn't UTC...

Warner

From seaman at noao.edu  Tue Dec 30 23:58:16 2008
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 30 Dec 2008 21:58:16 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <p06230908c580a4dfe71c@[192.168.0.5]>
References: <495A6C34.26550.11CE6F05@dan.tobias.name>
	<46273.1230682346@critter.freebsd.dk>
	<495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<20081231012433.GA14690@ucolick.org>
	<p06230908c580a4dfe71c@[192.168.0.5]>
Message-ID: <1D08C2BD-00CF-402A-9B31-724DCF433FAC@noao.edu>

On Dec 30, 2008, at 9:32 PM, Jonathan E. Hardis wrote:

> Please rest assured that the same group of experts show up to both  
> the ITU WG7A meetings and the BIPM CCTF meetings.

What does this mean, precisely?  I'm completely ignorant of the  
logistics.  Is there actually a near one-to-one correspondence between  
the two groups?  Or is one group a subset of the other?

Also, what does "show up" mean?  Are either of these open meetings?   
At a typical meeting, what fraction of eligible attendees actually  
attend?  Does voting require attendance?  Do some attend via video or  
audio?

And what sort of experts participate?  Are these all technical folks,  
or managers, or lawyers, or what?

Rob


From imp at bsdimp.com  Wed Dec 31 00:00:44 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 22:00:44 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495AEB56.4080806@cox.net>
References: <495AC9C8.9010601@cox.net>
	<20081230.190100.-1916658631.imp@bsdimp.com>
	<495AEB56.4080806@cox.net>
Message-ID: <20081230.220044.502287442.imp@bsdimp.com>

In message: <495AEB56.4080806 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: 
: > GMT is officially deprecated as the term for what is now UTC.  To
: > continue to use the old terminology over three and a half decades
: > after it was deprecated is a mistake.
: 
: Who officially depreciated it? If Paul is correct
: and GMT is owned by the British, why would
: a NIST web site should be belived?

Well, NASA isn't running on GMT, but rather UTC.  That's the relevant
point for my point.  They are calling one thing by the old-archaic
term that has mutated into something else.

I'd tend to believe the NIST web site, since they are in charge of the
official time in the United States.  While we might qibble over some
minor details (see Steve Allan's posts for some of the minor
inconsistencies), on the whole it is correct.  It also agrees with the
USNO web pages, as well as the BIPM web pages.  Would you like the
URLs?

Warner


From greg.hennessy at cox.net  Wed Dec 31 00:05:49 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Wed, 31 Dec 2008 00:05:49 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.215422.2140533317.imp@bsdimp.com>
References: <46683.1230687155@critter.freebsd.dk>	<495AE9E8.7000608@cox.net>
	<20081230.215422.2140533317.imp@bsdimp.com>
Message-ID: <495AFDAD.507@cox.net>


 > Even really good programmers have problems with leap seconds.  Plus,
 > you've ignored the practical issues that I've raised with using an
 > additional time scale that isn't UTC...

I agree that good programmers have problems with leap seconds,
partly due to POSIX not doing what I think is the correct
thing, but again, I see the proper thing is to fix POSIX,
not break leap seconds.

And I haven't ignored the practical issues you've raised.
I don't agree with your conclusions, but that doesn't
mean I ignored the issues.


From imp at bsdimp.com  Wed Dec 31 00:05:27 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 22:05:27 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <p06230907c5809b279ff1@[192.168.0.5]>
References: <20081230.190100.-1916658631.imp@bsdimp.com>
	<20081231022213.GA14795@ucolick.org>
	<p06230907c5809b279ff1@[192.168.0.5]>
Message-ID: <20081230.220527.1492586015.imp@bsdimp.com>

In message: <p06230907c5809b279ff1@[192.168.0.5]>
            "Jonathan E. Hardis" <jhardis at tcs.wap.org> writes:
: >The NIST web pages also make the wikipedia-cited claim that the ITU
: >chose the apellation "UTC".
: >
: >http://tf.nist.gov/general/misc.htm#Anchor-14550
: >
: >I can find no evidence to support this, and much evidence to refute
: >it.  Perhaps the evidence is buried in one of the private documents
: >shelved in Geneva...
: 
: Steve,
: 
: We're talking about a technical decision made in 1970, not 1790. 
: Many of the people involved then are still around, active in the 
: field.  If this story were not true, don't you think that SOMEONE 
: would have spoken up about it by now?

Steve has documented a profoundly dysfunctional community that did
thing without proper consultation.  He's further documented apologies
for past bad behavior, as well as producing many of the primary
sources to back up his assertions.  Based on this history, I'm
inclined to give him the benefit of the doubt in this area.  In the
past, he's expanded the refuting evidence at length.

: 'Fess up.  Do you think the moon landing the year earlier (1969) also 
: lacks evidence to support it?

There's much independent evidence to support this...  So it is
different...

Warner


From greg.hennessy at cox.net  Wed Dec 31 00:15:22 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Wed, 31 Dec 2008 00:15:22 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.220044.502287442.imp@bsdimp.com>
References: <495AC9C8.9010601@cox.net>	<20081230.190100.-1916658631.imp@bsdimp.com>	<495AEB56.4080806@cox.net>
	<20081230.220044.502287442.imp@bsdimp.com>
Message-ID: <495AFFEA.7020808@cox.net>


 > Well, NASA isn't running on GMT, but rather UTC.  That's the relevant
 > point for my point.

You are asserting that one is different from the other.
I'm asking you the basis of that assertion.
Repeating your assertion is not an answer to my question.

 > They are calling one thing by the old-archaic
 > term that has mutated into something else.

To the general public, I submit that GMT has mutated into UTC.
In about 24 hours from now, I'll be watching my TV watching
the time ball in Times Square drop. They will do a countdown
10-9-8-7-6-5-4-3-1-LEAP-0. I'll kiss my wife, and she will
get annoyed at me when I point out that they did the leap
second wrong.

If I was in London about 19 hours from now, I assume
that the legal time would be GMT. I would assume
that de facto, a leap second added after 11h59m59s PM.
Thus in practice GMT is UTC, for large numbers of people.

 > I'd tend to believe the NIST web site, since they are in charge of the
 > official time in the United States.

Why would you belive the NIST web site on how GMT is defined
rather than quoting British law or some other English site?

 > It also agrees with the
 > USNO web pages, as well as the BIPM web pages.  Would you like the
 > URLs?

Since I don't consider them relavent, no thank you.

From imp at bsdimp.com  Wed Dec 31 00:30:29 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 22:30:29 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495AFFEA.7020808@cox.net>
References: <495AEB56.4080806@cox.net>
	<20081230.220044.502287442.imp@bsdimp.com>
	<495AFFEA.7020808@cox.net>
Message-ID: <20081230.223029.1346822441.imp@bsdimp.com>

In message: <495AFFEA.7020808 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: Since I don't consider them relavent, no thank you.

Then you are too clueless to argue with.

Seriously, if you are advocating leap seconds that are defined by the
folks you don't think are relevant, then have a nice night.

Warner

From imp at bsdimp.com  Wed Dec 31 01:00:02 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 30 Dec 2008 23:00:02 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495AFFEA.7020808@cox.net>
References: <495AEB56.4080806@cox.net>
	<20081230.220044.502287442.imp@bsdimp.com>
	<495AFFEA.7020808@cox.net>
Message-ID: <20081230.230002.-467811804.imp@bsdimp.com>

In message: <495AFFEA.7020808 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
:  > It also agrees with the
:  > USNO web pages, as well as the BIPM web pages.  Would you like the
:  > URLs?
: 
: Since I don't consider them relavent, no thank you.

The problem is that GMT means several different things.  It is an
ambiguous term.

Those web sites are relevant for at least one definition of GMT.  GMT
is the mean solar time at the royal observatory, at least
historically.  This means that there are no leap seconds.  This is
approximately what is now called UT1.  It differs from UTC, as it is
realized today, by a few hundred milliseconds either way (depending on
when the last leap second happened).  For this definition see the
following:

http://en.wikipedia.org/wiki/Time_zone
(note references to GMT being the mean SOLAR TIME (emp mine))
http://www.answers.com/topic/greenwich-mean-time
(in particular note that the legal time is based on GMT, not UTC,
 implying they are different)
http://encyclopedia2.thefreedictionary.com/Greenwich+Mean+Time
(which says it is equivalent to UT, which is a solar time)

More are a Google search away.  At the very least, it shows that GMT
is an ambiguous term.  At most it shows that it is a solar time,
different from UTC (although closely related).

This is one of the many reasons why UTC is the proper form.

Warner

From sla at ucolick.org  Wed Dec 31 01:43:50 2008
From: sla at ucolick.org (Steve Allen)
Date: Tue, 30 Dec 2008 22:43:50 -0800
Subject: [LEAPSECS] BBC World Service at 06:55 GMT
Message-ID: <20081231064350.GA27296@ucolick.org>

They say there will be a tune from the Muppets to go along with the
story on the leap second.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Wed Dec 31 03:08:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 08:08:33 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 19:01:00 MST."
	<20081230.190100.-1916658631.imp@bsdimp.com> 
Message-ID: <48139.1230710913@critter.freebsd.dk>

In message <20081230.190100.-1916658631.imp at bsdimp.com>, "M. Warner Losh" write
s:

>http://tf.nist.gov/timefreq/general/enc-g.htm
>
>>> Greenwich Mean Time (GMT)
>
>>> A 24-hour time keeping system whose hours, minutes, and seconds
>>> represent the time-of-day at the Earth's prime meridian (0=B0
>>> longitude) located near Greenwich, England.

Notice the "near": the 0? meridian no longe passes through the
transit instrument there.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From phk at phk.freebsd.dk  Wed Dec 31 03:10:17 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 08:10:17 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 19:31:57 MST."
	<62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu> 
Message-ID: <48156.1230711017@critter.freebsd.dk>

In message <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5 at noao.edu>, Rob Seaman writes:
>M. Warner Losh wrote:

>But GMT has a  
>clear definition tied to - Hush my mouth! - the position of the mean  
>sun in the sky.

No it does not, GMT wandered several seconds when the 0? longitude
were moved away from he observatory.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From sla at ucolick.org  Wed Dec 31 03:51:35 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 31 Dec 2008 00:51:35 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48156.1230711017@critter.freebsd.dk>
References: <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
	<48156.1230711017@critter.freebsd.dk>
Message-ID: <20081231085135.GA27564@ucolick.org>

On Wed 2008-12-31T08:10:17 +0000, Poul-Henning Kamp hath writ:
> >But GMT has a
> >clear definition tied to - Hush my mouth! - the position of the mean
> >sun in the sky.
>
> No it does not, GMT wandered several seconds when the 0? longitude
> were moved away from he observatory.

GMT did not shift by seconds.  As with the rest of the discussion here
we are talking about two different and necessary-to-distinguish
things.

The geodetic longitude of the Greenwich transits is 5 arc seconds west
of the "International Meridian" defined by the global,
satellite-geocentered, VLBI-oriented reference frames.  That's less
than one second of time -- but it's mostly irrelevant to GMT.

Of those 5 arcseconds difference, the major component is due to the
E/W component of the deflection of vertical at Greenwich.  That is to
say, at Greenwich "up" is 5 arc seconds different than "geocentrically
radial".

Strict GMT is defined by the astronomical longitude of the
observatory.

Yes, using the international reference frames there was a shift.  When
BIH chose the statistical weights of the observations from all sites,
and as they averaged the differences in the "conventional longitudes"
of all the observatories which had been in use from the pre-satellite
era the terrestrial reference frame did shift.

This shift on the order of centiseconds of time.

And yes, it will drift over time at plate tectonic rates.
But that shift will not accelerate quadratically in the way that
atomic time and universal time will diverge.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Wed Dec 31 06:20:28 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 11:20:28 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Tue, 30 Dec 2008 22:42:46 EST."
	<495AEA36.7080608@cox.net> 
Message-ID: <48968.1230722428@critter.freebsd.dk>

In message <495AEA36.7080608 at cox.net>, Greg Hennessy writes:

>Poul-Henning Kamp wrote:
>> In message <495AC9C8.9010601 at cox.net>, Greg Hennessy writes:
>> 
>>> If you wish to make an argument that they did get it incorrect, please
>>> do so.
>> 
>> GMT is a timescale owned and defined by the British Parliament.
>> 
>> I rest my case.
>
>Excuse me, I don't see a case.
>
>You seem to be asserting that the use of GMT is an
>error. What is the error that you see?

Greg,

Several people on the "pro-leap" side here, have argued that
"programmers should just do it correctly and we would have no
problems. 

I don't know what you do for a living, but unless you are a programmer
yourself, you are likely to work at a level of complexity about
1000 times lower than programmers like Warner and me.

Right now, despite the best of my efforts, my "Varnish" program
which is used to speed up websites like marines.com, is growing
larger than the on-board software in the apollo capsule.

And that is widely admired for being an incredibly small program
for what it does.  The nearest competitor is five times larger
(and ten times slower :-).

The FreeBSD kernel Warner and I have worked on for 15 years approaches
5 million lines of code.

For comparison, the US navy touted the complexity of the Air
craft carrier Ronald Reagan (CVN-76), by boasting that it was
built from "more than one million individually tracked pieces".

Spare parts for al US cars, numbers only approx 1.5 million.

Of the 200+ FreeBSD developers, only Warner and I truly know how
the relevant 2500 lines of code keep track of time and leap-seconds.

Me because I wrote most of it, Warner because he worked at timing.com
who used it to deliver timing gadgets to customers like NIST and
USCG.

I won't claim. that Warner and I are the best programmers there
are, when it comes to timekeeping in operating system kernels.

But you would be hard pressed to find ten like us.  Anywhere.

Therefore I do feel on solid ground when I tell you, that when not
even NASA can get a detail like UTC/GMT right, we have no reason
to expect or rely on programmers to get leap seconds right.

Emperical evidence show that this is indeed the case, and the
fact that even national time laboratories screw up, underscores
this fact: http://phk.freebsd.dk/Leap/20051231_HBG/

Back when computers had just broken the 32 kilowords barrier, one
of the greatest thinkers in computer science wrote:

     "My own feelings are perhaps best described by saying that I am
      perfectly aware that there is no Royal Road to Mathematics, in other
      words, that I have only a very small head and must live with it."
		-- Edsger W. Dijkstra

We have no way to upgrade our programmers, we can only make the
task in front of them simpler.

The fact that you cannot see the problem, does not make it a non-problem,
people like Warner and me have seen the problems, we know they are there.

If you don't trust us, how about this:

	Judah Levine of the National Institute of Standards and
	Technology in Boulder, Colorado, which provides the time
	standard and technical support for most commercial activities
	in the US is braced for New Year's Eve. "On December 31,
	I'll be waiting with a cup of coffee for the problems to
	roll in," he sighs.

	http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-leap-second-grow.html


Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From dan at tobias.name  Wed Dec 31 07:55:42 2008
From: dan at tobias.name (Daniel R. Tobias)
Date: Wed, 31 Dec 2008 07:55:42 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48139.1230710913@critter.freebsd.dk>
References: <Your message of "Tue, 30 Dec 2008 19:01:00 MST."
	<20081230.190100.-1916658631.imp@bsdimp.com> >,
	<48139.1230710913@critter.freebsd.dk>
Message-ID: <495B257E.27731.14A24046@dan.tobias.name>

On 31 Dec 2008 at 8:08, Poul-Henning Kamp wrote:

> Notice the "near": the 0? meridian no longe passes through the
> transit instrument there.

They moved it?  (The meridian, or the transit instrument?)

Given continental drift, there really aren't any "fixed objects" on 
Earth anyway... just what is the meridian defined relative to?


-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From nimh at pipe.nl  Wed Dec 31 07:56:42 2008
From: nimh at pipe.nl (Nero Imhard)
Date: Wed, 31 Dec 2008 13:56:42 +0100
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <45973.1230678135@critter.freebsd.dk>
References: <45973.1230678135@critter.freebsd.dk>
Message-ID: <4E21991A-9580-4345-882B-6BE21E73349A@pipe.nl>

On 2008-12-31, at 00:02, Poul-Henning Kamp wrote:

> TAI is only a paperclock

And how is UTC not a "paperclock" as well? UTC is only known after the  
fact, when the BIPM publishes its analysis of comparisons between  
various renditions of UTC.

So your actual point may be that there are no suitable renditions of  
TAI. But wasn't that ITU's whole idea in the first pace? To make  
available renditions of a time scale that has no leap seconds?

N

From phk at phk.freebsd.dk  Wed Dec 31 08:01:43 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 13:01:43 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 13:56:42 +0100."
	<4E21991A-9580-4345-882B-6BE21E73349A@pipe.nl> 
Message-ID: <49590.1230728503@critter.freebsd.dk>

In message <4E21991A-9580-4345-882B-6BE21E73349A at pipe.nl>, Nero Imhard writes:
>On 2008-12-31, at 00:02, Poul-Henning Kamp wrote:
>
>> TAI is only a paperclock
>
>And how is UTC not a "paperclock" as well? UTC is only known after the  
>fact, when the BIPM publishes its analysis of comparisons between  
>various renditions of UTC.

The pure UTC is a paper clock like TAI, but there are plenty of
"real" UTC's to be had.

UTC has local implementations, such as UTC(PTB), UTC(USNO), UTC(NIST),
which are disseminated to the public via networks and radio signals.

The fact that TAI and UTC is an integer number of seconds apart,
makes the distinction between UTC and TAI as being more or less
a paper-clock a _very_ academic discussion.

Time-lords make a point about it nontheless: whenever somebody talks
about using TAI for something, they state in no uncertain terms that
this is not to be done.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From greg.hennessy at cox.net  Wed Dec 31 08:23:14 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Wed, 31 Dec 2008 08:23:14 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081230.230002.-467811804.imp@bsdimp.com>
References: <495AEB56.4080806@cox.net>	<20081230.220044.502287442.imp@bsdimp.com>	<495AFFEA.7020808@cox.net>
	<20081230.230002.-467811804.imp@bsdimp.com>
Message-ID: <495B7242.4030006@cox.net>



M. Warner Losh wrote:
> In message: <495AFFEA.7020808 at cox.net>
>             Greg Hennessy <greg.hennessy at cox.net> writes:
> :  > It also agrees with the
> :  > USNO web pages, as well as the BIPM web pages.  Would you like the
> :  > URLs?
> : 
> : Since I don't consider them relavent, no thank you.
> 
> The problem is that GMT means several different things.  It is an
> ambiguous term.

Thank you, you have finally acknowledged the point I making.

And you were able to do it without the personal insult you sent
to my private email account.

Given that GMT can mean more than one timescale, is a person
or group necessarily wrong when using the term?


From greg.hennessy at cox.net  Wed Dec 31 08:39:18 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Wed, 31 Dec 2008 08:39:18 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48968.1230722428@critter.freebsd.dk>
References: <48968.1230722428@critter.freebsd.dk>
Message-ID: <495B7606.9040609@cox.net>


> I don't know what you do for a living, but unless you are a programmer
> yourself, you are likely to work at a level of complexity about
> 1000 times lower than programmers like Warner and me.

I'm an astronomer working for USNO. The last third of
your sentence comes across as "I'm smarter than you are, you should
accept what I say", which is not a philosophy I agree with. I
concede you may not have intended it in that fashion.

> Therefore I do feel on solid ground when I tell you, that when not
> even NASA can get a detail like UTC/GMT right, we have no reason
> to expect or rely on programmers to get leap seconds right.

And when you say that rocket scientists at NASA have made
an error, and can't show it was rockets scientists who
have made the error, or that it is actually an error,
it weakens the argument you are making.

> The fact that you cannot see the problem, does not make it a non-problem,
> people like Warner and me have seen the problems, we know they are there.

You again refer to a "fact" that isn't one. I assure you I see
problems with the current state of affairs. That I favor different
solutions than you do does not mean I'm not seeing the problem.





From phk at phk.freebsd.dk  Wed Dec 31 09:26:33 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 14:26:33 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 08:39:18 EST."
	<495B7606.9040609@cox.net> 
Message-ID: <50010.1230733593@critter.freebsd.dk>

In message <495B7606.9040609 at cox.net>, Greg Hennessy writes:
>
>> I don't know what you do for a living, but unless you are a programmer
>> yourself, you are likely to work at a level of complexity about
>> 1000 times lower than programmers like Warner and me.
>
>I'm an astronomer working for USNO. The last third of
>your sentence comes across as "I'm smarter than you are, you should
>accept what I say", which is not a philosophy I agree with. I
>concede you may not have intended it in that fashion.

I didn't say I was smarter, I said that I know more than you about
how computers and operating systems keep track of time, and how
people (ab)use those programming interfaces.

>That I favor different
>solutions than you do does not mean I'm not seeing the problem.

If you cannot see why the GMT/UTC confusion is a problem, then
you do not properly appreciate why any proposal that adds a new
timescale is a non-starter.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From lang at unb.ca  Wed Dec 31 09:33:16 2008
From: lang at unb.ca (Richard B. Langley)
Date: Wed, 31 Dec 2008 10:33:16 -0400
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231085135.GA27564@ucolick.org>
References: <62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
	<48156.1230711017@critter.freebsd.dk>
	<20081231085135.GA27564@ucolick.org>
Message-ID: <1230733996.495b82acce1c9@webmail.unb.ca>

Quoting Steve Allen <sla at ucolick.org>:
 
> The geodetic longitude of the Greenwich transits is 5 arc seconds west
> of the "International Meridian" defined by the global,
> satellite-geocentered, VLBI-oriented reference frames.  That's less
> than one second of time -- but it's mostly irrelevant to GMT.
> 
> Of those 5 arcseconds difference, the major component is due to the
> E/W component of the deflection of vertical at Greenwich.  That is to
> say, at Greenwich "up" is 5 arc seconds different than "geocentrically
> radial".

Steve:
The 5 arcseconds is the difference between two geodetic longitudes, so I believe
deflection of the vertical is not a component of this difference, it has already been
taken into account. The drift from the Airy meridian is due to 
i) The merging of transit measurements from many global observatories by the BIH.
ii) The the shift of the Greenwich transit observations to PZT measurements at
Herstmonceux.
iii) The introduction of the satellite Doppler technique (Transit) to help in
establishing the BIH meridian; the Doppler datum turned out to have a different
longitude origin.
iv) Misalignment of the series of WGS reference meridians with that of BIH.
Further details here:
<http://www.nmm.ac.uk/explore/astronomy-and-time/astronomy-facts/history/the-longitude-of-greenwich>
<http://en.wikipedia.org/wiki/Prime_Meridian>

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From phk at phk.freebsd.dk  Wed Dec 31 09:42:55 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 14:42:55 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 10:33:16 -0400."
	<1230733996.495b82acce1c9@webmail.unb.ca> 
Message-ID: <50087.1230734575@critter.freebsd.dk>

In message <1230733996.495b82acce1c9 at webmail.unb.ca>, "Richard B. Langley" writ
es:

>iii) The introduction of the satellite Doppler technique (Transit) to help in
>establishing the BIH meridian; the Doppler datum turned out to have a different
>longitude origin.
>iv) Misalignment of the series of WGS reference meridians with that of BIH.

So which datum is used for the zero meridian, which defines the UT* family
of timescales ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From lang at unb.ca  Wed Dec 31 09:56:58 2008
From: lang at unb.ca (Richard B. Langley)
Date: Wed, 31 Dec 2008 10:56:58 -0400
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50087.1230734575@critter.freebsd.dk>
References: <50087.1230734575@critter.freebsd.dk>
Message-ID: <1230735418.495b883a0082e@webmail.unb.ca>

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

> In message <1230733996.495b82acce1c9 at webmail.unb.ca>, "Richard B. Langley" writ
> es:
> 
> >iii) The introduction of the satellite Doppler technique (Transit) to help in
> >establishing the BIH meridian; the Doppler datum turned out to have a different
> >longitude origin.
> >iv) Misalignment of the series of WGS reference meridians with that of BIH.
> 
> So which datum is used for the zero meridian, which defines the UT* family
> of timescales ?

That would be the current ITRF as established by the IERS:
<http://www.iers.org/MainDisp.csl?pid=42-17>
It is a realization of the ITRS:
<http://www.iers.org/MainDisp.csl?pid=97-108>

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From lang at unb.ca  Wed Dec 31 10:00:20 2008
From: lang at unb.ca (Richard B. Langley)
Date: Wed, 31 Dec 2008 11:00:20 -0400
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50087.1230734575@critter.freebsd.dk>
References: <50087.1230734575@critter.freebsd.dk>
Message-ID: <1230735620.495b890442f65@webmail.unb.ca>

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

> In message <1230733996.495b82acce1c9 at webmail.unb.ca>, "Richard B. Langley" writ
> es:
> 
> >iii) The introduction of the satellite Doppler technique (Transit) to help in
> >establishing the BIH meridian; the Doppler datum turned out to have a different
> >longitude origin.
> >iv) Misalignment of the series of WGS reference meridians with that of BIH.
> 
> So which datum is used for the zero meridian, which defines the UT* family
> of timescales ?

This might also be relevant:
<ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT>

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From phk at phk.freebsd.dk  Wed Dec 31 10:12:07 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 15:12:07 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 10:56:58 -0400."
	<1230735418.495b883a0082e@webmail.unb.ca> 
Message-ID: <50258.1230736327@critter.freebsd.dk>

In message <1230735418.495b883a0082e at webmail.unb.ca>, "Richard B. Langley" writes:
>Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

>> So which datum is used for the zero meridian, which defines the UT* family
>> of timescales ?
>
>That would be the current ITRF as established by the IERS:
><http://www.iers.org/MainDisp.csl?pid=42-17>
>It is a realization of the ITRS:
><http://www.iers.org/MainDisp.csl?pid=97-108>

OK....

And since WGS84 is not rigidly linked to ITRS, doesn't that mean
that in order to use DUT1 broadcasts to point a telescope (precisely[1])
you also need to the ITRS/WGS84 difference at your place ?

Has anybody calculated what the worst case DUT1 difference is in
the WGS84 datum ?

Poul-Henning

[1] Yes, I know telescopes do not use dead reckoning at this level of 
precision (yet ?)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From seaman at noao.edu  Wed Dec 31 10:37:37 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 08:37:37 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48139.1230710913@critter.freebsd.dk>
References: <48139.1230710913@critter.freebsd.dk>
Message-ID: <36778AE2-DACE-4DF3-9A31-C135CC3436B1@noao.edu>

Poul-Henning Kamp wrote:

> Notice the "near": the 0? meridian no longe passes through the  
> transit instrument there.

Steve and Richard have replied with their usual level of precision.   
We risk getting lost in the details.

I might just remind folks that one arc second corresponds to 30 meters  
on the surface of the Earth.  At the equator, that means that one  
second of time corresponds to 450 meters.  (280m at the latitude of  
Greenwich.)  It is the ITU that is seeking to move the prime meridian,  
by about two-tenths of a mile per year at the equator (accelerating  
quadratically).

We've had this discussion before.  What might be different this time  
is that presumably there must now be some plan among the proponents of  
the ITU proposal to deal with the obvious and completely unacceptable  
implications.  Or is there?

Of the several rather absurd options it appears the one the ITU has  
selected, perhaps implicitly, is to throw Greenwich Mean Time under  
the bus.

I won't belabor in this message why that is not likely to happen in  
practice. But again - there are indeed two different kinds of time,  
and if you suppress one kind in one place, it will always pop up again  
somewhere else.

In any event, a policy for dealing with the prime meridian should  
appear in the ITU proposal.  If you think this is a non-issue, it  
should be easy to describe, right?

And what precisely does the ITU propose to do should the UK not accept  
this plan?  We've been gleefully informed that people persist in  
identifying UTC with GMT.  We've been told that GMT is nothing more  
than the timezone of Greenwich.  We've also been told that the  
intercalary corrections will be managed purely by local authorities  
messing with their timezones.  What if local authorities have  
different ideas about the appropriateness of this?

Greenwich Mean Time is (and will be) reified by nature.  UTC is  
currently reified by GMT.  The ITU seeks to wrench the two definitions  
apart, but is implicitly insisting that they remain the same so that  
the Greenwich timezone can participate in the inevitable intercalary  
adjustments.

The ITU's biggest argument is with itself.

Rob


From phk at phk.freebsd.dk  Wed Dec 31 10:41:29 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 15:41:29 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 08:37:37 MST."
	<36778AE2-DACE-4DF3-9A31-C135CC3436B1@noao.edu> 
Message-ID: <50448.1230738089@critter.freebsd.dk>

In message <36778AE2-DACE-4DF3-9A31-C135CC3436B1 at noao.edu>, Rob Seaman writes:

>It is the ITU that is seeking to move the prime meridian,  
>by about two-tenths of a mile per year at the equator (accelerating  
>quadratically).

Until now I have never seen any indication anywhere that longitude
or lattitude would be affected in any way.

Pray, show us the documentation for this hyperbole.

Or, alternatively, stow spewing such nonsense.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From lang at unb.ca  Wed Dec 31 10:48:31 2008
From: lang at unb.ca (Richard B. Langley)
Date: Wed, 31 Dec 2008 11:48:31 -0400
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50258.1230736327@critter.freebsd.dk>
References: <50258.1230736327@critter.freebsd.dk>
Message-ID: <1230738511.495b944f91ce3@webmail.unb.ca>

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

> And since WGS84 is not rigidly linked to ITRS, doesn't that mean
> that in order to use DUT1 broadcasts to point a telescope (precisely[1])
> you also need to the ITRS/WGS84 difference at your place ?
> 
> Has anybody calculated what the worst case DUT1 difference is in
> the WGS84 datum ?

The current version of WGS84 differs from the current version of ITRF by only a few
centimetres. WGS84 was purposely updated to agree as closely as possibly with ITRF.

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From phk at phk.freebsd.dk  Wed Dec 31 11:09:13 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 31 Dec 2008 16:09:13 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: Your message of "Wed, 31 Dec 2008 11:48:31 -0400."
	<1230738511.495b944f91ce3@webmail.unb.ca> 
Message-ID: <50557.1230739753@critter.freebsd.dk>

In message <1230738511.495b944f91ce3 at webmail.unb.ca>, "Richard B. Langley" writes:
>Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:
>
>> And since WGS84 is not rigidly linked to ITRS, doesn't that mean
>> that in order to use DUT1 broadcasts to point a telescope (precisely[1])
>> you also need to the ITRS/WGS84 difference at your place ?
>> 
>> Has anybody calculated what the worst case DUT1 difference is in
>> the WGS84 datum ?
>
>The current version of WGS84 differs from the current version of ITRF by only a few
>centimetres. WGS84 was purposely updated to agree as closely as possibly with ITRF.

But it is not guaranteed to keep close, is it ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From sla at ucolick.org  Wed Dec 31 11:24:30 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 31 Dec 2008 08:24:30 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50557.1230739753@critter.freebsd.dk>
References: <1230738511.495b944f91ce3@webmail.unb.ca>
	<50557.1230739753@critter.freebsd.dk>
Message-ID: <20081231162430.GA1039@ucolick.org>

On Wed 2008-12-31T16:09:13 +0000, Poul-Henning Kamp hath writ:
> In message <1230738511.495b944f91ce3 at webmail.unb.ca>, "Richard B. Langley" writes:
> >The current version of WGS84 differs from the current version of ITRF by only a few
> >centimetres. WGS84 was purposely updated to agree as closely as possibly with ITRF.
>
> But it is not guaranteed to keep close, is it ?

This is pretty much the same as asking whether GPS time will remain
close to (TAI - 19 s), and in a sense, whether it's okay to use GPS
time as a proxy for TAI.

It boils down to asking whether the US DoD intends to continue to
comply with international standards, and if so, how accurately.

We have seen that the international timekeepers of the BIPM get livid
when someone suggests that GPS time could be used in an official sense.
The IERS seems to be a bit more mellow.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From lang at unb.ca  Wed Dec 31 11:25:24 2008
From: lang at unb.ca (Richard B. Langley)
Date: Wed, 31 Dec 2008 12:25:24 -0400
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50557.1230739753@critter.freebsd.dk>
References: <50557.1230739753@critter.freebsd.dk>
Message-ID: <1230740724.495b9cf41d5cb@webmail.unb.ca>

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

> In message <1230738511.495b944f91ce3 at webmail.unb.ca>, "Richard B. Langley" writes:
> >Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:
> >
> >> And since WGS84 is not rigidly linked to ITRS, doesn't that mean
> >> that in order to use DUT1 broadcasts to point a telescope (precisely[1])
> >> you also need to the ITRS/WGS84 difference at your place ?
> >> 
> >> Has anybody calculated what the worst case DUT1 difference is in
> >> the WGS84 datum ?
> >
> >The current version of WGS84 differs from the current version of ITRF by only a few
> >centimetres. WGS84 was purposely updated to agree as closely as possibly with ITRF.
> 
> But it is not guaranteed to keep close, is it ?

Yes, it is. Geodetic reference frames are established these days by essentially adopting
the coordinates of the reference stations (primarily GPS) and their velocities. The
WGS84 reference sites are basically a subset of those used by IERS.

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From seaman at noao.edu  Wed Dec 31 11:25:31 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 09:25:31 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <50448.1230738089@critter.freebsd.dk>
References: <50448.1230738089@critter.freebsd.dk>
Message-ID: <1A264AF8-EB99-4E95-B585-91594CDCEEC5@noao.edu>

Poul-Henning Kamp wrote:

> Until now I have never seen any indication anywhere that longitude
> or lattitude would be affected in any way.
>
> Pray, show us the documentation for this hyperbole.

Ah!  That explains it.  You believe documentation is the master  
definition of a system.

Rather, requirements rooted in real world issues are the master.   
Whereas the requirements listed in the documentation are always  
incomplete and never completely self-consistent.

If this were a religious argument (which so many technology issues  
resemble), there would be a fundamentalist versus a liberal  
interpretation of every point.

Greenwich Mean Time has a clear definition that has nothing to do with  
technology.  The prime meridian likely has an official definition  
distinct from GMT, but in origin and practice the two are inextricably  
linked.

It is through the actions of CCIR as inherited by the ITU that UTC was  
linked to GMT.

Presumably nobody disputes that the ITU seeks to sunder this connection.

The Earth has a large moon.  As a result, the Earth's rotational  
angular momentum is being transferred to the Moon's orbit.  The Earth  
slows down.

Civil time is related to diurnal rhythms.  As a result, a timekeeper  
built on non-diurnal rhythms, like an ensemble of atomic clocks, will  
inevitably diverge from a timekeeper for civil time.

The ITU proposal is to flip the interpretation of the last paragraph.   
There are world's of possibilities in how this might be done.  The ITU  
has only ever considered the most garish option.

So civil time is to tick, tick, tick at a steady rate and the Sun in  
the sky is to fend for itself.  On some schedule (some of us prefer  
quick and some slow), intercalary adjustments will have to be made.

The implicit ITU position appears to be that these adjustments will be  
made through the system of timezones that were conveniently set up in  
the 19th century.  Consider this a preadaptation in the evolutionary  
sense.

Well, it just so happens that one of the timezones, actually the  
keystone of the whole system, is tied to GMT.  If the ITU's implicit  
assumption as to the future mechanism for intercalary adjustments is  
to work, then GMT must also be redefined to continue to serve as an  
approximation to the new UTC timescale.

So the ITU demands both that GMT != UTC and that GMT == UTC.

If the definition of GMT changes to be ITU-centric, rather than  
astronomical, the question of the definition and meaning of the prime  
meridian is left in limbo.  I certainly don't think the nice folks at  
the ITU have missed this point, so I am requesting that they make it  
evident in their proposal.  It would also help if the proposal were  
made publicly accessible.

So, I just typed that in without review.  I'll read through it once to  
look for typos, bad phraseology and so forth.  I had no problem  
navigating from top to bottom - and could continue to add levels of  
details - because the logic of the message is rooted in the logic of  
how the world works (and 9 years of practice :-)

The world, that is, is automatically self-consistent.  Documentation  
can be assumed to be always inconsistent.  Just because nobody has  
said anything about implications for latitude and longitude it doesn't  
mean that time and space aren't related in various ways, prosaic and  
sublime.

Ok - my read through is finished.  The only change I made was to add  
the smiley and break the last paragraph at that point.  By comparison,  
a message layered on an analysis of ITU standards would be very  
laborious to construct since one would have to keep referring back to  
other documents and glosses on those documents.

Nature rulez!

Rob


From seaman at noao.edu  Wed Dec 31 11:54:36 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 09:54:36 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231162430.GA1039@ucolick.org>
References: <1230738511.495b944f91ce3@webmail.unb.ca>
	<50557.1230739753@critter.freebsd.dk>
	<20081231162430.GA1039@ucolick.org>
Message-ID: <EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5@noao.edu>

Steve Allen wrote:

> We have seen that the international timekeepers of the BIPM get livid
> when someone suggests that GPS time could be used in an official  
> sense.
> The IERS seems to be a bit more mellow.

Does anybody have insight into what the real issue is with simply  
adopting GPS time?  It has long seemed that UTC is simply caught in a  
crossfire between two factions of the precision timekeeping community.

If the ITU position were simply to stop distributing UTC and to start  
distributing GPS (or some TI = GPS offset to avoid a jump), this whole  
debate we are having would simply go away.  We'd work around the new  
standard.  Whether or not standard time would end up layered on UTC/ 
GMT or on GPS/TI would make for an entertaining discussion, but it  
would be a very different discussion.

Rather, the ITU is seeking to redefine UTC, and apparently GMT,  
perhaps just as some gambit in a funding war or academic dispute.

What's wrong with GPS?  Astronomers use it all the time, very  
productively.

Rob


From imp at bsdimp.com  Wed Dec 31 12:23:26 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed, 31 Dec 2008 10:23:26 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495B7242.4030006@cox.net>
References: <495AFFEA.7020808@cox.net>
	<20081230.230002.-467811804.imp@bsdimp.com>
	<495B7242.4030006@cox.net>
Message-ID: <20081231.102326.195751037.imp@bsdimp.com>

In message: <495B7242.4030006 at cox.net>
            Greg Hennessy <greg.hennessy at cox.net> writes:
: 
: 
: M. Warner Losh wrote:
: > In message: <495AFFEA.7020808 at cox.net>
: >             Greg Hennessy <greg.hennessy at cox.net> writes:
: > :  > It also agrees with the
: > :  > USNO web pages, as well as the BIPM web pages.  Would you like the
: > :  > URLs?
: > : 
: > : Since I don't consider them relavent, no thank you.
: > 
: > The problem is that GMT means several different things.  It is an
: > ambiguous term.
: 
: Thank you, you have finally acknowledged the point I making.
: 
: And you were able to do it without the personal insult you sent
: to my private email account.
: 
: Given that GMT can mean more than one timescale, is a person
: or group necessarily wrong when using the term?

Yes.  They are wrong.  They are misusing a term, although it is a
common mistake.  The proper term for UTC is UTC.  While others may
call it by other names, that shows an ignorance on their part of the
underlying details.  This lack of precision is but one example of why
it is hard to get this stuff right.  To get things right, you have to
use the right terms, not fuzzy, the public thinks it is right terms.

Warner


From imp at bsdimp.com  Wed Dec 31 12:40:18 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed, 31 Dec 2008 10:40:18 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5@noao.edu>
References: <50557.1230739753@critter.freebsd.dk>
	<20081231162430.GA1039@ucolick.org>
	<EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5@noao.edu>
Message-ID: <20081231.104018.570084810.imp@bsdimp.com>

In message: <EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Steve Allen wrote:
: 
: > We have seen that the international timekeepers of the BIPM get livid
: > when someone suggests that GPS time could be used in an official  
: > sense.
: > The IERS seems to be a bit more mellow.
: 
: Does anybody have insight into what the real issue is with simply  
: adopting GPS time?  It has long seemed that UTC is simply caught in a  
: crossfire between two factions of the precision timekeeping community.
: 
: If the ITU position were simply to stop distributing UTC and to start  
: distributing GPS (or some TI = GPS offset to avoid a jump), this whole  
: debate we are having would simply go away.  We'd work around the new  
: standard.  Whether or not standard time would end up layered on UTC/ 
: GMT or on GPS/TI would make for an entertaining discussion, but it  
: would be a very different discussion.
: 
: Rather, the ITU is seeking to redefine UTC, and apparently GMT,  
: perhaps just as some gambit in a funding war or academic dispute.
: 
: What's wrong with GPS?  Astronomers use it all the time, very  
: productively.

In the software that I wrote, I adapted a time scale similar to GPS
time.  There were no leap seconds in this time scale.  This made the
high precision math that was used to measure clocks and the like work
out in the face of leap seconds.  It made sure that certain measuring
events happened at the right time or the right interval.

However, it presented a number of challenges.  The biggest one was
that you had to know the number of leap seconds for the current time
before you could start up.  Either you were fed the GPS time, in which
case you needed them to display the UTC time to the user, set the
atomic clocks to the proper UTC time, get ntpd going with the proper
UTC time, etc.  Or you had UTC time and didn't know the offset to the
GPS time and had to wait for it to start the rest of the system.

While knowing this seems trivial, it is anything but for many common
scenarios.  The data is in the GPS stream, but a cold receiver can
take up to 20 minutes to deliver this data, which interferes with the
startup time specifications we had to meet.  For systems that didn't
have a GPS receiver, there's no widely deployed way to get this data.
NTP can provide it, but most NTP servers don't (and if you are an NTP
server that's disconnected, it can be hard to fabricate the necessary
tables).  There's ftp sites on the net that one can get it from, but
firewalls in the way often times in the installations I've used.  One
can mitigate these effects somewhat (knowing when you last knew when
the next leap second could be would help all but the coldest of spares
pulled off the shelf cases), but there are still edge cases that
remain.

Plus, even though we were using C++ that provided a number of
different ways to try to get the time scale right all the time,
several ways were found to slip through the cracks.  Time scale
confusion was often a subtle bug to find (but easy to spot: my times
are off by 34s!).  The multiplicity of the time scales also increased
the complexity of the programs.

In addition, we found that it was hard to exhaustively test different
leap second scenarios.  In one set of tests we thought we'd covered
everything (both positive and negative leap seconds).  However, we
neglected the case where there was no leap second at the prior leap
second opportunity (meaning December or June) and there's no leap
second this opportunity, then bad things would happen due to an array
overflow.  There were many other similar bugs that were found outside
of testing, but this one illustrates the complexities that are faced
when trying to get this pedantically correct for all cases.

So if there were multiple time scales propagated, there would still be
these problems so long at UTC was mandated anywhere in the system
design.

These are some of the practical problems associated with having to
cope with multiple time scales.  I'm sure there are many others.

Warner

From msokolov at ivan.Harhan.ORG  Wed Dec 31 13:01:57 2008
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Wed, 31 Dec 2008 18:01:57 GMT
Subject: [LEAPSECS] Schedule for success
Message-ID: <0812311801.AA21407@ivan.Harhan.ORG>

Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> Time-lords make a point about it nontheless: whenever somebody talks
> about using TAI for something, they state in no uncertain terms that
> this is not to be done.

Then let's just call it TAPF for Temps Atomique Pedant-Free.  TAPF is
identical with TAI in all ways but one single exception: when the pedants
say "you can't use TAI", that doesn't apply to TAPF because the latter
is pedant-free!

MS

From imp at bsdimp.com  Wed Dec 31 13:12:55 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed, 31 Dec 2008 11:12:55 -0700 (MST)
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231.102326.195751037.imp@bsdimp.com>
References: <20081230.230002.-467811804.imp@bsdimp.com>
	<495B7242.4030006@cox.net>
	<20081231.102326.195751037.imp@bsdimp.com>
Message-ID: <20081231.111255.846952744.imp@bsdimp.com>

In message: <20081231.102326.195751037.imp at bsdimp.com>
            "M. Warner Losh" <imp at bsdimp.com> writes:
: In message: <495B7242.4030006 at cox.net>
:             Greg Hennessy <greg.hennessy at cox.net> writes:
: : 
: : 
: : M. Warner Losh wrote:
: : > In message: <495AFFEA.7020808 at cox.net>
: : >             Greg Hennessy <greg.hennessy at cox.net> writes:
: : > :  > It also agrees with the
: : > :  > USNO web pages, as well as the BIPM web pages.  Would you like the
: : > :  > URLs?
: : > : 
: : > : Since I don't consider them relavent, no thank you.
: : > 
: : > The problem is that GMT means several different things.  It is an
: : > ambiguous term.
: : 
: : Thank you, you have finally acknowledged the point I making.
: : 
: : And you were able to do it without the personal insult you sent
: : to my private email account.

Yea, I'd like to apologize for that...  that was bad on my part...

: : Given that GMT can mean more than one timescale, is a person
: : or group necessarily wrong when using the term?
: 
: Yes.  They are wrong.  They are misusing a term, although it is a
: common mistake.  The proper term for UTC is UTC.  While others may
: call it by other names, that shows an ignorance on their part of the
: underlying details.  This lack of precision is but one example of why
: it is hard to get this stuff right.  To get things right, you have to
: use the right terms, not fuzzy, the public thinks it is right terms.

I guess the argument here boils down to this.  Greg is saying that
there exists a definition of GMT such that NASA is right.  In such a
case, you can point to the definition and be done with it.

I'm saying that there exists too many definitions of GMT so NASA is
wrong to use the term.  There's an ambiguity in the reader's mind that
makes it a bad choice and can create confusion...

Warner

From seaman at noao.edu  Wed Dec 31 13:31:06 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 11:31:06 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231.104018.570084810.imp@bsdimp.com>
References: <50557.1230739753@critter.freebsd.dk>
	<20081231162430.GA1039@ucolick.org>
	<EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5@noao.edu>
	<20081231.104018.570084810.imp@bsdimp.com>
Message-ID: <EB7BDF0D-3B23-4891-960D-A2D0FF67E0B6@noao.edu>

Without trivializing the details, what you are describing could  
equally be taken as an argument for getting rid of GPS :-)  Nobody is  
suggesting this, since GPS is useful.  I'll skip my disclaimer about  
there being two kinds of time, but if a system requires two timescales  
then it must handle the edge cases.  And if it doesn't require two  
timescales, the edge cases shouldn't appear.  Your edge cases  
themselves remind me of similar issues with astrometric solutions.   
Getting these right can be a challenge.  That doesn't mean that there  
isn't a requirement to get them right.

However, your description is similar to nothing so much as arguments  
against using the metric system that focus on a bunch of paradigm  
smashing conversions to avoirdupois.  The point I was trying to make  
was that the ITU could simply focus exclusively on GPS.  As I said,  
the standard time issue would then be a separate question and you  
would be free to make a case for your point of view.  In fact, the ITU  
could pawn off standard time on some other organization entirely.   
Don't they only care about telecommunications infrastructure?  Aren't  
they the ones claiming that civil timekeeping is something else  
entirely?

In the mean time, you presumably wouldn't have to pay a 20 minute  
penalty if you aren't using the UTC features.  Considering that the  
ITU's vision of UTC in the future still wouldn't be GPS, it is by no  
means clear that the 20 minute overhead would go away.  Sounds like  
another good issue to explore to improve the proposal.

Why does the ITU itself appear to dislike GPS?

Rob
---

On Dec 31, 2008, at 10:40 AM, M. Warner Losh wrote:

> In message: <EA44A9B7-8C68-4B1E-B1D8-0DC35B4E8FA5 at noao.edu>
>            Rob Seaman <seaman at noao.edu> writes:
> : Steve Allen wrote:
> :
> : > We have seen that the international timekeepers of the BIPM get  
> livid
> : > when someone suggests that GPS time could be used in an official
> : > sense.
> : > The IERS seems to be a bit more mellow.
> :
> : Does anybody have insight into what the real issue is with simply
> : adopting GPS time?  It has long seemed that UTC is simply caught  
> in a
> : crossfire between two factions of the precision timekeeping  
> community.
> :
> : If the ITU position were simply to stop distributing UTC and to  
> start
> : distributing GPS (or some TI = GPS offset to avoid a jump), this  
> whole
> : debate we are having would simply go away.  We'd work around the new
> : standard.  Whether or not standard time would end up layered on UTC/
> : GMT or on GPS/TI would make for an entertaining discussion, but it
> : would be a very different discussion.
> :
> : Rather, the ITU is seeking to redefine UTC, and apparently GMT,
> : perhaps just as some gambit in a funding war or academic dispute.
> :
> : What's wrong with GPS?  Astronomers use it all the time, very
> : productively.
>
> In the software that I wrote, I adapted a time scale similar to GPS
> time.  There were no leap seconds in this time scale.  This made the
> high precision math that was used to measure clocks and the like work
> out in the face of leap seconds.  It made sure that certain measuring
> events happened at the right time or the right interval.
>
> However, it presented a number of challenges.  The biggest one was
> that you had to know the number of leap seconds for the current time
> before you could start up.  Either you were fed the GPS time, in which
> case you needed them to display the UTC time to the user, set the
> atomic clocks to the proper UTC time, get ntpd going with the proper
> UTC time, etc.  Or you had UTC time and didn't know the offset to the
> GPS time and had to wait for it to start the rest of the system.
>
> While knowing this seems trivial, it is anything but for many common
> scenarios.  The data is in the GPS stream, but a cold receiver can
> take up to 20 minutes to deliver this data, which interferes with the
> startup time specifications we had to meet.  For systems that didn't
> have a GPS receiver, there's no widely deployed way to get this data.
> NTP can provide it, but most NTP servers don't (and if you are an NTP
> server that's disconnected, it can be hard to fabricate the necessary
> tables).  There's ftp sites on the net that one can get it from, but
> firewalls in the way often times in the installations I've used.  One
> can mitigate these effects somewhat (knowing when you last knew when
> the next leap second could be would help all but the coldest of spares
> pulled off the shelf cases), but there are still edge cases that
> remain.
>
> Plus, even though we were using C++ that provided a number of
> different ways to try to get the time scale right all the time,
> several ways were found to slip through the cracks.  Time scale
> confusion was often a subtle bug to find (but easy to spot: my times
> are off by 34s!).  The multiplicity of the time scales also increased
> the complexity of the programs.
>
> In addition, we found that it was hard to exhaustively test different
> leap second scenarios.  In one set of tests we thought we'd covered
> everything (both positive and negative leap seconds).  However, we
> neglected the case where there was no leap second at the prior leap
> second opportunity (meaning December or June) and there's no leap
> second this opportunity, then bad things would happen due to an array
> overflow.  There were many other similar bugs that were found outside
> of testing, but this one illustrates the complexities that are faced
> when trying to get this pedantically correct for all cases.
>
> So if there were multiple time scales propagated, there would still be
> these problems so long at UTC was mandated anywhere in the system
> design.
>
> These are some of the practical problems associated with having to
> cope with multiple time scales.  I'm sure there are many others.
>
> Warner


From zefram at fysh.org  Wed Dec 31 15:15:19 2008
From: zefram at fysh.org (Zefram)
Date: Wed, 31 Dec 2008 20:15:19 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <p06230909c580a7166c0a@[192.168.0.5]>
References: <495A7453.29508.11EE2652@dan.tobias.name>
	<20081230.175727.1306326652.imp@bsdimp.com>
	<62AE92E0-8CF7-494D-96A4-E1EBAE4BA0E5@noao.edu>
	<20081230.194608.1172766174.imp@bsdimp.com>
	<ED8B39FB-5F33-451B-9907-7D06B14F903D@noao.edu>
	<p06230909c580a7166c0a@[192.168.0.5]>
Message-ID: <20081231201519.GS2263@fysh.org>

Jonathan E. Hardis wrote:
>>we also learn that "Universal Time (UT) is the general designation 
>>of time scales based on the rotation of the Earth."
>
>Then it's not very "Universal," now is it?

It's not Time either, and so is quite comprehensively misnamed.  Much like
the Holy Roman Empire and the Indian Civil Service.

-zefram

From greg.hennessy at cox.net  Wed Dec 31 16:05:19 2008
From: greg.hennessy at cox.net (Greg Hennessy)
Date: Wed, 31 Dec 2008 16:05:19 -0500
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <20081231.111255.846952744.imp@bsdimp.com>
References: <20081230.230002.-467811804.imp@bsdimp.com>	<495B7242.4030006@cox.net>	<20081231.102326.195751037.imp@bsdimp.com>
	<20081231.111255.846952744.imp@bsdimp.com>
Message-ID: <495BDE8F.1030907@cox.net>


> I guess the argument here boils down to this.  Greg is saying that
> there exists a definition of GMT such that NASA is right.  In such a
> case, you can point to the definition and be done with it.

While perhaps not a definition, the grounds of what used
to be RGO are now apparently the UK National Maritime
Museum, and they assert that GMT is the same as UTC.

http://www.nmm.ac.uk/explore/astronomy-and-time/time-facts/the-new-millennium


From seaman at noao.edu  Wed Dec 31 18:55:04 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 16:55:04 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48968.1230722428@critter.freebsd.dk>
References: <48968.1230722428@critter.freebsd.dk>
Message-ID: <B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>

Just sitting here watching the Nixie tube page ticking along:

	http://leapsecond.com/java/nixie.htm

I have Hard Day's Night on the HD for a sound track.  Somehow seemed  
appropriate.

Dropped by our sysadmin's office earlier.  He didn't look too  
frantic.  One reason (no irony intended) is that we rely on FreeBSD  
for various critical infrastructure at the observatory.

On Dec 31, 2008, at 4:20 AM, Poul-Henning Kamp wrote:

> The FreeBSD kernel Warner and I have worked on for 15 years approaches
> 5 million lines of code.

Good job boys!

We do have systems in astronomy of that level of complexity,  
including, for instance our widely distributed image processing  
system, layered on a virtual operating system of complexity similar to  
BSD.  Its kernel has networking built in down to the bedrock - any  
resource can be either local or remote.  The exact same high level  
source code runs not only on a wide swath of both BSD and Sys V  
unixes, but also back in the day ran verbatim on VMS and Data General  
OSes.  There are very tricky bits in the VOS as well as vast numbers  
of applications with clever algorithms.

Of more recent vintage, you might peruse various "virtual observatory"  
projects around the globe.  Just to point to something completely  
different, I heartily recommend the Microsoft Research World Wide  
Telescope and Google Sky.

> For comparison, the US navy touted the complexity of the Air
> craft carrier Ronald Reagan (CVN-76), by boasting that it was
> built from "more than one million individually tracked pieces".

Yes indeed.  Management never quite seems to get the complexity of  
software.  You might query on "ALMA" and "LSST" for a sense for the  
scale of some current projects.

On the other hand, note that those aircraft carrier pieces each have  
equivalent complexity of much greater than the 5 lines of code implied  
by an assertion of parity.  (And of course, presumably include  
hundreds or thousands of onboard computers.)

> Back when computers had just broken the 32 kilowords barrier, one
> of the greatest thinkers in computer science wrote:

Another appropriate quote from Dijkstra:

	"Computer science is no more about computers than astronomy is about  
telescopes."

:-)

> We have no way to upgrade our programmers, we can only make the
> task in front of them simpler.

One might reference the Mythical Man Month here, too.

> The fact that you cannot see the problem, does not make it a non- 
> problem,
> people like Warner and me have seen the problems, we know they are  
> there.

Well, perhaps we haven't been clear enough that we do understand what  
problem you are talking about.  We just disagree about the solution.

> If you don't trust us, how about this:
>
> 	Judah Levine of the National Institute of Standards and
> 	Technology in Boulder, Colorado, which provides the time
> 	standard and technical support for most commercial activities
> 	in the US is braced for New Year's Eve. "On December 31,
> 	I'll be waiting with a cup of coffee for the problems to
> 	roll in," he sighs.
>
> 	http://www.newscientist.com/article/mg20026875.400-calls-to-scrap-the-leap-second-grow.html

Yeah, I didn't think much of that article.

For those that dig back to the depths of the archives of this list and  
prior discussions, I should mention that it was Levine who kickstarted  
the interest of the astronomical software community in this issue.  JL  
contacted an astronomer in northern Arizona, who contacted the  
National Observatory in southern Arizona.  It naturally wended its way  
to my desk.  I believe this was the first public message:

	http://listmgr.cv.nrao.edu/pipermail/fitsbits/1999-December/000949.html

Just a reminiscence as we close out another year.

Happy New Year!

Back to watching the clock.

Rob



From ashley at semantic.org  Wed Dec 31 19:01:45 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Wed, 31 Dec 2008 16:01:45 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
Message-ID: <1230768105.29954.83.camel@glastonbury>

On Wed, 2008-12-31 at 16:55 -0700, Rob Seaman wrote:
> Just sitting here watching the Nixie tube page ticking along:
> 
> 	http://leapsecond.com/java/nixie.htm
> 
> I have Hard Day's Night on the HD for a sound track.  Somehow seemed  
> appropriate.

The leap second having passed, the Nixie clock is now counting
backwards. I guess PHK and Warner were right after all?

Happy Leap Second!

-- 
Ashley


From seaman at noao.edu  Wed Dec 31 19:05:25 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 17:05:25 -0700
Subject: [LEAPSECS] New Year's Fools!
Message-ID: <909388E2-AB33-4F63-8A09-917CA1430FE2@noao.edu>

Very cute!

Unfortunately, it just demanded I reload.


From sla at ucolick.org  Wed Dec 31 19:06:10 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 31 Dec 2008 16:06:10 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <1230768105.29954.83.camel@glastonbury>
References: <48968.1230722428@critter.freebsd.dk>
	<B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
	<1230768105.29954.83.camel@glastonbury>
Message-ID: <20090101000610.GA12087@ucolick.org>

On Wed 2008-12-31T16:01:45 -0800, Ashley Yakeley hath writ:
> The leap second having passed, the Nixie clock is now counting
> backwards. I guess PHK and Warner were right after all?

I think javascript is nobody's favorite language.  Fortunately (after
much testing and two or three significant recodings) mine worked
http://www.ucolick.org/~sla/leapsecs/epochtime.html
and it now shows that all us in the US and Quebec
deserve congratulations for having experienced our >
first legal leap second.

Happy New Year!

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Wed Dec 31 19:30:35 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 01 Jan 2009 00:30:35 +0000
Subject: [LEAPSECS] Time is hard...
In-Reply-To: Your message of "Wed, 31 Dec 2008 17:05:25 MST."
	<909388E2-AB33-4F63-8A09-917CA1430FE2@noao.edu> 
Message-ID: <51795.1230769835@critter.freebsd.dk>


Happy new year and leap-second.

Further evidence that average programmers should not be let near
timekeeping:

http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From sla at ucolick.org  Wed Dec 31 19:40:56 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 31 Dec 2008 16:40:56 -0800
Subject: [LEAPSECS] Time is hard...
In-Reply-To: <51795.1230769835@critter.freebsd.dk>
References: <909388E2-AB33-4F63-8A09-917CA1430FE2@noao.edu>
	<51795.1230769835@critter.freebsd.dk>
Message-ID: <20090101004056.GA12138@ucolick.org>

On Thu 2009-01-01T00:30:35 +0000, Poul-Henning Kamp hath writ:
> http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail

So because of failure to implement a standard that has been published
for over 400 years the Zune will fail every 4 years unless the
firmware is updated.

"Math is hard" -- talking Barbie

I could despair, but I'd rather go watch the CGI Barbie movie with my
A+ in math daughter and help play with her little sister's Barbies.
I choose hope.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Wed Dec 31 20:06:40 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 18:06:40 -0700
Subject: [LEAPSECS] Time is hard...
In-Reply-To: <51795.1230769835@critter.freebsd.dk>
References: <51795.1230769835@critter.freebsd.dk>
Message-ID: <20DCC329-5CCA-45D1-BC9A-2742DA96AAD1@noao.edu>

Poul-Henning Kamp wrote:

> Happy new year and leap-second.
>
> Further evidence that average programmers should not be let near  
> timekeeping:
>
> http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail

Not to discount the bug reported, but there are lots of other more  
complex issues with such a device.  In addition to the question of why  
the Zune should care particularly about the date in the first place -  
something to do with syncing with the mothership?  The bug's  
description online, including the official support page, is really poor.

Knowing a little something about data compression, I would suggest  
that such a device has lots of much more complex and subtle  
compression issues.  Also a variety of embedded device issues,  
encryption issues, etc.

One could say that an "average" programmer shouldn't be allowed to  
work on encryption without thoroughly digesting Bruce Schneier's  
books.  I think rather highly of Dave Mills' NTP book, but if one  
could find a copy on the shelf of your local Borders, it would be  
dwarfed by the number of security books, itself not a huge segment of  
the computer section of a bookstore.  All those ITU "above-average"  
experts could have better spent the past nine years writing a few more  
books to describe what they do for a living.

What precisely is an "average" programmer, anyway?  This is a very  
multimodal discipline.  There mostly appear to be OS kernel/device  
driver hackers and scientific programmers on this list.  The  
observatory just rolled out a new web page, an entirely different  
regime of expertise.  My brother-in-law works in banking, originally  
Cobal.  GUI programmers.  We employ a lot of instrument programmers  
who use anything from C++ to LabVIEW to microcode.  Telescope control  
system programmers who use various messaging protocols.  Pipeline  
programmers.  Our archive is an Enterprise Java code base.  XML.   
Databases.  (All our best DB programmers eventually end up getting  
hired away by Amazon or Google.)  Grid and parallel processing - much  
harder than leap seconds.  And dozens of other major divisions.

I can personally attest to the stupid lpd tricks the BSD line printer  
daemon can be jollied into doing :-)  (CUPS isn't nearly as flexible.)

It's been an hour.  Anything blow?

Rob



From tvb at LeapSecond.com  Wed Dec 31 20:12:34 2008
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 31 Dec 2008 17:12:34 -0800
Subject: [LEAPSECS] Schedule for success
References: <48968.1230722428@critter.freebsd.dk><B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
	<1230768105.29954.83.camel@glastonbury>
Message-ID: <E320480378A940909607115ED9F9C89F@pc52>

> On Wed, 2008-12-31 at 16:55 -0700, Rob Seaman wrote:
>> Just sitting here watching the Nixie tube page ticking along:
>> 
>> http://leapsecond.com/java/nixie.htm
>> 
>> I have Hard Day's Night on the HD for a sound track.  Somehow seemed  
>> appropriate.
> 
> The leap second having passed, the Nixie clock is now counting
> backwards. I guess PHK and Warner were right after all?

Yeah, I need to fix that JavaScript code. Sorry.
/tvb

> 
> Happy Leap Second!
> 
> -- 
> Ashley



From tvb at LeapSecond.com  Wed Dec 31 20:18:42 2008
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 31 Dec 2008 17:18:42 -0800
Subject: [LEAPSECS] New Year's Fools!
References: <909388E2-AB33-4F63-8A09-917CA1430FE2@noao.edu>
Message-ID: <C94D344FA7BD476FB57655A484504CEA@pc52>

From: "Rob Seaman" <seaman at noao.edu>
> Very cute!
> 
> Unfortunately, it just demanded I reload.

Yeah, I had to put that in because some browsers apparently did
not cache the nixie tube images correctly. The result was that my
web site would get hammered for hours serving every digit every
second.

/tvb


From seaman at noao.edu  Wed Dec 31 21:13:59 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 19:13:59 -0700
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
Message-ID: <210E7F04-099E-4F44-8FE9-EB6D31D17B19@noao.edu>

On Dec 31, 2008, at 4:55 PM, Rob Seaman wrote:

> For those that dig back to the depths of the archives of this list  
> and prior discussions, I should mention that it was Levine who  
> kickstarted the interest of the astronomical software community in  
> this issue.  JL contacted an astronomer in northern Arizona, who  
> contacted the National Observatory in southern Arizona.  It  
> naturally wended its way to my desk.  I believe this was the first  
> public message:
>
> 	http://listmgr.cv.nrao.edu/pipermail/fitsbits/1999-December/000949.html

I've had a pleasant time rereading a few of the messages from that  
thread.  Rather amusing how many of the familiar tropes were laid out  
within 2 days of the first post.  It sounds like there was a  
contemporaneous thread over in the NTP community.  It could be  
interesting to compare the two.

One thing to note in addition to the stunned perception at the hubris  
of the notion was the willingness among the astronomers to debate the  
proposal.  Another thing to note is that from that day to this the ITU  
proposal has not wavered one whit in response.  One really has to  
think that we could have more luck considering alternate possibilities.

Rob


From seaman at noao.edu  Wed Dec 31 22:29:14 2008
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 31 Dec 2008 20:29:14 -0700
Subject: [LEAPSECS] Time is hard...
In-Reply-To: <51795.1230769835@critter.freebsd.dk>
References: <51795.1230769835@critter.freebsd.dk>
Message-ID: <C12083FB-B866-4036-ADE6-85FD17820E4D@noao.edu>

On Dec 31, 2008, at 5:30 PM, Poul-Henning Kamp wrote:

> Further evidence that average programmers should not be let near  
> timekeeping:
>
> http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail

Slashdot is having fun with this:

	"I sense a disturbance in the Force... It's as if tens of voices  
cried out in terror and were silenced."

http://it.slashdot.org/article.pl?sid=08/12/31/1428254

From sla at ucolick.org  Wed Dec 31 23:09:36 2008
From: sla at ucolick.org (Steve Allen)
Date: Wed, 31 Dec 2008 20:09:36 -0800
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <46756.1230687766@critter.freebsd.dk>
References: <20081231012433.GA14690@ucolick.org>
	<46756.1230687766@critter.freebsd.dk>
Message-ID: <20090101040936.GA18332@ucolick.org>

On Wed 2008-12-31T01:42:46 +0000, Poul-Henning Kamp hath writ:
> In message <20081231012433.GA14690 at ucolick.org>, Steve Allen writes:
> >On Tue 2008-12-30T17:57:27 -0700, M. Warner Losh hath writ:
> >> If rocket-scientists can't get the relatively simple nomenclature of
> >> this topic right, what hope is there for the average engineer?
> >
> >Not enough in the current scenario, given that the ITU-R docs are
> >proprietary to the point of inaccessability [...]
>
> We're clawing for straws now, aren't we ?  :-)

No, I don't think so.  See this blog entry from someone on
the crew of folks defining XML for W3C.

http://cmsmcq.com/mib/?p=271

Perhaps not every member of the W3C has been driven to the point of
talking with himself over the inconsistent picture painted by the
authorities responsible for the leap second, but this one has.

In the case of the Zune the standard was broadly disseminated over
400 years ago, and mass marketing of a product that does not conform
may even be considered negligent to the point of culpability.

But no manufacturer can be blamed for products which cannot figure out
what the rules for the leap second really are, or who's in charge of
those rules.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m