From dan at tobias.name  Thu Jan  1 00:08:19 2009
From: dan at tobias.name (Daniel R. Tobias)
Date: Thu, 01 Jan 2009 00:08:19 -0500
Subject: [LEAPSECS] Happy New Year....
Message-ID: <495C0973.14402.181CC4F2@dan.tobias.name>

It just reached midnight here in the U.S. Eastern time zone... the 
time counting toward midnight on ABC's New Years Rockin' Eve didn't 
show a leap second (I think somebody earlier on this list claimed 
those shows went "58-59-LEAP-00", but this one didn't), and of course 
was correct here since the leap second was hours ago.  I'm not sure 
what time source Times Square and ABC sync to; it was a few seconds 
off from my computer and my watch, both of which supposedly keep 
synced regularly through UTC time signals.

Anyway, we're past the leap second without planes falling from the 
sky or, as far as I know after seeing the 11:00 newscast, people 
dropping dead from horrible leap-second-related accidents, so I think 
the hyperbole of people on this list who say "Leap seconds will KILL! 
 Think of the CHILDREN!" are as overblown as the Y2K fearmongers 
were.  Meanwhile, the good old leap YEAR had a victim in the 
Micro$oft Zume players, so are we going to see calls to abolish leap 
days because programmers get them wrong, so all years should just be 
365 days long and it doesn't matter if the dates of the year rotate 
through the seasons... the Muslims deal with it in THEIR calendar, 
after all.

-- 
== 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  Thu Jan  1 00:57:41 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 1 Jan 2009 05:57:41 +0000
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: <alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>

On Tue, 30 Dec 2008, M. Warner Losh wrote:
>
> Time used to be strongly coupled to the earth.

Only because it was the most accurate clock we had. It might still be the
most reliable clock we have but our natural tendency to optimisation means
that isn't the most important consideration.

> 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.

Actually I would say that mean solar time was (past tense deliberate) was
a temporary aberration, lasting from mechanical clocks replacing the
sundial, to the rise of DST. Really, mean solar time only started to rule
our lives when we became industrialised and therefore ruled by the clock
rather than the sun, so I would date it to the establishment of railway
time: between the the 1840s in Britain and the development of timezones in
the 1870s in North America. The popularity of DST is because people prefer
to synch to sunrise instead of noon, and it wasn't long after the takeover
of mean solar time that the DST rebellion occurred, about 75 years.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
PLYMOUTH BISCAY: EAST OR SOUTHEAST 5 TO 7, DECREASING 3 OR 4 IN SOUTH BISCAY.
MODERATE OR ROUGH. RAIN OR SHOWERS, BUT FAIR IN PLYMOUTH. MODERATE OR GOOD,
OCCASIONALLY POOR.

From dot at dotat.at  Thu Jan  1 01:10:59 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 1 Jan 2009 06:10:59 +0000
Subject: [LEAPSECS] the leap second in the media
Message-ID: <alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk>

The Guardian soeaks to Peter Whibberley, "a senior research scientist at
the National Physical Laboratory". There's discussion about the future of
leap seconds, and he's against any change in line with the UK's national
policy as we saw in the WP7a summary.

http://www.guardian.co.uk/science/2008/dec/30/leap-second-new-year

Wednesday's PM on Radio 4 included an item about the way the keepers of
the Big Ben clock handled the leap second. They slowed it down for several
hours by removing a stack of old coins from a plate near the top of the
pendulum to lower its centre of gravity. They replaced them again when it
had lost a seond. Rubber seconds, 19th century style! You can still get
the episode (usng realplayer) until about 17:00 UTC from this link:

http://www.bbc.co.uk/radio4/news/pm/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FORTIES: NORTHERLY 4 OR 5, OCCASIONALLY 6 LATER IN EAST. MODERATE OR ROUGH,
BUT SLIGHT IN SOUTH FOR A TIME. SHOWERS. MAINLY GOOD.

From dwmalone at maths.tcd.ie  Thu Jan  1 04:15:56 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Thu, 01 Jan 2009 09:15:56 +0000
Subject: [LEAPSECS] the leap second in the media
In-Reply-To: Your message of "Thu, 01 Jan 2009 06:10:59 GMT."
	<alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk> 
Message-ID: <200901010915.aa85027@walton.maths.tcd.ie>

> Wednesday's PM on Radio 4 included an item about the way the keepers of
> the Big Ben clock handled the leap second. They slowed it down for several
> hours by removing a stack of old coins from a plate near the top of the
> pendulum to lower its centre of gravity. They replaced them again when it
> had lost a seond. Rubber seconds, 19th century style! You can still get
> the episode (usng realplayer) until about 17:00 UTC from this link:

> http://www.bbc.co.uk/radio4/news/pm/

There's also some video associated with that story, so you can
see the pennies:

	http://news.bbc.co.uk/2/hi/science/nature/7797818.stm

and some mention of Peter Whibberley.

	David,

From lang at unb.ca  Thu Jan  1 07:24:06 2009
From: lang at unb.ca (Richard B. Langley)
Date: Thu,  1 Jan 2009 08:24:06 -0400
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: <1230812646.495cb5e6f2587@webmail.unb.ca>

Quoting Rob Seaman <seaman at noao.edu>:

> 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:

Depending on what "public" means. The article in my GPS World Innovation column appeared
in the November 1999 issue. ;-)

===============================================================================
 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 Jan  1 08:08:35 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 06:08:35 -0700
Subject: [LEAPSECS] Pentagon Papers
In-Reply-To: <1230812646.495cb5e6f2587@webmail.unb.ca>
References: <48968.1230722428@critter.freebsd.dk>
	<B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
	<1230812646.495cb5e6f2587@webmail.unb.ca>
Message-ID: <C110C940-B6B8-4CD1-94A5-51212DE4BAA7@noao.edu>

Richard B. Langley wrote:

> Quoting Rob Seaman <seaman at noao.edu>:
>
>> 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:
>
> Depending on what "public" means. The article in my GPS World  
> Innovation column appeared
> in the November 1999 issue. ;-)

Actually, it depends what "message" means - I was referring to bloggy/ 
webby/usenet things.  I've often referenced the GPS World article as  
the normative reference, in particular when trying to make the point  
that there are more ways to address the issue than the ITU's  
monomaniacal focus on simply forgetting the whole requirement and  
ceasing leap seconds.

Hmmm.  It would be interesting to do some traffic analysis on  
publications, both online and print.  Obviously they align with leap  
seconds, but it's also seemed kind of interesting that GPS World  
kicked it off, but GPS itself seems to be spurned as a "serious"  
candidate.  Ignoring slice of life publications like Harpers, how have  
the print media been selected and who is doing the selection?

Obviously the issue must have been discussed for a long time in the  
hushed antechambers of Galifrey before the Timelords sought  
consultation through either paper or digital media.  Where is Daniel  
Ellsberg when you need him?

Rob


From phk at phk.freebsd.dk  Thu Jan  1 09:21:32 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 01 Jan 2009 14:21:32 +0000
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
Message-ID: <55773.1230819692@critter.freebsd.dk>


DCF77 got right, as always.

HBG also got it right this time.

MSF still fumbles the DUT1 bits.

http://phk.freebsd.dk/Leap/20081231/

-- 
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  Thu Jan  1 11:10:10 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 1 Jan 2009 16:10:10 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <48968.1230722428@critter.freebsd.dk>
References: <48968.1230722428@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>

On Wed, 31 Dec 2008, Poul-Henning Kamp wrote:
>
> 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/

It's hardly surprising that leap seconds are never handled correctly when
all time dissemmination systems have to be manually configured each time.
The lack of automation is a recipe for mistakes, but leap seconds can't be
automated because they don't occur on a predictable schedule.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SHANNON ROCKALL MALIN HEBRIDES BAILEY: SOUTHEAST 5 OR 6, BUT OCCASIONALLY 7 AT
FIRST IN SHANNON AND BAILEY, DECREASING 4 OR 5 LATER IN HEBRIDES. ROUGH BUT
VERY ROUGH AT FIRST IN WEST, BECOMING MODERATE IN EAST. MAINLY FAIR, BUT RAIN
AT FIRST IN SHANNON. MODERATE OR GOOD.

From sla at ucolick.org  Thu Jan  1 11:17:12 2009
From: sla at ucolick.org (Steve Allen)
Date: Thu, 1 Jan 2009 08:17:12 -0800
Subject: [LEAPSECS] Pentagon Papers
In-Reply-To: <C110C940-B6B8-4CD1-94A5-51212DE4BAA7@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<B30E593E-EE6E-4E5B-AAC6-60DE9E9DCBAA@noao.edu>
	<1230812646.495cb5e6f2587@webmail.unb.ca>
	<C110C940-B6B8-4CD1-94A5-51212DE4BAA7@noao.edu>
Message-ID: <20090101161712.GA20237@ucolick.org>

On Thu 2009-01-01T06:08:35 -0700, Rob Seaman hath writ:
> Hmmm.  It would be interesting to do some traffic analysis on
> publications, both online and print.

Recall that William Markowitz, whose urgent hard work resulted in the
choice of the length of the atomic second as well as contributing to
the existence of the flavors of UT0, UT1, UT2 died 1998-10-10
http://ad.usno.navy.mil/wds/history/markowitz.html

Then at the 33rd CGSIC meeting on 1999-03-18 William Klepczinski
gave a presentation suggesting abandoning leap seconds.

Than at the 31st PTTI on 1999-12-07/09 was their first panel
discussion on the subject.

--
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  Thu Jan  1 11:19:33 2009
From: lang at unb.ca (Richard B. Langley)
Date: Thu,  1 Jan 2009 12:19:33 -0400
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
In-Reply-To: <55773.1230819692@critter.freebsd.dk>
References: <55773.1230819692@critter.freebsd.dk>
Message-ID: <1230826773.495ced1569212@webmail.unb.ca>

CHU got it right this time. Last time there was a change in the DUT1 value effective 1
January in addition to the leap second. The notice from IERS was sent late and the
people responsible for inputting the new DUT1 value were already on their Christmas/New
Year break when it arrived.

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:

> 
> DCF77 got right, as always.
> 
> HBG also got it right this time.
> 
> MSF still fumbles the DUT1 bits.
> 
> http://phk.freebsd.dk/Leap/20081231/
> 
> -- 
> 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
> 


===============================================================================
 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 Jan  1 11:41:41 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 09:41:41 -0700
Subject: [LEAPSECS] Automation
In-Reply-To: <alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
Message-ID: <151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>

Tony Finch wrote:

> The lack of automation is a recipe for mistakes, but leap seconds  
> can't be automated because they don't occur on a predictable schedule.

They can't be naively automated.  The schedule is currently  
predictable 6 months in advance.  Nobody has objected to a longer  
schedule; we're positively giddy to give it a try.  NTP is proof of  
concept that automation is possible once the schedule is released.

Of course, the benefits of naive automation are precisely what the ITU  
is trying to take away from UTC.  Leap seconds are the price of  
preserving easy access to knowledge of Earth orientation.

Since the problem space has never been fully explored, we haven't even  
speculated on ways to improve the automation associated with  
timekeeping.

Rob


From dot at dotat.at  Thu Jan  1 12:33:45 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 1 Jan 2009 17:33:45 +0000
Subject: [LEAPSECS] Automation
In-Reply-To: <151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
Message-ID: <alpine.LSU.2.00.0901011729500.14215@hermes-1.csi.cam.ac.uk>

On Thu, 1 Jan 2009, Rob Seaman wrote:
>
> NTP is proof of concept that automation is possible once the schedule is
> released.

Yes for high stratum clients, but the lowest stratum servers need their
leap second file kept up-to-date, which is a manual task that is often not
performed correctly. That's why I said it's the dissemination systems that
need manual adjustment, not the receiving systems.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FAIR ISLE: NORTHERLY OR NORTHEASTERLY 4 OR 5, BECOMING VARIABLE 3 OR LESS FOR
A TIME, THEN SOUTHWESTERLY 3 OR 4. MODERATE, BUT ROUGH AT FIRST IN NORTH.
SHOWERS, THEN FAIR. GOOD.

From dot at dotat.at  Thu Jan  1 13:02:02 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 1 Jan 2009 18:02:02 +0000
Subject: [LEAPSECS] Schedule for success
In-Reply-To: <495B257E.27731.14A24046@dan.tobias.name>
References: <Your message of "Tue, 30 Dec 2008 19:01:00 MST."
	<20081230.190100.-1916658631.imp@bsdimp.com> >,
	<48139.1230710913@critter.freebsd.dk>
	<495B257E.27731.14A24046@dan.tobias.name>
Message-ID: <alpine.LSU.2.00.0901011751501.14215@hermes-1.csi.cam.ac.uk>

On Wed, 31 Dec 2008, Daniel R. Tobias wrote:
> 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?)

The meridian moved several times. About a year ago I wrote the
following...

When GMT was chosen to be UT at the Washington conference in 1884, there
was a requirement that the prime meridian passed through the transit
instrument of a good observatory which could thereby keep the time on
which longitude depended. By the start of WWI, people were developing
long-distance precision time transfer using radio telegraphy, so the
dependence on a single observatory and master clock was no longer
necessary or desirable. The French established the Bureau International de
l'Heure (BIH) which defined and maintained time and longitude based on
observations from multiple observatories, and thereby took back what they
had lost three decades previously at the Washington meridian conference.

This should have made no difference, but owing to longstanding
inaccuracies in the official longitudes of the various observatories, the
zero longitude of the BIH's geodetic model no longer matched the Airy
transit circle at Greenwich. Further errors (of about 10m) were introduced
when the Royal Observatory moved from Greenwich to Herstmonceaux after
WWII. The biggest change, however, happened when the standard geodetic
model was fixed to be geocentric, i.e. to have a common centre of
revolution with the Earth. Although the new model matched the old fairly
well at the equator, it ended up being off by about 100m at Greenwich.
This discrepancy is still preserved by WGS84, the world geodetic system
used by GPS. If you go to Greenwich you'll find that not only does your
GPS receiver disagree with the markings on the ground, but also your
Ordnance Survey maps - because the OS uses a datum established before the
construction of the Airy transit circle.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FAIR ISLE: NORTHEASTERLY 4 OR 5, BECOMING VARIABLE 3 OR LESS FOR A TIME, THEN
WESTERLY OR SOUTHWESTERLY 4 OR 5. MODERATE, BUT ROUGH AT FIRST IN NORTH.
MAINLY FAIR. GOOD.

From imp at bsdimp.com  Thu Jan  1 13:22:05 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 01 Jan 2009 11:22:05 -0700 (MST)
Subject: [LEAPSECS] Automation
In-Reply-To: <151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
Message-ID: <20090101.112205.-1350498354.imp@bsdimp.com>

In message: <151A3828-174F-41DB-917A-0C98C8430DCD at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Tony Finch wrote:
: 
: > The lack of automation is a recipe for mistakes, but leap seconds  
: > can't be automated because they don't occur on a predictable schedule.
: 
: They can't be naively automated.  The schedule is currently  
: predictable 6 months in advance.

That's not much of a prediction.  No offense to the current Bulletin C
folks, but 6 months is way too short a time frame for proper
coordination.

: Nobody has objected to a longer  
: schedule; we're positively giddy to give it a try.  NTP is proof of  
: concept that automation is possible once the schedule is released.

Well, ntpd does require manual intervention at the head end to work.
Some reference clocks (stratum 1) do light the leap second indicator
automatically, but not all.

: Of course, the benefits of naive automation are precisely what the ITU  
: is trying to take away from UTC.  Leap seconds are the price of  
: preserving easy access to knowledge of Earth orientation.
: 
: Since the problem space has never been fully explored, we haven't even  
: speculated on ways to improve the automation associated with  
: timekeeping.

If we must have leapseconds, we must put them on a better schedule
than 'we'll tell you 6 months in advance'.

If one accepts > .9s tolerance, we can make our best guess now for the
next 10 years and be very likely to be very close.  We'd likely know
after 5 years how well we've done.  Having leap seconds on a
predictable schedule out many years would solve many of the
engineering problems that are faced today.

It still wouldn't solve the fact that POSIX time_t is fundamentally
incompatible with leap seconds.  It is incapable of expressing
23:59:60 unambiguously.  The obvious solution of running in 'TAI' time
breaks a lot of code because lots of code assumes it knows how to do
the math itself.  In addition, there's no difference between
2008-12-31 23:59:60 and 2009-01-01 00:00:00 when encoded in a struct
tm, due to the normalization rule.

Warner

From seaman at noao.edu  Thu Jan  1 14:21:17 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 12:21:17 -0700
Subject: [LEAPSECS] Automation
In-Reply-To: <20090101.112205.-1350498354.imp@bsdimp.com>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
	<20090101.112205.-1350498354.imp@bsdimp.com>
Message-ID: <E0C97FD0-1B5E-4A56-8D5B-61BA5FF3AAE9@noao.edu>

M. Warner Losh wrote:

> If we must have leapseconds, we must put them on a better schedule  
> than 'we'll tell you 6 months in advance'.
>
> If one accepts > .9s tolerance, we can make our best guess now for  
> the next 10 years and be very likely to be very close.  We'd likely  
> know after 5 years how well we've done.  Having leap seconds on a  
> predictable schedule out many years would solve many of the  
> engineering problems that are faced today.

Let's give it a try.  The online cache of Bulletin A at IERS only goes  
back to 2005.  Presumably the earlier ones are stashed somewhere.  Can  
we drill back a decade or two and see how well Bulletin B can be  
recovered in a longitudinal study?

Whether or not leap seconds survive the next decade, we can always  
benefit from improving their handling in the interim.  This may even  
make the whole thing moot.

Rob


From lang at unb.ca  Thu Jan  1 14:46:33 2009
From: lang at unb.ca (Richard B. Langley)
Date: Thu,  1 Jan 2009 15:46:33 -0400
Subject: [LEAPSECS] Automation
In-Reply-To: <E0C97FD0-1B5E-4A56-8D5B-61BA5FF3AAE9@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
	<20090101.112205.-1350498354.imp@bsdimp.com>
	<E0C97FD0-1B5E-4A56-8D5B-61BA5FF3AAE9@noao.edu>
Message-ID: <1230839193.495d1d99d39ab@webmail.unb.ca>

Quoting Rob Seaman <seaman at noao.edu>:

> Let's give it a try.  The online cache of Bulletin A at IERS only goes  
> back to 2005.  Presumably the earlier ones are stashed somewhere.  

<http://cddis.gsfc.nasa.gov/reports.html>

Also, data can be extracted from here:

<http://maia.usno.navy.mil/search/search.html>

Now, back to exam marking. Oh, and by the way, with reference to Time Lords, did anyone
else get a Tardis USB hub for Christmas? ;-)

===============================================================================
 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 ashley at semantic.org  Thu Jan  1 16:02:09 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Thu, 01 Jan 2009 13:02:09 -0800
Subject: [LEAPSECS] Automation
In-Reply-To: <151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
Message-ID: <1230843729.9555.2.camel@glastonbury>

On Thu, 2009-01-01 at 09:41 -0700, Rob Seaman wrote:
> They can't be naively automated.  The schedule is currently  
> predictable 6 months in advance.  Nobody has objected to a longer  
> schedule; we're positively giddy to give it a try.  NTP is proof of  
> concept that automation is possible once the schedule is released.

This might encourage software engineers to do the wrong thing, that is,
hard-code a leap-second table.

-- 
Ashley Yakeley


From seaman at noao.edu  Thu Jan  1 16:39:48 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 14:39:48 -0700
Subject: [LEAPSECS] Automation
In-Reply-To: <1230843729.9555.2.camel@glastonbury>
References: <48968.1230722428@critter.freebsd.dk>
	<alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
	<1230843729.9555.2.camel@glastonbury>
Message-ID: <B25E9B04-EA3F-4CCF-ADE2-A237B68A76C8@noao.edu>

Ashley Yakeley wrote:

> Rob Seaman wrote:
>
>> They can't be naively automated.  The schedule is currently
>> predictable 6 months in advance.  Nobody has objected to a longer
>> schedule; we're positively giddy to give it a try.  NTP is proof of
>> concept that automation is possible once the schedule is released.
>
> This might encourage software engineers to do the wrong thing, that  
> is,
> hard-code a leap-second table.

Only if the schedule is permitted to change after it is released.  For  
example, I just got finished updating the eleven cached telescope  
schedules for three mountaintops whose data I'm responsible for.  I  
typically do this on the last day of the month.  I let it slide last  
night, but halted the data transport system this morning and just  
restarted the DTS after updating the schedule.

The point is, I wait until the latest possible moment to update the  
schedule (table in whatever format) because procedures elsewhere in  
the observatory permit updating the information at any point.   
Occasionally I have to update the schedule after it is published.   
Procedures even exist for updating the resulting archival holdings  
retroactively.

The only thing special about leap seconds is that they more  
predictable than a lot of real world situations.

Rob




From blb8 at po.cwru.edu  Thu Jan  1 16:43:37 2009
From: blb8 at po.cwru.edu (blb8 at po.cwru.edu)
Date: Thu, 1 Jan 2009 13:43:37 -0800 (PST)
Subject: [LEAPSECS] Time is hard...
In-Reply-To: <20DCC329-5CCA-45D1-BC9A-2742DA96AAD1@noao.edu>
References: <51795.1230769835@critter.freebsd.dk>
	<20DCC329-5CCA-45D1-BC9A-2742DA96AAD1@noao.edu>
Message-ID: <Pine.BSO.4.58.0901011339440.599@www.blarfy.net>

> From: Rob Seaman <seaman at 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
> 
> ...
> 
> What precisely is an "average" programmer, anyway?

One that tests a ten-line code chunk before releasing it, and realizes that corner cases are important.  Quite frankly, I'd say that was a "beginning" programmer.



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 blb8 at po.cwru.edu  Thu Jan  1 16:52:48 2009
From: blb8 at po.cwru.edu (blb8 at po.cwru.edu)
Date: Thu, 1 Jan 2009 13:52:48 -0800 (PST)
Subject: [LEAPSECS] Happy New Year....
In-Reply-To: <495C0973.14402.181CC4F2@dan.tobias.name>
References: <495C0973.14402.181CC4F2@dan.tobias.name>
Message-ID: <Pine.BSO.4.58.0901011344450.599@www.blarfy.net>

> From: Daniel R. Tobias <dan at tobias.name>
> 
> ...  Meanwhile, the good old leap YEAR had a victim in the 
> Micro$oft Zume players, so are we going to see calls to abolish leap 
> days because programmers get them wrong, so all years should just be 
> 365 days long and it doesn't matter if the dates of the year rotate 
> through the seasons

If the resolution is:

1. Abolish leap seconds.

2. Abolish leap days.

3. Abolish daylight saving time.

4. Abolish all time zones and adopt a new, single, world-wide timezone (TPT) that syncs with current UTC+0 at some point.

5. TPT counts atomic seconds from that point.

6. The IERS does the job that their name suggests and publishes tables of corrects for UT*-TPT so those that want to know can figure out where the sun is.

Then I'll vote for it.  I will permit amendments about the Gregorian calendar and a suitable replacement, but anything else would be a non-starter.



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 blb8 at po.cwru.edu  Thu Jan  1 16:57:30 2009
From: blb8 at po.cwru.edu (blb8 at po.cwru.edu)
Date: Thu, 1 Jan 2009 13:57:30 -0800 (PST)
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
In-Reply-To: <55773.1230819692@critter.freebsd.dk>
References: <55773.1230819692@critter.freebsd.dk>
Message-ID: <Pine.BSO.4.58.0901011356230.599@www.blarfy.net>

> From: Poul-Henning Kamp <phk at phk.freebsd.dk>
> 
> DCF77 got right, as always.
> 
> HBG also got it right this time.
> 
> MSF still fumbles the DUT1 bits.
> 
> http://phk.freebsd.dk/Leap/20081231/

Very nice.  Alas, my receiver isn't close enough to the computer and I didn't think to record the signal.

WWV got it right, as far as I could tell.  I'm not sure if the DUT1 bits were correct in the first minute or not.



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 ashley at semantic.org  Thu Jan  1 16:58:23 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Thu, 01 Jan 2009 13:58:23 -0800
Subject: [LEAPSECS] Happy New Year....
In-Reply-To: <Pine.BSO.4.58.0901011344450.599@www.blarfy.net>
References: <495C0973.14402.181CC4F2@dan.tobias.name>
	<Pine.BSO.4.58.0901011344450.599@www.blarfy.net>
Message-ID: <1230847103.9555.6.camel@glastonbury>

On Thu, 2009-01-01 at 13:52 -0800, blb8 at po.cwru.edu wrote:
> If the resolution is:
> 
> 1. Abolish leap seconds.
> 
> 2. Abolish leap days.
> 
> 3. Abolish daylight saving time.
> 
> 4. Abolish all time zones and adopt a new, single, world-wide timezone (TPT) that syncs with current UTC+0 at some point.
> 
> 5. TPT counts atomic seconds from that point.
> 
> 6. The IERS does the job that their name suggests and publishes tables of corrects for UT*-TPT so those that want to know can figure out where the sun is.
> 
> Then I'll vote for it.  I will permit amendments about the Gregorian calendar and a suitable replacement, but anything else would be a non-starter.

Perhaps we should also make all months 30 days long. We could then make
weeks ten days long to match.

-- 
Ashley Yakeley


From imp at bsdimp.com  Thu Jan  1 17:11:13 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 01 Jan 2009 15:11:13 -0700 (MST)
Subject: [LEAPSECS] Automation
In-Reply-To: <1230843729.9555.2.camel@glastonbury>
References: <alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>
	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>
	<1230843729.9555.2.camel@glastonbury>
Message-ID: <20090101.151113.-494097056.imp@bsdimp.com>

In message: <1230843729.9555.2.camel at glastonbury>
            Ashley Yakeley <ashley at semantic.org> writes:
: On Thu, 2009-01-01 at 09:41 -0700, Rob Seaman wrote:
: > They can't be naively automated.  The schedule is currently  
: > predictable 6 months in advance.  Nobody has objected to a longer  
: > schedule; we're positively giddy to give it a try.  NTP is proof of  
: > concept that automation is possible once the schedule is released.
: 
: This might encourage software engineers to do the wrong thing, that is,
: hard-code a leap-second table.

But leap seconds are already hard coded, or at least there's a table
of them, on many systems that need to grok leap seconds.  similar to
the timezone 'hard coding'.

Warner

From seaman at noao.edu  Thu Jan  1 17:51:39 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 15:51:39 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
Message-ID: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>

Tony Finch wrote:

> M. Warner Losh wrote:
>
>> Time used to be strongly coupled to the earth.
>
> Only because it was the most accurate clock we had. It might still  
> be the most reliable clock we have but our natural tendency to  
> optimisation means that isn't the most important consideration.

The high reliability of the Earth as a clock is an intriguing and  
original point.  Amazing we haven't long since run out of them!   
(Well, actually quite commonplace when the problem definition phase of  
a project is shorted.)

> Actually I would say that mean solar time was (past tense  
> deliberate) was a temporary aberration, lasting from mechanical  
> clocks replacing the sundial, to the rise of DST.

Mean solar time will outlast artificial clocks and the species that  
built them by a factor of something like 5,000,000,000 to 50,000.   
(Time remaining on the Earth clock compared to the Cro Magnon clock.)   
Mean solar time is an intrinsic characteristic of life on Earth, the  
count of our days.

The clock (singular deliberate) is a subdivision of the calendar.   
When the Sun goes nova and melts the crust of an Earth long void of  
humans and unrecognizable as ours due to plate tectonics (and lost in  
space due to the differential rotation of the Galaxy) - it will yet  
have been both theoretically and logistically possible to count every  
- single - unique - day that the long suffering, ever renewing globe  
has seen.

Our Moon will be more distant, its tides lessened.  The engine of  
plate tectonics will have halted, quieting seismic modes.  The Earth  
will be an even more reliable timekeeper at the end of days.  For all  
our sturm and drang, tidal slowing will have made no difference  
whatsoever to the countability of our days.

Days are real, not manufactured by the ITU.  Anything that attempts to  
mess with them is fated to fail - in the real world and perhaps even  
in the political world.  Leap seconds are a red herring.  A day  
without the Sun is devoid of meaning.

Atomic clocks are said to be better than solar timekeeping.  It's a  
funny definition that discounts a clock that lasts for 10 billion  
years and gets more accurate as it ages.

Beat that for optimization and natural tendencies :-)

Rob

From dot at dotat.at  Thu Jan  1 19:46:13 2009
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Jan 2009 00:46:13 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
Message-ID: <alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>

On Thu, 1 Jan 2009, Rob Seaman wrote:
>
> Mean solar time will outlast artificial clocks and the species that
> built them by a factor of something like 5,000,000,000 to 50,000.

Not really, because mean solar time is also artificial and can't exist
without mechanical clocks and telescopes.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FAEROES: VARIABLE 4, BUT MAINLY SOUTHEASTERLY 4 OR 5 IN WEST, BECOMING
WESTERLY OR SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6 IN NORTH. MODERATE. FAIR.
GOOD.

From seaman at noao.edu  Thu Jan  1 20:07:56 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 18:07:56 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
Message-ID: <96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>

Tony Finch wrote:

> On Thu, 1 Jan 2009, Rob Seaman wrote:
>>
>
>> Mean solar time will outlast artificial clocks and the species that
>> built them by a factor of something like 5,000,000,000 to 50,000.
>
> Not really, because mean solar time is also artificial and can't exist
> without mechanical clocks and telescopes.

And I suppose the refrigerator light goes out when the door is  
closed :-)

Once more from the top, mean solar time is just sidereal time offset  
by a little bit to make up for the Earth lapping the Sun once a year.   
Nowhere does humanity appear in the equation, just the Earth and Sun  
and Stars.

Apparent solar time is derived from mean solar time, not the other way  
around.

Rob



From imp at bsdimp.com  Thu Jan  1 20:33:08 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 01 Jan 2009 18:33:08 -0700 (MST)
Subject: [LEAPSECS] Reliability
In-Reply-To: <96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
Message-ID: <20090101.183308.128309630.imp@bsdimp.com>

In message: <96C34D96-8A20-453A-B4A6-B8491287B1B7 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Apparent solar time is derived from mean solar time, not the other way  
: around.

Can you explain this, since I thought it was the other way around...

Warner

From seaman at noao.edu  Thu Jan  1 22:47:02 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Jan 2009 20:47:02 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090101.183308.128309630.imp@bsdimp.com>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
Message-ID: <984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>

M. Warner Losh wrote:

> Rob Seaman writes:
>
>> Apparent solar time is derived from mean solar time, not the other  
>> way around.
>>
>
> Can you explain this, since I thought it was the other way around...

We live in an empirical world.  When investigating the behavior of a  
class of objects (or processes, in astronomy the difference isn't  
always clear), measurements are often combined in weird and wonderful  
ways through population studies.  In that case, a measure of central  
tendency like the mean is taken as an estimator of a typical value for  
the class.

For instance, the cosmological distance ladder is built from large  
numbers of measurements of classes of objects like supernovae and  
cepheid variables.  One might also perform solar system studies on the  
population dynamics of different classes of asteroids or Kuiper belt  
objects.

Studying the orbital/rotational dynamics of a single object - for  
instance, the Earth - is different in that a measure of central  
tendency would be used to refine an estimate of a characteristic  
intrinsic to a single object, not of a class.

So the point of that preface is that the meaning of the word "mean"  
depends on the purpose of the exercise.

In particular, ignoring relativistic issues and perturbation theory  
and other stuff out of my depth, the orbital dynamics of the solar  
system have been a solved issue since Kepler and Newton and a lot of  
clever French mathematicians.

Like I keep saying, the mean solar day is trivial to compute from the  
sidereal day.  Look at it this way, there are "really" 366.25 days per  
year.  That extra day just gets sliced and diced among all the others.

Rather than mean solar time being some mysterious created artifact  
that is assembled out of vast numbers of independent "real"  
measurements of a time series of apparent solar positions in the sky,  
the apparent position of the sun is calculable from (and dependent on)  
the Earth's orbital parameters (e.g., semi-major axis and  
eccentricity), the tilt of its axis, the corresponding rates, and  
latitude and longitude.

To some extent it is just a point of view which are the independent  
and which are the dependent variables, but few are likely to choose  
the bizarre curlicues made by the Sun and planets on the celestial  
sphere as their fundamental coordinate system.

Instead, a handful of parameters describe the elliptical orbit of each  
of the planets.  The spinning planets (just angular velocity vectors)  
are layered on the orbits.  And the apparent position of each of the  
other solar system objects in the Earth's sky is a function of  
latitude and longitude layered on top of the Earth's spin and the two  
orbits in question.

It's the usual familiar layered architecture and the apparent position  
of the Sun is from a higher layer then the - so-called - mean  
position.  Astronomers confuse the issue by using phrases like  
"fictitious Sun", but then astronomical terminology is always upside- 
down and backwards.

Rob

From dan at tobias.name  Fri Jan  2 00:10:10 2009
From: dan at tobias.name (Daniel R. Tobias)
Date: Fri, 02 Jan 2009 00:10:10 -0500
Subject: [LEAPSECS] Reliability
In-Reply-To: <984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>,
	<20090101.183308.128309630.imp@bsdimp.com>,
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
Message-ID: <495D5B62.25198.1D44E4DB@dan.tobias.name>

On 1 Jan 2009 at 20:47, Rob Seaman wrote:

> So the point of that preface is that the meaning of the word "mean"  
> depends on the purpose of the exercise.

What does "mean" mean?  Don't be mean about it!  :-)


-- 
== 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 sla at ucolick.org  Fri Jan  2 00:39:39 2009
From: sla at ucolick.org (Steve Allen)
Date: Thu, 1 Jan 2009 21:39:39 -0800
Subject: [LEAPSECS] Reliability
In-Reply-To: <495D5B62.25198.1D44E4DB@dan.tobias.name>
References: <984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<495D5B62.25198.1D44E4DB@dan.tobias.name>
Message-ID: <20090102053939.GA29139@ucolick.org>

On Fri 2009-01-02T00:10:10 -0500, Daniel R. Tobias hath writ:
> What does "mean" mean?  Don't be mean about it!  :-)

In this particular arena, the accepted meaning of mean has been
changed as it was handed along a chain of names, notably among them,
but not limited to
Ptolemy                  150
Huygens                 1665
Flamsteed               1672
Newcomb                 1895
Aoki et al.             1982
Capitaine et al.        2000

Curiously enough, in scant weeks the Secretary of State, who has sayso
over the US position presented to ITU-R by USWP7A delegates, will be
the woman whose husband's presidential deposition included the
infamous words

"It depends on what the meaning of the word 'is' is."

http://www.youtube.com/watch?v=j4XT-l-_3y0

This whole issue is a conventional matter, and conventional reality
is established in accordance with the needs of its makers.

--
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 blb8 at po.cwru.edu  Fri Jan  2 01:29:23 2009
From: blb8 at po.cwru.edu (blb8 at po.cwru.edu)
Date: Thu, 1 Jan 2009 22:29:23 -0800 (PST)
Subject: [LEAPSECS] Reliability
In-Reply-To: <984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
Message-ID: <Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>

> From: Rob Seaman <seaman at noao.edu>
> ...
> Like I keep saying, the mean solar day is trivial to compute from the  
> sidereal day.  Look at it this way, there are "really" 366.25 days per  
> year.  That extra day just gets sliced and diced among all the others.

Nice, now we have extra days!

A "leap year" is every four years except every one hundred years except every four hundred years.  Put another way, if Y is the number of the year then Y is a leap year if:  (Y%4==0)&&((Y%100!=0)||(Y%400==0)) where that's the modulus operator, of course.  In a four-hundred year cycle, that's 24 leap years per century except the start of the century (minus one), and then one leap year at the start of the millenium (minus one).

That's 303*365+97*366=146097 days for an average of 365.2425 days per year.  Woo!

I guess being on break for two weeks means I haven't gotten my fill of teaching arithmetic.



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 magnus at rubidium.dyndns.org  Fri Jan  2 03:03:40 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Fri, 02 Jan 2009 09:03:40 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>	<20090101.183308.128309630.imp@bsdimp.com>	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>
Message-ID: <495DCA5C.8050907@rubidium.dyndns.org>

Dear Brian,

blb8 at po.cwru.edu skrev:
>> From: Rob Seaman <seaman at noao.edu>
>> ...
>> Like I keep saying, the mean solar day is trivial to compute from the  
>> sidereal day.  Look at it this way, there are "really" 366.25 days per  
>> year.  That extra day just gets sliced and diced among all the others.
> 
> Nice, now we have extra days!
> 
> A "leap year" is every four years except every one hundred years except every four hundred years.  Put another way, if Y is the number of the year then Y is a leap year if:  (Y%4==0)&&((Y%100!=0)||(Y%400==0)) where that's the modulus operator, of course.  In a four-hundred year cycle, that's 24 leap years per century except the start of the century (minus one), and then one leap year at the start of the millenium (minus one).
> 
> That's 303*365+97*366=146097 days for an average of 365.2425 days per year.  Woo!
> 
> I guess being on break for two weeks means I haven't gotten my fill of teaching arithmetic.

I think you have mixed up your solar days with sidereal days. The 
sidereal day is the time it takes the earth to turn 360 degrees, and to 
measure that one often uses a fix-star as reference. A sidereal day is 
is about 23 hours and 56 minutes long. A solar day is the time it takes 
for the earth to turn until the sun is at the same place in the sky 
(i.e. using the sun as the fix-star). These are not the same thing since 
we have a significant movement around the sun where as a more distant 
fix-star has a much less angular distorsion.

Your arthmetic describes solar days, but fails to describe the sidereal 
days.

The side-real day is important. The GPS satellite orbits is 11 hour and 
58 minutes long, so that their orbit around the world causes a near 
perfect re-tracing over the world.

So yes, we have an extra day, but since the earth turns in the direction 
is does the solar day count is one less.

Cheers,
Magnus

From phk at phk.freebsd.dk  Fri Jan  2 04:47:51 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 02 Jan 2009 09:47:51 +0000
Subject: [LEAPSECS] more 2008-12-31  breakage
Message-ID: <63370.1230889671@critter.freebsd.dk>


Solaris, Linux and/or Oracle committing suicide:

	http://www.merit.edu/mail.archives/nanog/msg13846.html

-- 
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  Fri Jan  2 05:42:55 2009
From: zefram at fysh.org (Zefram)
Date: Fri, 2 Jan 2009 10:42:55 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
References: <EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
Message-ID: <20090102104255.GI14473@fysh.org>

Rob Seaman wrote:
>Apparent solar time is derived from mean solar time, not the other way  
>around.

The way I see it, apparent solar time is, in an astronomical sense,
derived from sidereal time, not from mean solar time.  Apparent solar
time is just sidereal time minus true anomaly.  All three parts of
this equation are astronomically reified angles: they could be measured
directly given a protractor and a suitable viewpoint.

Mean solar time, on the other hand, does not correspond to any actual
geometric angle.  It can't be measured directly from the instantaneous
positions of the bodies.  Mean solar time is sidereal time minus mean
anomaly, but the mean anomaly is a mathematical construction, not a
direct part of the geometry.

Granted, the concept of mean solar time can be applied without requiring
the kind of human activity that is inherent in timezones or TAI.  In that
sense it's a naturally-occurring time scale.  But it's no more fundamental
than apparent solar time; if anything, it is less so.

Of course, for the purposes of human psychological factors, the
(periodic) difference between mean solar time and apparent solar time
is insignificant.  An unaided human would be hard pressed to distinguish
between them.

-zefram

From zefram at fysh.org  Fri Jan  2 06:04:15 2009
From: zefram at fysh.org (Zefram)
Date: Fri, 2 Jan 2009 11:04:15 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
Message-ID: <20090102110415.GA22707@fysh.org>

Rob Seaman wrote:
>It's the usual familiar layered architecture and the apparent position  
>of the Sun is from a higher layer then the - so-called - mean  
>position.

Sidereal time isn't entirely linear in time either, as we all know.
So if the mean behaviour is the more fundamental, presumably you regard
UT2R as more fundamental than UT1.

>                                           few are likely to choose  
>the bizarre curlicues made by the Sun and planets on the celestial  
>sphere as their fundamental coordinate system.

The mean may well make a better coordinate system, but without those
bizarre curlicues the mean wouldn't exist.

-zefram

From dan at tobias.name  Fri Jan  2 07:40:48 2009
From: dan at tobias.name (Daniel R. Tobias)
Date: Fri, 02 Jan 2009 07:40:48 -0500
Subject: [LEAPSECS] Leap year day-count bugs, then and now
Message-ID: <495DC500.16749.1EE17BE5@dan.tobias.name>

Here's an article about a leap-year bug fairly similar to the one in 
current Zume music players which immobilized Wang computers in 1984:

http://thedailywtf.com/Articles/Classic-WTF-The-Bug-That-Shut-Down-
Computers-WorldWide.aspx

Also, the comments section of that article includes the actual code 
behind the Zume bug, which involves the system getting put in an 
infinite loop on reaching a day number of 366, even though the code 
did in fact attempt to be cognizant of leap years.


-- 
== 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 sla at ucolick.org  Fri Jan  2 11:15:40 2009
From: sla at ucolick.org (Steve Allen)
Date: Fri, 2 Jan 2009 08:15:40 -0800
Subject: [LEAPSECS] Dennis McCarthy on the leap second
Message-ID: <20090102161540.GA30967@ucolick.org>

On Wednesday Dr. McCarthy was interviewed by Los Angeles CBS radio

http://podcast.kcbs.com/kcbs/1506340.mp3

--
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  Fri Jan  2 11:34:49 2009
From: lang at unb.ca (Richard B. Langley)
Date: Fri,  2 Jan 2009 12:34:49 -0400
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
In-Reply-To: <1230826773.495ced1569212@webmail.unb.ca>
References: <55773.1230819692@critter.freebsd.dk>
	<1230826773.495ced1569212@webmail.unb.ca>
Message-ID: <1230914089.495e4229780e3@webmail.unb.ca>

BBC's 7 pips went off o.k. too <http://en.wikipedia.org/wiki/Greenwich_Time_Signal> They
were broadcast on Radio 5 Live. You can replay them here:
<http://www.bbc.co.uk/programmes/b00g4dsd> about 2/3 of the way through the program. The
main radio networks (1 through 4) only carried Big Ben.

Quoting "Richard B. Langley" <lang at unb.ca>:

> CHU got it right this time. Last time there was a change in the DUT1 value effective
> 1
> January in addition to the leap second. The notice from IERS was sent late and the
> people responsible for inputting the new DUT1 value were already on their
> Christmas/New
> Year break when it arrived.
> 
> Quoting Poul-Henning Kamp <phk at phk.freebsd.dk>:
> 
> > 
> > DCF77 got right, as always.
> > 
> > HBG also got it right this time.
> > 
> > MSF still fumbles the DUT1 bits.
> > 
> > http://phk.freebsd.dk/Leap/20081231/
> > 
> > -- 
> > 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
> > 
> 
> 
> ===============================================================================
>  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/
> ===============================================================================
> 
> 
> _______________________________________________
> 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 tvb at LeapSecond.com  Fri Jan  2 11:52:38 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Fri, 2 Jan 2009 08:52:38 -0800
Subject: [LEAPSECS] Leap year day-count bugs, then and now
References: <495DC500.16749.1EE17BE5@dan.tobias.name>
Message-ID: <351E43AA7D854B42865CF4EDBE93A2B2@pc52>

> Also, the comments section of that article includes the actual code 
> behind the Zume bug, which involves the system getting put in an 
> infinite loop on reaching a day number of 366, even though the code 
> did in fact attempt to be cognizant of leap years.

Dan, thanks for the rtt.c link (http://pastie.org/349916.txt)
The piece of code in question starts at line 259:

    while (days > 365)
    {
        if (IsLeapYear(year))
        {
            if (days > 366)
            {
                days -= 366;
                year += 1;
            }
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

The file contains quite a number of date/time related functions,
not unlike those found in almost any application, library, or
operating system.

I recommend anyone on the list take a look at this file, not as a
swipe at Zune or the company that makes it, or Freescale, who
apparently wrote the code, but as a typical example of the state
of date/time handling in modern software.

Then, if leap seconds were to matter to a device like Zune, ask
yourself what would have to change in the code the handle leap
seconds correctly as well as leap years.

/tvb



From seaman at noao.edu  Fri Jan  2 12:14:19 2009
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 2 Jan 2009 10:14:19 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <1230902301.495e141d4bc2a@webmail.unb.ca>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<1230902301.495e141d4bc2a@webmail.unb.ca>
Message-ID: <713C1A68-4790-4984-A56E-83E2FDAE0289@noao.edu>

Hi Richard,

Yes, it's certainly true that sundials show apparent solar time.  I  
looked into buying or building a state of the art sundial when we  
moved into a new house a few years back.  The cost can be staggering,  
so this was hard to justify, but the state of the art is pretty spiffy  
these days.

Apparent is not more real than mean, however.  Like I said, it depends  
on point of view.  By combining multiple measurements of apparent  
apparitions, one attempts to recover an intrinsic parameter of the  
planet - mean solar time.

Another point of view is gain vs sensitivity (as used in Janesick's  
CCD bible, for instance).  Gain relates successive steps in a process  
in a forward direction.  Sensitivity recovers them in a backward  
direction.  Photons from astrophysical sources are more fundamental  
than electrons from solid-state detectors, and electrons more  
fundamental than the DNs from A/D converters.  Image processing  
measures DNs to characterize photons, however.

We measure apparent positions of solar system objects, comets as well  
as the Sun, in order to characterize the more fundamental parameters  
of orbital elements and the spinning bodies following those orbits (as  
well as weird and wonderful higher order wobbles).

The Earth is spinning like a top.  Its rate of spin is what we're  
interested in for civil time.  Far from denying this fact, both the  
current UTC standard and the ITU proposal rely on the high regularity  
of mean solar time for them to be even conceptually possible.

If we focus on ways to improve the logistics of the approximation  
scheme (without abandoning the underlying requirement), we'll reach  
consensus.

Rob
---

On Jan 2, 2009, at 6:18 AM, Richard B. Langley wrote:

> Rob:
> Just sending this offlist. Forward if you like. A conventional  
> sundial directly shows
> apparent solar time.
> -- Richard
>
> Quoting Rob Seaman <seaman at noao.edu>:
>
>> Tony Finch wrote:
>>
>>> On Thu, 1 Jan 2009, Rob Seaman wrote:
>>>>
>>>
>>>> Mean solar time will outlast artificial clocks and the species that
>>>> built them by a factor of something like 5,000,000,000 to 50,000.
>>>
>>> Not really, because mean solar time is also artificial and can't  
>>> exist
>>> without mechanical clocks and telescopes.
>>
>> And I suppose the refrigerator light goes out when the door is
>> closed :-)
>>
>> Once more from the top, mean solar time is just sidereal time offset
>> by a little bit to make up for the Earth lapping the Sun once a year.
>> Nowhere does humanity appear in the equation, just the Earth and Sun
>> and Stars.
>>
>> Apparent solar time is derived from mean solar time, not the other  
>> way
>> around.
>>
>> Rob

From nimh at pipe.nl  Fri Jan  2 12:43:01 2009
From: nimh at pipe.nl (Nero Imhard)
Date: Fri, 2 Jan 2009 18:43:01 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <713C1A68-4790-4984-A56E-83E2FDAE0289@noao.edu>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<1230902301.495e141d4bc2a@webmail.unb.ca>
	<713C1A68-4790-4984-A56E-83E2FDAE0289@noao.edu>
Message-ID: <1F8BBB00-1CE6-4D8A-AC7F-06FBC8745A5C@pipe.nl>


On 2009-01-02, at 18:14, Rob Seaman wrote:

> Yes, it's certainly true that sundials show apparent solar time.

Not all! A Bernhardt precision sundial has a specially shaped gnomon  
and shows UT or local civil time to precisions well within one minute.  
Beautiful things. I wish I had one.

N

From seaman at noao.edu  Fri Jan  2 12:44:29 2009
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 2 Jan 2009 10:44:29 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090102110415.GA22707@fysh.org>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
Message-ID: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>

Zefram wrote:

> Rob Seaman wrote:
>> It's the usual familiar layered architecture and the apparent  
>> position
>> of the Sun is from a higher layer then the - so-called - mean
>> position.
>
> Sidereal time isn't entirely linear in time either, as we all know.
> So if the mean behaviour is the more fundamental, presumably you  
> regard
> UT2R as more fundamental than UT1.

According to the IAU, sidereal time itself doesn't really exist :-)

And yet the Earth spins beneath a starry sky.

> The mean may well make a better coordinate system, but without those
> bizarre curlicues the mean wouldn't exist.


Mean solar time is highly regular and elegantly simple.  Regression to  
the mean (which I think is the notion underlying this disputation of  
terms) from unrelated measurements would not recover such a simple  
result.  Rather (to first order) the Earth spins at a constant angular  
rate.  The apparent positions of the Sun from day-to-day are not  
unrelated, they are related precisely by the fundamental angular  
velocity vector of the spinning Earth (http://www.analemma.com).

The fact that this results in apparent positions that vary  
flamboyantly reveals a number of hidden variables.  The eccentricity  
of the Earth's orbit.  The tilt of its axis.  The (near) spherical  
coordinate system on the surface of the Earth (http://en.wikipedia.org/wiki/Eratosthenes 
).

For civil timekeeping, these are irrelevant.  Civil timekeeping (even  
under the ITU proposal) is about the underlying diurnal period.  The  
curlicues obscure underlying reality, they don't create it.

Removing leap seconds (without providing an alternate mode of  
approximation) would just make the curlicues more bizarre.

Rob


From dot at dotat.at  Fri Jan  2 13:29:18 2009
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Jan 2009 18:29:18 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
References: <42836.1230627431@critter.freebsd.dk>
	<EA6B0AE7-7375-4AB4-8F0C-005E5A5183AA@pipe.nl>
	<20081230.125706.-1622602191.imp@bsdimp.com>
	<alpine.LSU.2.00.0901010545500.2395@hermes-1.csi.cam.ac.uk>
	<1DF7E5D8-A031-4422-80D5-866B04B4BD45@noao.edu>
	<15F5908A-62F5-42AD-9ED6-3186C35FDEBC@noao.edu>
	<B41B5336-2BC3-4A8E-AA2B-E192B8EB2D58@noao.edu>
	<737107F9-22ED-41B6-A8E5-AB6E2ECA0CA5@noao.edu>
	<EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
Message-ID: <alpine.LSU.2.00.0901021828230.26975@hermes-1.csi.cam.ac.uk>

On Thu, 1 Jan 2009, Rob Seaman wrote:
>
> Once more from the top, mean solar time is just sidereal time offset by a
> little bit to make up for the Earth lapping the Sun once a year.  Nowhere does
> humanity appear in the equation, just the Earth and Sun and Stars.

No, since an oscillator without a counter is not a clock.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FAIR ISLE FAEROES: WESTERLY OR NORTHWESTERLY 4 OR 5, INCREASING 6 OR 7 FOR A
TIME. MODERATE OR ROUGH. RAIN OR SHOWERS, OCCASIONAL SNOW LATER IN NORTH.
MODERATE OR GOOD, OCCASIONALLY VERY POOR LATER.

From dot at dotat.at  Fri Jan  2 13:45:48 2009
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Jan 2009 18:45:48 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
Message-ID: <alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>

On Fri, 2 Jan 2009, Rob Seaman wrote:
>
> Mean solar time is highly regular and elegantly simple.

Compared to our clocks it's too irregular.

> Civil timekeeping (even under the ITU proposal) is about the underlying
> diurnal period.

What does atomic time have to do with the position of the Earth?

I find it odd that you are arguing that the mathematical model of the
earth's orbit and rotation is more real than the observations from which
the model is derived.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA SHANNON: EASTERLY OR SOUTHEASTERLY 5 TO 7,
DECREASING 4, BUT BECOMING VARIABLE 3 IN IRISH SEA. MODERATE OR ROUGH,
BECOMING VERY ROUGH IN WEST SOLE AND FASTNET, MAINLY SLIGHT IN IRISH SEA.
OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

From dot at dotat.at  Fri Jan  2 13:52:02 2009
From: dot at dotat.at (Tony Finch)
Date: Fri, 2 Jan 2009 18:52:02 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <495DCA5C.8050907@rubidium.dyndns.org>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>
	<495DCA5C.8050907@rubidium.dyndns.org>
Message-ID: <alpine.LSU.2.00.0901021847550.26975@hermes-1.csi.cam.ac.uk>

On Fri, 2 Jan 2009, Magnus Danielson wrote:
> blb8 at po.cwru.edu skrev:
> >
> > That's 303*365+97*366=146097 days for an average of 365.2425 days per year.
>
> Your arthmetic describes solar days, but fails to describe the sidereal days.

No, he's talking about calendar years, as opposed to the conventional
astronomical year of 365.25 days that Rob mentioned. The latter is often
the unit for the time co-ordinate in ephemerides and is not supposed to
model the length of the earth's orbit.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
CROMARTY FORTH TYNE: VARIABLE 3 OR 4, BECOMING WEST OR NORTHWEST 4 OR 5 ,
INCREASING 6 LATER IN CROMARTY. SLIGHT OR MODERATE. OCCASIONAL RAIN LATER IN
CROMARTY. MODERATE OR GOOD, OCCASIONALLY POOR LATER IN CROMARTY.

From magnus at rubidium.dyndns.org  Fri Jan  2 20:13:23 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 03 Jan 2009 02:13:23 +0100
Subject: [LEAPSECS] Automation
In-Reply-To: <20090101.151113.-494097056.imp@bsdimp.com>
References: <alpine.LSU.2.00.0901011607160.14215@hermes-1.csi.cam.ac.uk>	<151A3828-174F-41DB-917A-0C98C8430DCD@noao.edu>	<1230843729.9555.2.camel@glastonbury>
	<20090101.151113.-494097056.imp@bsdimp.com>
Message-ID: <495EBBB3.10207@rubidium.dyndns.org>

M. Warner Losh skrev:
> In message: <1230843729.9555.2.camel at glastonbury>
>             Ashley Yakeley <ashley at semantic.org> writes:
> : On Thu, 2009-01-01 at 09:41 -0700, Rob Seaman wrote:
> : > They can't be naively automated.  The schedule is currently  
> : > predictable 6 months in advance.  Nobody has objected to a longer  
> : > schedule; we're positively giddy to give it a try.  NTP is proof of  
> : > concept that automation is possible once the schedule is released.
> : 
> : This might encourage software engineers to do the wrong thing, that is,
> : hard-code a leap-second table.
> 
> But leap seconds are already hard coded, or at least there's a table
> of them, on many systems that need to grok leap seconds.  similar to
> the timezone 'hard coding'.

Rolling back a few messages you find the use of longer schedules. If a 
schedule was given say every 5th year with the upcomming 10 years 
schedule of leap seconds then you have two things, a longer heads-up 
time and a longer valid time. However, such a procedure comes with a 
clear end-date of validity. If you do not update the table prior to that 
you are on your own. Today we have slightly less than 6 months heads-up 
and 6 months of valid-time. For systems requiring hard-coded tables this 
is too short and then it is a hurdle.

For systems having at least some external reference, automatic methods 
such as web or DNS based could be used, with probably the added 
requirement of some means of authenticity checks, could be used to send 
information about upcomming leap-seconds, then the current leap-second 
schedule is more than adequate. Shorter than a month would be possible.
For NTP, root NTP servers could either rely on information sources such 
as GPS or use network based methods to automatically update their own 
list, and then NTP could be used to transfer this knowledge thoughtout 
the network.

As I have understood it, advances in ability to predict earth orbits 
would allow predictions deeper into the future. This would allow for 
longer schedules. It can be argued that maybe "isolated systems" can't 
be that isolated if they require proper UTC representation at the same 
time as they are totally isolated. Never the less, longer schedule times 
seems possible. The implications they would have for such isolated 
systems is slower upgrade rate and to some degree a more stable upgrade 
pattern (every 5 years with my example numbers). The IERS would issue a 
rolling schedule, so their announcement rate would be the same, but 
their predictions would be further out in time than today.

Long schedules and automation can work hand in hand. You can deliver 
long schedules using automatic methods, but the hold-over times would be 
considerably longer.

The drawback of long schedules is that people would forget or ignore the 
issue, with the implied risk of missing or avoiding updates.

Cheers,
Magnus

From seaman at noao.edu  Fri Jan  2 22:29:21 2009
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 2 Jan 2009 20:29:21 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
Message-ID: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>

Tony Finch wrote:

> I find it odd that you are arguing that the mathematical model of  
> the earth's orbit and rotation is more real than the observations  
> from which the model is derived.

Clearly I failed again to make my point.

There are two different uses to which one might put statistics.   
(Well, many more than this, but two that are being confused here.)   
The first is your interpretation.  That multiple independent  
observations are combined to build a theory of some unknown process.

That is not the case we have, and haven't had since Newton explained  
Kepler's laws that were derived from Tycho's data.

Rather, we can now assume that Newtonian mechanics governs the solar  
system.  For investigations with more precise requirements, Einstein  
steps in.  To the level of precision needed to define civil  
timekeeping, we know the Earth follows an elliptical orbit around the  
Sun, and that the Earth spins at a constant rate on a tilted axis.   
There are also various wobbles and perturbations from the other  
objects in the solar system.  Laplace is handy to explain those.  We  
don't often need to model new theory in classical or relativistic  
mechanics at the modest velocities found in the solar system.

So yes, I think the angular momentum of the Earth is more real than  
the observations that might be compiled to generate an estimate for  
its value.  In freshman physics lab, I recall compiling a big grid of  
current measurements resulting from voltages applied to a wide range  
of resistances.  Unsurprisingly, Ohm's law was confirmed.  The solar  
system is not a mystery.

In any event, this isn't some big philosophical point.  I'm just  
looking for another way to emphasize that civil timekeeping has a  
diurnal cadence.  How's this:

1) The ITU says an hour excursion from mean solar time is acceptable.   
(They appear to assume that some procedure for handling the inevitable  
intercalary correction will self-organize before we reach that hour.)

2) The notion is that an hour's intercalary correction might first  
occur about 600 years out (when the excursion ought to be around a  
half hour).

3) The accumulation of a one-hour error term in 600 years is one-hour  
in 220,000 days is one-hour in 5.3 million hours.  That's equivalent  
to a clock that keeps mean solar time to better than 1 second in 60  
days.

4) Which is to say that the ITU position - a very extreme position -  
depends on staying aligned to mean solar time to better than one part  
in several million.

Civil time is solar time.  The rate is the issue, not local offsets.   
Let's move past the fantasy that the ITU can redefine timescales willy- 
nilly to serve the requirements of a civilization of mole people, and  
rather address the actual requirements of our own civilization.

The best way to build a consensus is to focus on the logistics of the  
approximation needed to align interval timekeepers with Earth  
orientation timekeepers.

Rob


From sla at ucolick.org  Fri Jan  2 23:43:15 2009
From: sla at ucolick.org (Steve Allen)
Date: Fri, 2 Jan 2009 20:43:15 -0800
Subject: [LEAPSECS] temporal turf wars
Message-ID: <20090103044315.GA32266@ucolick.org>

An interesting NIST document from 2000 gives insight into the turf wars
about precision time scales.

http://tf.nist.gov/general/pdf/1429.pdf

The document makes it clear that GPS time was never designed to follow
UTC(USNO) (and by implication, TAI).

The document also clarifies the distinction between (raw) GPS time and
GPS time corrected by the offset given in subframe 4 page 18.

The document also coins the term UTC(GPS) with very interesting
footnotes disclaiming the validity of the use of such a term.

--
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 tvb at LeapSecond.com  Sat Jan  3 00:36:44 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Fri, 2 Jan 2009 21:36:44 -0800
Subject: [LEAPSECS] temporal turf wars
References: <20090103044315.GA32266@ucolick.org>
Message-ID: <56E257659FAB46B292DA0A8DEDDB9A12@pc52>

> An interesting NIST document from 2000 gives insight into the turf wars
> about precision time scales.
> 
> http://tf.nist.gov/general/pdf/1429.pdf
> 
> The document makes it clear that GPS time was never designed to follow
> UTC(USNO) (and by implication, TAI).

I think you're misreading that sentence. GPS is in fact steered to
the USNO MC which is steered to UTC. But I think the steering
parameters are quite different between the two though. I also
suspect there have been improvements in the past ten years.
Demetrios can explain more, if needed.

> The document also clarifies the distinction between (raw) GPS time and
> GPS time corrected by the offset given in subframe 4 page 18.

The GPS ICD 200 describes the A0 and A1 correction. I believe
most (all?) GPS timing receiver implement the correction. Steve, you'd
have fun with a GPS timing receiver like a Thunderbolt or an M12;
all those subframe parameters can be dumped over the serial port
and played with.

> The document also coins the term UTC(GPS) with very interesting
> footnotes disclaiming the validity of the use of such a term.

I doubt Al coined that term; I recall seeing it long before. But like
the editor implies, people realized it was not a valid term and so
you rarely see it any more. Maybe marketing people still use it.
I remember being gently corrected by the BIPM and I stopped
using it myself. I think UTC(tvb) is ok, though ;-)

/tvb



From dot at dotat.at  Sat Jan  3 08:33:55 2009
From: dot at dotat.at (Tony Finch)
Date: Sat, 3 Jan 2009 13:33:55 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
Message-ID: <alpine.LSU.2.00.0901031315520.19349@hermes-1.csi.cam.ac.uk>

On Fri, 2 Jan 2009, Rob Seaman wrote:
>
> So yes, I think the angular momentum of the Earth is more real than the
> observations that might be compiled to generate an estimate for its value.

But the value is an estimate, so if you plug numbers into a model based on
this estimate you are only going to get an estimate to apparent solar
time. In fact, since the model has to include a value for the earth's
unpredictably variable moment of inertia, the result of using the model is
going to be less accurate than the estimate you started with.

(Um, do we actually know the earth's angular momentum and moment of
inertia to any useful accuracy? I would have thought models would be based
directly on angular velocity since that can be measured more precisely.)

I think it's wrong to say that a directly measurable value (such as
apparent solar time) is less real when measured than when derived from a
model!

Perhaps the word you are looking for is "fundamental".

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FITZROY: NORTHWESTERLY IN SOUTH AT FIRST, OTHERWISE EASTERLY BACKING
NORTHEASTERLY, 5 OR 6, OCCASIONALLY 6 AT FIRST, BECOMING VARIABLE 4 IN FAR
NORTHWEST LATER. ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.

From matsakis.demetrios at usno.navy.mil  Sat Jan  3 08:54:48 2009
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Sat, 3 Jan 2009 08:54:48 -0500
Subject: [LEAPSECS] temporal turf wars
In-Reply-To: <56E257659FAB46B292DA0A8DEDDB9A12@pc52>
References: <20090103044315.GA32266@ucolick.org>,
	<56E257659FAB46B292DA0A8DEDDB9A12@pc52>
Message-ID: <5B265E66-FB13-41F6-B640-DA5F96E75A9A@mimectl>

I agree with Tom about GPS.   Over the past decade both GPS's delivered prediction of UTC(USNO) and GPS time have been getting closer and closer to UTC(USNO), modulo 1 second  and as measured by the RMS.  That is mostly due to improved GPS clocks, but tighter steering was implemented about ten years ago, and other algorithm improvements have also been made.  GPS III's times will adhere even closer to UTC(USNO) - because clocks, algorithms, and official specs are being improved.

While I can't speak for the USNO's sister-institution, I do remember the paper referenced below.  It was presented at a PTTI meeting by someone who at that time was an employee of NIST and this must be why they include it in their reprint library.  I am quite sure that it does not now represent nor ever has represented any official position of NIST in any way.  However, USNO did at one time host a web page that included UTC(tvb)! 

From: Tom Van Baak
Sent: Sat 1/3/2009 5:36 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] temporal turf wars


> An interesting NIST document from 2000 gives insight into the turf wars
> about precision time scales.
> 
> http://tf.nist.gov/general/pdf/1429.pdf
> 
> The document makes it clear that GPS time was never designed to follow
> UTC(USNO) (and by implication, TAI).

I think you're misreading that sentence. GPS is in fact steered to
the USNO MC which is steered to UTC. But I think the steering
parameters are quite different between the two though. I also
suspect there have been improvements in the past ten years.
Demetrios can explain more, if needed.

> The document also clarifies the distinction between (raw) GPS time and
> GPS time corrected by the offset given in subframe 4 page 18.

The GPS ICD 200 describes the A0 and A1 correction. I believe
most (all?) GPS timing receiver implement the correction. Steve, you'd
have fun with a GPS timing receiver like a Thunderbolt or an M12;
all those subframe parameters can be dumped over the serial port
and played with.

> The document also coins the term UTC(GPS) with very interesting
> footnotes disclaiming the validity of the use of such a term.

I doubt Al coined that term; I recall seeing it long before. But like
the editor implies, people realized it was not a valid term and so
you rarely see it any more. Maybe marketing people still use it.
I remember being gently corrected by the BIPM and I stopped
using it myself. I think UTC(tvb) is ok, though ;-)

/tvb


_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20090103/b4957e90/attachment.html>

From zefram at fysh.org  Sat Jan  3 09:28:46 2009
From: zefram at fysh.org (Zefram)
Date: Sat, 3 Jan 2009 14:28:46 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901031315520.19349@hermes-1.csi.cam.ac.uk>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<alpine.LSU.2.00.0901031315520.19349@hermes-1.csi.cam.ac.uk>
Message-ID: <20090103142846.GT2263@fysh.org>

Tony Finch wrote:
>(Um, do we actually know the earth's angular momentum and moment of
>inertia to any useful accuracy?

Our knowledge of the planets' masses is limited.  From watching orbits
we know very precisely the product of each planet's mass with the
gravitational constant.  But we only know the gravitational constant
itself to about five significant figures, and so we don't know the
absolute planetary masses any more precisely than that.  This imposes a
limit on our knowledge of angular momentum, and many other quantities that
have to be derived by multiplying a directly-observed quanity by mass.

-zefram

From jhardis at tcs.wap.org  Sat Jan  3 09:58:05 2009
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Sat, 3 Jan 2009 09:58:05 -0500
Subject: [LEAPSECS] temporal turf wars
In-Reply-To: <5B265E66-FB13-41F6-B640-DA5F96E75A9A@mimectl>
References: <20090103044315.GA32266@ucolick.org>,
	<56E257659FAB46B292DA0A8DEDDB9A12@pc52>
	<5B265E66-FB13-41F6-B640-DA5F96E75A9A@mimectl>
Message-ID: <p06230901c58526fc6b3a@[192.168.0.5]>

>While I can't speak for the USNO's sister-institution, I do 
>remember the paper referenced below.  It was presented at a PTTI 
>meeting by someone who at that time was an employee of NIST and this 
>must be why they include it in their reprint library.  I am quite 
>sure that it does not now represent nor ever has represented any 
>official position of NIST in any way.

Furthermore, the careful reader will note that the paper contains no 
NIST data, does not describe any NIST operational activity, and 
involves no NIST institutional equities.

For that matter, the paper has no authorship from any USG agency 
whose data and equities *are* being discussed.

   - Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20090103/3395fa88/attachment-0001.htm>

From seaman at noao.edu  Sat Jan  3 10:09:28 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 3 Jan 2009 08:09:28 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901031315520.19349@hermes-1.csi.cam.ac.uk>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<alpine.LSU.2.00.0901031315520.19349@hermes-1.csi.cam.ac.uk>
Message-ID: <DFF642C4-E47A-4E80-ADBC-7A8B4677C60E@noao.edu>

Tony Finch wrote:

> (Um, do we actually know the earth's angular momentum and moment of  
> inertia to any useful accuracy? I would have thought models would be  
> based directly on angular velocity since that can be measured more  
> precisely.)
>
> I think it's wrong to say that a directly measurable value (such as  
> apparent solar time) is less real when measured than when derived  
> from a model!
>
> Perhaps the word you are looking for is "fundamental".

And in several recent messages I've used the term angular velocity.

I'm happy with the term fundamental.

The point is that the Princes of the ITU, to borrow Steve Allen's  
metaphor, sit in a hushed chamber (which might extend to Polycom  
participants) and solemnly debate the future of time on Earth.

While they are debating this, it is a mental model they have about  
timekeeping that guides the discussions.  Their mental model clearly  
must include the notion that mean solar time is dispensable - else  
they wouldn't be trying to dispense with it.

The mental model of mean solar time is, however, indispensable.  What  
we are really debating is not how to change from one standard to  
another, but rather how to enable two very different conceptions of  
time to better coexist.

Nobody here has indicated an unwillingness to haggle.  It seems like  
we would all be delighted to see the leap second schedule extended in  
some fashion.  It appears a two or three year lead time is possible  
even from a cursory look at the data.  Even an extension from six  
months to a year would be appreciated.  Other possibilities exist.

Only the ITU has a completely immovable position - a position that  
appears to be built on a faulty mental model.

Rob


From phk at phk.freebsd.dk  Sat Jan  3 10:16:47 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 03 Jan 2009 15:16:47 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: Your message of "Sat, 03 Jan 2009 08:09:28 MST."
	<DFF642C4-E47A-4E80-ADBC-7A8B4677C60E@noao.edu> 
Message-ID: <22692.1230995807@critter.freebsd.dk>

In message <DFF642C4-E47A-4E80-ADBC-7A8B4677C60E at noao.edu>, Rob Seaman writes:

>While they are debating this, it is a mental model they have about  
>timekeeping that guides the discussions.  Their mental model clearly  
>must include the notion that mean solar time is dispensable - else  
>they wouldn't be trying to dispense with it.

Nobody is "dispensing with mean solar time", you will always be able
to calculate it if you want to.

-- 
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 magnus at rubidium.dyndns.org  Sat Jan  3 10:32:04 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 03 Jan 2009 16:32:04 +0100
Subject: [LEAPSECS] temporal turf wars
In-Reply-To: <56E257659FAB46B292DA0A8DEDDB9A12@pc52>
References: <20090103044315.GA32266@ucolick.org>
	<56E257659FAB46B292DA0A8DEDDB9A12@pc52>
Message-ID: <495F84F4.2050500@rubidium.dyndns.org>

Tom Van Baak skrev:
>> An interesting NIST document from 2000 gives insight into the turf wars
>> about precision time scales.
>>
>> http://tf.nist.gov/general/pdf/1429.pdf
>>
>> The document makes it clear that GPS time was never designed to follow
>> UTC(USNO) (and by implication, TAI).
> 
> I think you're misreading that sentence. GPS is in fact steered to
> the USNO MC which is steered to UTC. But I think the steering
> parameters are quite different between the two though. I also
> suspect there have been improvements in the past ten years.
> Demetrios can explain more, if needed.

It is certainly true that "GPS time was never designed to represent the 
DoD's precise time source, UTC(USNO)". GPS Phase I did not include 
navigation messages for time corrections or ionospheric correction model 
for that matter [1].

This was introduced at a later stage [2] as the initial system 
evaluation was completed. The GPS Program Office polled potential users 
for their needs and it was decided that adding the feature would be "a 
piece of cake" (actual words in article). UTC access through GPS can be 
dated back to 1983 (exact time is not available in my sources, but the 
articles is from 1983 and says "now".)

So the statement in the NIST article [3] is correct with other sources 
and it seems updated practices have shown that the introduced method to 
achieve it is fairly successful considering that the system was not 
specifically designed for it but certainly had good potential. The 
article is rather a report on work to improve the process, which is 
indeed what the Abstract is saying.

Thus, we can totally leave NIST vs USNO political issues out of this 
one, as it has a track record back into the early days of GPS 
development itself.

[1] A. J. Van Dierendonck, S. S. Russell, E. R. Kopitzke and M. Birnbaum 
"The GPS Navigation Message", ION Papers published in NAVIGATION, Global 
Positioning System Volume I.

[2] A. J. Van Dierendonck, W. C. Melton "Applications of Time Transfer 
Using NAVSTAR GPS", ION Papers published in NAVIGATION, Global 
Positioning System Volume II.

[3] A. Gifford "One-Way GPS Time Transfer 2000", 32nd Annual PTTI Meeting.

Cheers,
Magnus

From adi at stav.org.il  Sun Jan  4 04:44:38 2009
From: adi at stav.org.il (Adi Stav)
Date: Sun, 4 Jan 2009 11:44:38 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
Message-ID: <20090104094438.GD6161@stav.org.il>

On Fri, Jan 02, 2009 at 08:29:21PM -0700, Rob Seaman wrote:
>
> Civil time is solar time.  The rate is the issue, not local offsets.   
> Let's move past the fantasy that the ITU can redefine timescales willy- 
> nilly to serve the requirements of a civilization of mole people, and  
> rather address the actual requirements of our own civilization.

I'm trying to understand this position. I have a question.

If I understand correctly, you require that civil time is kept synchronized with mean solar time, and you also agree that UTC, which is synchronized to mean solar time with DUT of less than one second, complies with this requirement.

Then, what is the maximum DUT a time standard can have and still comply with this requirement? How is this maximum arrived at? Or, if compliance with the requirement cannot be decided in such terms, then in what terms can it be decided?

From seaman at noao.edu  Sun Jan  4 10:36:31 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 08:36:31 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090104094438.GD6161@stav.org.il>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
Message-ID: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>

Adi Stav wrote:

> On Fri, Jan 02, 2009 at 08:29:21PM -0700, Rob Seaman wrote:
>>
>> Civil time is solar time.  The rate is the issue, not local offsets.
>> Let's move past the fantasy that the ITU can redefine timescales  
>> willy-
>> nilly to serve the requirements of a civilization of mole people, and
>> rather address the actual requirements of our own civilization.
>
> I'm trying to understand this position. I have a question.

I appreciate both the question and the polite way it was asked :-)

> If I understand correctly, you require that civil time is kept  
> synchronized with mean solar time, and you also agree that UTC,  
> which is synchronized to mean solar time with DUT of less than one  
> second, complies with this requirement.

I am the one expressing these opinions, yes, but this is a broadly  
derived requirement.  UTC currently satisfies it.  The ITU proposal  
would not.

> Then, what is the maximum DUT a time standard can have and still  
> comply with this requirement? How is this maximum arrived at? Or, if  
> compliance with the requirement cannot be decided in such terms,  
> then in what terms can it be decided?

Well stated.  Requirements derive from use cases.  Use cases pertain  
to all the stakeholders.  In the case of civil timekeeping, the  
stakeholders are all the people on Earth.  Clearly everybody can't  
participate in making the decision, but a little humility in the ITU's  
decision-making process would be appreciated.

I remain flabbergasted that of all the postings I've made to this list  
over the years - postings like the recent one that speculated 5  
billion years into the future - that of all these, the ones to  
generate full-throated outrage as a result are when I humbly suggest  
that normal system engineering protocols be followed.

Which is to say that I can speculate on an acceptable maximum value  
for DUT1, but that misses the point.

I could say, for example, that 4 seconds wouldn't make me gag too  
badly (even though this corresponds to a full arc-minute at the  
equator).  If we feed this into some Bayesian simulation using  
historical values from Bulletin A to predict the baseline truth of  
Bulletin B, this seems likely to give us a decade or more lead time on  
announcing a leap second schedule.

But speculating on a solution and then inverting the process to define  
the problem is not a very clever sort of engineering.  Rather,  
characterize the problem first.  With a clear set of requirements in  
hand, it might well be - it almost surely will be - that we would  
identify a consensus solution that satisfies all stakeholders much,  
much better.

A civil timescale is not like a technical timescale.  We are  
attempting to satisfy many different purposes at the same time.  The  
"easiest way out" is very likely to be one of the worst choices.

My suggestion for the skeleton of a process is:

1) Perform a more careful simulation as in the Arias, et. al. paper:

	http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf

Vary the parameters, characterize how well predictive scheduling of  
leap seconds can actually do.

2) Reach an interim consensus on a reasonable trade-off of the  
parameters.

3) Implement this under the current standard (or make a modest, non- 
controversial change to the standard as required).

Simultaneously:

4) Seek funding for a proper long term study of the requirements of  
civil timekeeping.  Surely some combination of national and  
international funding would be available to do the job right.

5) I have to believe that #4 could have resulted in findings in less  
than the nine years the current lack of a coherent process has burned  
through.

6) With actual requirements in hand, perform a broad trade-off of the  
very distinct options that have been mentioned here over the years.   
It is likely that a coherent set of requirements will suggest several  
options we have never even considered.

7) Further debates will then be informed by, and strengthened by, the  
requirements and resulting trade-off study, but also by very standard  
methods of system engineering such as risk analyses, sensitivity  
analyses, etc and so forth.

8) This isn't only the best way to do the job, it is the quickest way  
to finish it.

Rob


From seaman at noao.edu  Sun Jan  4 10:47:06 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 08:47:06 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <885BB969-BE30-4F94-8A28-3AA5069F9872@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>	<20090101.183308.128309630.imp@bsdimp.com>	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>
	<495DCA5C.8050907@rubidium.dyndns.org>
	<885BB969-BE30-4F94-8A28-3AA5069F9872@noao.edu>
Message-ID: <9A05AD0B-7141-4EF4-BB1E-88EA5A4E8732@noao.edu>

Our humble and long suffering moderator informs me that this message  
bounced a few days back since the attachment was too big.  My  
apologies, since my more recent messages were predicated on folks  
having seen this plot.

I've put the attachment online as I should have in the first place:

	http://iraf.noao.edu/~seaman/images/HowLongIsADay.pdf

Rob
--

On Jan 2, 2009, at 2:29 AM, Rob Seaman wrote:

> Let's see if an attachment will help.  Here's a slide from a  
> conference session a few years back.  I think this was in San  
> Lorenzo de El Escorial, Spain, which I mention since the highlight  
> of that conference was fittingly a solar eclipse.  (Well, my  
> personal highlight was a day trip to see Guernica at the Reina Sof?a.)
>
> If the attachment makes it through, imagine zooming out by a factor  
> of 200X so the y-axis reaches one full day from 0 to 86400 seconds.   
> The wiggle due to the eccentricity of the Earth's orbit and the tilt  
> of the poles will vanish in the anti-aliasing.  There will be a just  
> barely visible offset between the sidereal ("relative to the stars")  
> day length and the mean solar day length - just under 4 minutes out  
> of 1440 minutes per day.  Add up 4 minutes per day times 365 days  
> and you end up with an extra day relative to the stars.
>
> Except that this is looking at it backwards.  We really spin with  
> respect to the stars.  All the solar system action is foreground  
> folderol.  There is the simple offset to the mean solar day from  
> lapping the sun once per year.  And the wiggle on top of that of the  
> apparent solar day from the elliptical orbit and the tilt.  And the  
> equation of time / analemma (not shown) from integrating the slight  
> wiggle throughout the year.  (Well, maybe it makes more sense to put  
> the tilt into the analemma.)
>
> My thesis is that a lot of the thrashing on this list over the years  
> has come from allowing the apparent solar issues to cloud the more  
> fundamental mean solar day.  (Yes, the pun was intended, get over it.)
>
> Rob
> ---

http://iraf.noao.edu/~seaman/images/HowLongIsADay.pdf

From seaman at noao.edu  Sun Jan  4 11:19:13 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 09:19:13 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <F84C3542-3C94-4FA0-B771-0BEA3FF1AF1A@noao.edu>
References: <22692.1230995807@critter.freebsd.dk>
	<EC649B92-C4EE-4424-8A7A-EEDBF97DD3D9@noao.edu>
	<F84C3542-3C94-4FA0-B771-0BEA3FF1AF1A@noao.edu>
Message-ID: <7F659F29-8923-4ED5-8073-1993BF478C70@noao.edu>

Poul-Henning Kamp wrote:

> Nobody is "dispensing with mean solar time", you will always be able  
> to calculate it if you want to.

Just as you are now able to calculate TAI from UTC :-)

The issue, of course, is in details.

By redefining UTC, the ITU proposal would require rewriting our  
extensively and remotely deployed codebase simply to maintain access  
to mean solar time.  This is a mirror reflection of what you complain  
about on your part - other than that we have been coding to the  
standard all this time and others have apparently not.

There's no need to revisit entrenched positions.  Rather, let's seek a  
new solution that is satisfactory to all.  This is not a zero-sum game.

Rob


From mgy1912 at cox.net  Sun Jan  4 14:50:34 2009
From: mgy1912 at cox.net (Brian Garrett)
Date: Sun, 4 Jan 2009 11:50:34 -0800
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
References: <55773.1230819692@critter.freebsd.dk>
	<Pine.BSO.4.58.0901011356230.599@www.blarfy.net>
Message-ID: <F0075D7CD194462791A394026A73AD3F@company48fcb68>


----- Original Message ----- 
From: <blb8 at po.cwru.edu>
To: "Leap Second Discussion List" <leapsecs at leapsecond.com>
Sent: Thursday, January 01, 2009 1:57 PM
Subject: Re: [LEAPSECS] DCF77, HBG, MSF, two out of three


>> From: Poul-Henning Kamp <phk at phk.freebsd.dk>
>>
>> DCF77 got right, as always.
>>
>> HBG also got it right this time.
>>
>> MSF still fumbles the DUT1 bits.
>>
>> http://phk.freebsd.dk/Leap/20081231/
>
> Very nice.  Alas, my receiver isn't close enough to the computer and I 
> didn't think to record the signal.
>
> WWV got it right, as far as I could tell.  I'm not sure if the DUT1 bits 
> were correct in the first minute or not.
>
Sprint's cellular network has still NOT got it right,after four days.  My 
cell phone, whose time display used to change right on the tick of the UTC 
second, is now one second slow.  Sprint is a CDMA network, which as far as I 
know runs on GPS time, so it would appear that some code indicating the 
number of seconds difference between UTC and GPS ws not updated.

GSM networks like T-Mobile and AT&T are just fine with wall-clock time so 
they can happily be off by two minutes and no one but us anal-retentives 
will know or care :)  Verizon is CDMA so they should have updated, unless 
they goofed like Sprint.


Brian Garrett 


From lang at unb.ca  Sun Jan  4 15:11:13 2009
From: lang at unb.ca (Richard B. Langley)
Date: Sun,  4 Jan 2009 16:11:13 -0400
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
In-Reply-To: <F0075D7CD194462791A394026A73AD3F@company48fcb68>
References: <55773.1230819692@critter.freebsd.dk>
	<Pine.BSO.4.58.0901011356230.599@www.blarfy.net>
	<F0075D7CD194462791A394026A73AD3F@company48fcb68>
Message-ID: <1231099873.496117e1ed706@webmail.unb.ca>

The clock on my Bell Mobility (CDMA) phone is clicking over about 2 seconds FAST.

Quoting Brian Garrett <mgy1912 at cox.net>:

> 
> ----- Original Message ----- 
> From: <blb8 at po.cwru.edu>
> To: "Leap Second Discussion List" <leapsecs at leapsecond.com>
> Sent: Thursday, January 01, 2009 1:57 PM
> Subject: Re: [LEAPSECS] DCF77, HBG, MSF, two out of three
> 
> 
> >> From: Poul-Henning Kamp <phk at phk.freebsd.dk>
> >>
> >> DCF77 got right, as always.
> >>
> >> HBG also got it right this time.
> >>
> >> MSF still fumbles the DUT1 bits.
> >>
> >> http://phk.freebsd.dk/Leap/20081231/
> >
> > Very nice.  Alas, my receiver isn't close enough to the computer and I 
> > didn't think to record the signal.
> >
> > WWV got it right, as far as I could tell.  I'm not sure if the DUT1 bits 
> > were correct in the first minute or not.
> >
> Sprint's cellular network has still NOT got it right,after four days.  My 
> cell phone, whose time display used to change right on the tick of the UTC 
> second, is now one second slow.  Sprint is a CDMA network, which as far as I 
> know runs on GPS time, so it would appear that some code indicating the 
> number of seconds difference between UTC and GPS ws not updated.
> 
> GSM networks like T-Mobile and AT&T are just fine with wall-clock time so 
> they can happily be off by two minutes and no one but us anal-retentives 
> will know or care :)  Verizon is CDMA so they should have updated, unless 
> they goofed like Sprint.
> 
> 
> Brian Garrett 
> 
> _______________________________________________
> 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 adi at stav.org.il  Sun Jan  4 16:15:01 2009
From: adi at stav.org.il (Adi Stav)
Date: Sun, 4 Jan 2009 23:15:01 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
References: <alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
Message-ID: <20090104211501.GE6161@stav.org.il>

On Sun, Jan 04, 2009 at 08:36:31AM -0700, Rob Seaman wrote:
> Adi Stav wrote:
>>
>> I'm trying to understand this position. I have a question.
>
> I appreciate both the question and the polite way it was asked :-)

Thanks for that, and for your answer :)

> I remain flabbergasted that of all the postings I've made to this list  
> over the years - postings like the recent one that speculated 5 billion 
> years into the future - that of all these, the ones to generate 
> full-throated outrage as a result are when I humbly suggest that normal 
> system engineering protocols be followed.

Maybe because discussing possible solutions is much more interesting
than talking about funding long-term requirements research, after all.

> Which is to say that I can speculate on an acceptable maximum value for 
> DUT1, but that misses the point.

But surely there's some value in exploration of the problem and
solution spaces beforehand. In can help guide subsequent efforts and
decisions.

> I could say, for example, that 4 seconds wouldn't make me gag too badly 
> (even though this corresponds to a full arc-minute at the equator).  If 
> we feed this into some Bayesian simulation using historical values from 
> Bulletin A to predict the baseline truth of Bulletin B, this seems likely 
> to give us a decade or more lead time on announcing a leap second 
> schedule.

Then why 4 seconds? Because they could be predicted a decade in advance?
Isn't that putting the cart before the horses? I think the "lead time"
is a different requirement altogether. (Although, for some values you might 
not be able to satisfy both at the same time.)

If I reckon correctly, people on this list specified 20 or 60 minutes as
their guesses for the limit, based on current human tolerance as witnessed 
by our indifference towards the Equation of Time and our own design of 
the time zone system. Clearly, you think DUT should be smaller. Why? For
practical reasons of astronomy? For other reasons?

Or, perhaps, it's not the *magnitude* of DUT but its permanence? Maybe
civil time can correct for the secular drift and ignore the decade
noise? (*That* could be predicted millenia in advance.)

From imp at bsdimp.com  Sun Jan  4 21:15:36 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 04 Jan 2009 19:15:36 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <496157C4.2050300@erols.com>
References: <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org>
	<496157C4.2050300@erols.com>
Message-ID: <20090104.191536.179953595.imp@bsdimp.com>

[[ continuation of a discussion from time-nuts ]]

In message: <496157C4.2050300 at erols.com>
            Chuck Harris <cfharris at erols.com> writes:
: Magnus Danielson wrote:
: > Chuck Harris skrev:
: >> One of us is confused about what time_t is... I think it is
: >> you.
: > 
: > I know of three different ways to interpret it. They fit different purposes.
: > 
: >> time_t is a 32 bit (depreciated), or 64 bit integer that contains
: >> the number of seconds since the epoch.  It is not to be adjusted
: >> for leap seconds according to POSIX, and unix convention.
: > 
: > This is one, no two, of the interpretations I know of.
: 
: Good!
: 
: >> Everything to do with UTC and leap seconds is a library function
: >> in most unixes that translates the leap second free time_t into
: >> the leap second adjusted broken-down-time UTC.
: > 
: > Exactly where? Do please tell me what the unified way of getting UTC 
: > time is. Oh, when there is a leap second it needs to give correct 
: > counting as well.
: 
: If the unix supports leap second, which usually requires ntp, gmtime()
: should report the UTC time correctly.

POSIX doesn't support leap seconds.  At all.  They do not exist in
POSIX's time_t.

: > Joe has in private conversations pointed out a POSIX interface which 
: > could be used.
: > 
: >> Again, are you telling me that time_t is getting adjusted for leap
: >> seconds?  If so, when did this change?
: > 
: > To the best of _my_ knowledge (which can be wrong) this is what is being 
: > done in practice, which is outside of the POSIX standard, but has the 
: > effect that 00:00:00 always midnight, which POSIX needs. This is a third 
: > interpretation...
: 
: Yes, but this is not UTC midnight, but unix time or POSIX time midnight.
: Unix time midnight, and POSIX time midnight drift from UTC midnight as the
: leap seconds get added or removed.

They are all the same thing.  POSIX midnight, UTC midnight and Unix
midnight all necessarily translate to the same value on a POSIXly
correct system.

: Some of the libc functions that convert time_t to broken down time convert
: to UTC, and others convert to POSIX/Unix time... which is, I guess 24 seconds
: fast?

No.  That's not POSIXly correct.  There are some systems that
implement this, but they aren't POSIX compliant.

: Ntpd doesn't mess with time_t when it makes its leap second corrections,
: but rather messes with tables and counters used by gmtime(), etal..  The
: only time that ntpd messes with time_t is to slew it so that your system's
: time_t is the same as everyone elses... (The number of si seconds since
: the epoch without adjustments for leap seconds.)

Actually, you are right.  ntpd doesn't mess with it, but the kernel
does.  The kernel steps time backwards 1 second to accont for the leap
second.  It has to, since the leap second has no unique value in a
time_t, in a POSIXly correct system.  This is what is horribly broken
about POSIX: leap second exist, but are explicitly ignored in POSIX.

: > If somebody (say PHK) got out and slapped my face and say this is a 
: > total misunderstanding, this is pretty good after all. If this practice 
: > does exist, then we still have three interpretations and they are in 
: > conflict with each other even after giving up on introducing leap 
: > seconds. So we have two or three interpretation of the POSIX timescale, 
: > one with pure SI seconds, one with rubber seconds up till 
: > 1972-00-00T00:00:00Z and then SI seconds and a third which is like the 
: > second but re-aligned on each leap second event so that midnights match.
: > 
: > This is only an issue if the POSIX scale is under external control.
: > 
: > And yes, do tell me how I get UTC on all platforms.
: 
: On all platforms?  Even my VCR?  That's a tall order.  On unix
: platforms, gmtime() will do the trick... assuming that leap seconds are
: supported.

Right.  It can't do that in a POSIXly correct system, but system that
doesn't completely comply with POSIX can choose to implement things
this way.

The problem is that when a system is implemented this way, you
suddenly have a number of programs that report time wrong by 24
seconds because they make the POSIX assumption that time_t % 86400 is
necessarily midnight (or some other assumption that is equivalent).

There are many many programs that compute a time_t based on what I've
called 'naive math' (since it is based on the naive assumption that
leap seconds do not exist).  It is not uncommon to see something akin
to:
	// compute Dec 23, 1988 12:34:54
	time_t t = (18 * 365 + 5) * 86400 + 12 * 3600 + 34 * 60 + 54;

(well, usually that's burried in the program's own implementation of
gmtime, but you get the idea).  Also common is code that looks like:

	time_t wakeup;

	wakeup = time(NULL) + 86400;	/* Same time tomorrow */
	while (1) {
	        /* Do something */
		while (time(NULL) < wakeup)
	      		sleep (1);
		wakeup += 86400;	/* Same time tomorrow */
	}

or variations on this theme where they can assume a time of day
computation and need no leap second tables.  Such code is POSIXly
correct, but breaks with the 'right' timezones from Olson.

So time_t is effectively defined in POSIX to be:

	d * 86400 + min(tod(x), 86399)

where d is the number of days since 01-01-1970, and tod is the second
since midnight within the day.

: > Regardless, this just shows how complex the issue is. There seems that 
: > there is no "correct" interpretation that everyone can agree with as a 
: > basis. If there is I'll be much happier and go away a bit wiser.
: 
: The only interpretation that would make me happy is one where UTC no longer
: requires leap seconds... but that is a different subject.

Yea, there's much opinion on the wisdom of that, or the lack of wisdom
of that, to be had on this list...

Warner

From jhardis at tcs.wap.org  Sun Jan  4 22:34:29 2009
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Sun, 4 Jan 2009 22:34:29 -0500
Subject: [LEAPSECS] Reliability
In-Reply-To: <9A05AD0B-7141-4EF4-BB1E-88EA5A4E8732@noao.edu>
References: <EB2D04A4-F7C4-4A3A-998A-EEFDDAA8B86E@noao.edu>
	<alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<Pine.BSO.4.58.0901012219030.22445@www.blarfy.net>
	<495DCA5C.8050907@rubidium.dyndns.org>
	<885BB969-BE30-4F94-8A28-3AA5069F9872@noao.edu>
	<9A05AD0B-7141-4EF4-BB1E-88EA5A4E8732@noao.edu>
Message-ID: <p06230900c587302c94fc@[192.168.0.5]>

>I've put the attachment online as I should have in the first place:
>
>	http://iraf.noao.edu/~seaman/images/HowLongIsADay.pdf

Nice.

Thanks!

   - Jonathan

From jhardis at tcs.wap.org  Sun Jan  4 22:40:22 2009
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Sun, 4 Jan 2009 22:40:22 -0500
Subject: [LEAPSECS] DCF77, HBG, MSF, two out of three
In-Reply-To: <F0075D7CD194462791A394026A73AD3F@company48fcb68>
References: <55773.1230819692@critter.freebsd.dk>
	<Pine.BSO.4.58.0901011356230.599@www.blarfy.net>
	<F0075D7CD194462791A394026A73AD3F@company48fcb68>
Message-ID: <p06230901c58730a7b1ac@[192.168.0.5]>

>Sprint's cellular network has still NOT got it right,after four 
>days.  My cell phone, whose time display used to change right on the 
>tick of the UTC second, is now one second slow.  Sprint is a CDMA 
>network, which as far as I know runs on GPS time, so it would appear 
>that some code indicating the number of seconds difference between 
>UTC and GPS ws not updated.
>
>...  Verizon is CDMA so they should have updated, unless they goofed 
>like Sprint.

My experience with one of the CDMA carriers is that when Daylight 
Savings Time begins or ends, the handset display is not updated until 
you make a call.

Yes, the cell sites of CDMA carriers sync to GPS so that they are in 
sync with each other at the microsecond level.  However, what you're 
seeing could also be a user-equipment issue.

   - Jonathan

From seaman at noao.edu  Sun Jan  4 22:58:29 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 20:58:29 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
References: <alpine.LSU.2.00.0901020043510.31331@hermes-1.csi.cam.ac.uk>
	<96C34D96-8A20-453A-B4A6-B8491287B1B7@noao.edu>
	<20090101.183308.128309630.imp@bsdimp.com>
	<984B76C7-E9A9-46BD-B551-D45A5ABB3CC8@noao.edu>
	<20090102110415.GA22707@fysh.org>
	<5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
Message-ID: <53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>

Here's a notion I don't recall seeing before on the list:

Coordinate leap seconds with leap days.  Introduce an integral number  
of leap seconds each February 29th.  Discuss.

Adi Stav wrote:

> Then why 4 seconds? Because they could be predicted a decade in  
> advance?  Isn't that putting the cart before the horses?

Yes, indeed.  You asked a question.  I provided a guess.  Personally,  
I think the current standard is better than allowing celestial  
coordinates to slosh around by an arcminute, but it is not the  
astronomers here who have refused to dicker.

> If I reckon correctly, people on this list specified 20 or 60  
> minutes as their guesses for the limit

Some people said such things.  Why lend them greater weight than  
alternate opinions?

Nobody has specified anything.  Specifications relate to solution  
space.  We have yet to discover the requirements describing the  
problem space.  There is nothing to specify against.

> Clearly, you think DUT should be smaller. Why? For practical reasons  
> of astronomy? For other reasons?

Yes and yes.  A static geographic offset is different from introducing  
a permanent bias in the rate.  A zero-mean periodic variation as in  
the equation of time is different from a permanent bias.  Seasonal  
step function jumps are different yet again.

Embargoing leap seconds (or their equivalent) for periods of decades  
or centuries is the same as not making intercalary adjustments at  
all.  It will introduce a tilted quadratic bias in the solar rate.   
The issue isn't about offsets at all, it is about preserving the  
correct functional form of civil timekeeping.

We have heard numerous times that the Gregorian calendar is acceptable  
because the schedule is predictable.  But why is the Gregorian  
calendar desirable?

It is desirable because it stabilizes the civil calendar against the  
natural annual rhythms of life on Earth AND because it does so at a  
fine enough resolution to permit smoothing across the decades and  
centuries.  When considering dates 400 years from now - or in colonial  
America - we don't have to wonder whether April occurs before or after  
the Vernal Equinox.

Well - except for the damage visited through the delayed Gregorian  
intercalary adjustment made by the British.  Why is there an English  
butterfly called an "April Fritillary"?  Because it emerges from its  
chrysalis in March.

The clock is a subdivision of the calendar.  It needs to be stabilized  
against natural diurnal rhythms on Earth.  And the resolution has to  
be fine enough to permit useful smoothing.

Over what period of time?  That is really the heart of this whole  
discussion.  The current UTC leap second policy is sufficient.  What  
is necessary?

We stabilize the calendar every 4 years.  Why would it be considered  
reasonable to forego stabilizing the clock for a thousand years?

Rob

From sla at ucolick.org  Sun Jan  4 23:20:38 2009
From: sla at ucolick.org (Steve Allen)
Date: Sun, 4 Jan 2009 20:20:38 -0800
Subject: [LEAPSECS] Reliability
In-Reply-To: <53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
Message-ID: <20090105042038.GA11656@ucolick.org>

On Sun 2009-01-04T20:58:29 -0700, Rob Seaman hath writ:
> Here's a notion I don't recall seeing before on the list:
>
> Coordinate leap seconds with leap days.  Introduce an integral number
> of leap seconds each February 29th.  Discuss.

This ignores the existing operational systems, and in particular NTP code.
Any change must be congruent with existing operational systems, and
that means nothing more than one second leaps at end of June or December.

It also does not address the underlying problem, which is
discontinuity in the broadcast time scale.

I think the "must not adversely affect existing operational systems"
clause is an inviolable rule for this process.  It's like the
physician's "First, do no harm" rule.

I'd like to think that "makes life better for some parties and not worse
for any party" is also paramount in this process.

--
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  Mon Jan  5 00:24:14 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 22:24:14 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105042038.GA11656@ucolick.org>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105042038.GA11656@ucolick.org>
Message-ID: <285ADA64-7A06-4520-8FEA-DBC16751E86D@noao.edu>

Steve Allen wrote:

> On Sun 2009-01-04T20:58:29 -0700, Rob Seaman hath writ:
>> Here's a notion I don't recall seeing before on the list:
>>
>> Coordinate leap seconds with leap days.  Introduce an integral  
>> number of leap seconds each February 29th.  Discuss.
>
> This ignores the existing operational systems, and in particular NTP  
> code.  Any change must be congruent with existing operational  
> systems, and that means nothing more than one second leaps at end of  
> June or December.
>
> It also does not address the underlying problem, which is  
> discontinuity in the broadcast time scale.
>
> I think the "must not adversely affect existing operational systems"  
> clause is an inviolable rule for this process.  It's like the  
> physician's "First, do no harm" rule.
>
> I'd like to think that "makes life better for some parties and not  
> worse for any party" is also paramount in this process.

Brainstorming comes in two phases:  1) generate ideas, and 2) winnow  
them down.  During the first phase, ideas should breed like rabbits.   
During the second phase, they should be matched against clear  
requirements.  Reexamine the requirements and repeat.

Whatever problem solving process we're following here (Monte Carlo  
conceptualization? :-) either we're in a phase of charactering the  
problem space or we're in a phase of characterizing the solution space.

If a problem phase, the discovery of requirements is the goal.  Care  
should be taken to express the essential idea behind each requirement,  
such as (perhaps):
	- change must be congruent with operational systems
	- does "congruent" mean the existence of a viable implementation plan?
	- a mechanism shall exist for managing discontinuities

A requirement that is worded either too specifically or too generally  
will bias the process.

If a solution phase, a quantitative trade-off study is the ultimate  
goal.  Before that can happen, the solution space should be  
extensively explored.  Often, aspects of several different notional  
solutions are combined to form a jointly richer concept.

The part I like most about the February 29th notion is that it  
standardizes all intercalary interactions at a very clearly stated  
moment.  Perhaps this is an aspect that could inform other possible  
solutions.

You'll also note that I didn't specify that this had to be applied to  
UTC.  The first step to implementing brand new technology is to break  
cleanly with the past.

Rob

From seaman at noao.edu  Mon Jan  5 00:36:12 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sun, 4 Jan 2009 22:36:12 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090104.191536.179953595.imp@bsdimp.com>
References: <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org>
	<496157C4.2050300@erols.com>
	<20090104.191536.179953595.imp@bsdimp.com>
Message-ID: <5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu>

M. Warner Losh wrote:

> POSIX doesn't support leap seconds.

I'm curious.  Is this the only widely recognized shortcoming of POSIX?

I mean - either POSIX is riddled with numerous other mistakes - or  
this is the only issue remaining to address before POSIX is  
perfected :-)

I suspect it is not the latter case, which suggests that there is a  
list of other such instances where POSIX fails to implement long- 
standing international standards.

Rob


From magnus at rubidium.dyndns.org  Mon Jan  5 00:37:08 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 06:37:08 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090104.191536.179953595.imp@bsdimp.com>
References: <4960C988.6090005@erols.com>
	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>
	<20090104.191536.179953595.imp@bsdimp.com>
Message-ID: <49619C84.3060300@rubidium.dyndns.org>

M. Warner Losh skrev:
> [[ continuation of a discussion from time-nuts ]]
> 
> In message: <496157C4.2050300 at erols.com>
>             Chuck Harris <cfharris at erols.com> writes:
> : Magnus Danielson wrote:
> : > Chuck Harris skrev:
> : >> One of us is confused about what time_t is... I think it is
> : >> you.
> : > 
> : > I know of three different ways to interpret it. They fit different purposes.
> : > 
> : >> time_t is a 32 bit (depreciated), or 64 bit integer that contains
> : >> the number of seconds since the epoch.  It is not to be adjusted
> : >> for leap seconds according to POSIX, and unix convention.
> : > 
> : > This is one, no two, of the interpretations I know of.
> : 
> : Good!
> : 
> : >> Everything to do with UTC and leap seconds is a library function
> : >> in most unixes that translates the leap second free time_t into
> : >> the leap second adjusted broken-down-time UTC.
> : > 
> : > Exactly where? Do please tell me what the unified way of getting UTC 
> : > time is. Oh, when there is a leap second it needs to give correct 
> : > counting as well.
> : 
> : If the unix supports leap second, which usually requires ntp, gmtime()
> : should report the UTC time correctly.
> 
> POSIX doesn't support leap seconds.  At all.  They do not exist in
> POSIX's time_t.

I agree with this. Since time_t will have the leap second and second 
prior to the leap second overlapped gmtime can not from time_t itself 
provide a correct mapping out of time_t. An additional flag/field needs 
to be used and when asking for current time an implementation could be 
using some interface to the kernel to read for instance the ntp 
interface flag, but doing that at any other point in time will not work 
as the time_t given is not matching the time of flags in the kernel.

> : > Joe has in private conversations pointed out a POSIX interface which 
> : > could be used.
> : > 
> : >> Again, are you telling me that time_t is getting adjusted for leap
> : >> seconds?  If so, when did this change?
> : > 
> : > To the best of _my_ knowledge (which can be wrong) this is what is being 
> : > done in practice, which is outside of the POSIX standard, but has the 
> : > effect that 00:00:00 always midnight, which POSIX needs. This is a third 
> : > interpretation...
> : 
> : Yes, but this is not UTC midnight, but unix time or POSIX time midnight.
> : Unix time midnight, and POSIX time midnight drift from UTC midnight as the
> : leap seconds get added or removed.
> 
> They are all the same thing.  POSIX midnight, UTC midnight and Unix
> midnight all necessarily translate to the same value on a POSIXly
> correct system.

After reading up (thanks to Joe giving me the homework) I fully agree 
with this. POSIX specify the mapping of UTC into time_t in an unambigous 
fashion, but it does not specify the mapping of time_t into UTC in an 
unambigous fashion.

I have identified 3 different interpretations of what time_t represents:

1) Number of SI seconds from 1970-01-01T00:00:00Z.

2) Number of UTC rubber seconds from 1970-01-01T00:00:00 to 
1972-01-01T00:00:00Z (non-inclusive) and from there the number of SI 
seconds, thus achieving an integer number of SI second difference 
between POSIX time_t and TAI, namely 10.

3) UTC mapping into time_t in such a fashion that UTC midnight and POSIX 
midnigth match.

POSIX.1-2008 actually defines the value of time_t as a strict mapping 
from the UTC value (see Clause 4 General Concepts, Sub-Clause 4.15 
Seconds Since the Epoch).

It goes on further if you go to the Clause A Rationale on sub-clause 
A.4.15 Seconds Since the Epoch it details further and does explicitly 
talk about how POSIX handles leap seconds or if you so whish, does not 
handle leap seconds.

> : Some of the libc functions that convert time_t to broken down time convert
> : to UTC, and others convert to POSIX/Unix time... which is, I guess 24 seconds
> : fast?
> 
> No.  That's not POSIXly correct.  There are some systems that
> implement this, but they aren't POSIX compliant.

The UTC => time_t mapping must be respected in the reverse mapping 
time_t => UTC, which is what POSIX.1-2008 explicitly state.

> : Ntpd doesn't mess with time_t when it makes its leap second corrections,
> : but rather messes with tables and counters used by gmtime(), etal..  The
> : only time that ntpd messes with time_t is to slew it so that your system's
> : time_t is the same as everyone elses... (The number of si seconds since
> : the epoch without adjustments for leap seconds.)
> 
> Actually, you are right.  ntpd doesn't mess with it, but the kernel
> does.  The kernel steps time backwards 1 second to accont for the leap
> second.  It has to, since the leap second has no unique value in a
> time_t, in a POSIXly correct system.  This is what is horribly broken
> about POSIX: leap second exist, but are explicitly ignored in POSIX.

Actually, to some degree you are both right and wrong. NTPD does fiddle 
with it, using the interface into the kernel. NTPD sets the flags which 
tells the kernel that there is an upcomming leap second and then the 
kernel adjust the system clock. This is evident in NTP documentation on 
leap-seconds, the interface specification for the kernel interface and 
also when looking into the Linux kernel code. All this in order to be 
POSIX compliant.

It is important to understand that the mapping between UTC and time_t is 
lossy in the sense that when adding a leap second, that second is not 
represented by a unique time_t value but it reuses a time_t value. All 
other UTC times than the added leap seconds will be unambigously 
represented in time_t for the time-span that time_t is defined.

If you need to represent UTC unambigously then a POSIX compliant time_t 
will no make you happy.

If you would honour interpretation 1 or 2 of time_t instead and let 
positive leap seconds remain encoded into time_t and use a leap-second 
table, then UTC => time_t and time_t => UTC mappings could be made 
totally unambigous. However, that would nto be POSIX.1-2008 compliant.

To also help understand the POSIX time_t, it does only say that it is 
nominally the SI second, thus writing off the requirements for 
non-steered systems.

> : > If somebody (say PHK) got out and slapped my face and say this is a 
> : > total misunderstanding, this is pretty good after all. If this practice 
> : > does exist, then we still have three interpretations and they are in 
> : > conflict with each other even after giving up on introducing leap 
> : > seconds. So we have two or three interpretation of the POSIX timescale, 
> : > one with pure SI seconds, one with rubber seconds up till 
> : > 1972-00-00T00:00:00Z and then SI seconds and a third which is like the 
> : > second but re-aligned on each leap second event so that midnights match.

Reading up on the facts I realized that the third one was the one POSIX 
used, not the first one as I earlier assumed. I thought I was going to 
kill the third one but ended up confirming it as the standard.

Chuck is basing his resoning on interpretation 1 or possibly 2. So yes, 
things DID change.

> : > This is only an issue if the POSIX scale is under external control.
> : > 
> : > And yes, do tell me how I get UTC on all platforms.
> : 
> : On all platforms?  Even my VCR?  That's a tall order.  On unix
> : platforms, gmtime() will do the trick... assuming that leap seconds are
> : supported.
> 
> Right.  It can't do that in a POSIXly correct system, but system that
> doesn't completely comply with POSIX can choose to implement things
> this way.

I agree.

> The problem is that when a system is implemented this way, you
> suddenly have a number of programs that report time wrong by 24
> seconds because they make the POSIX assumption that time_t % 86400 is
> necessarily midnight (or some other assumption that is equivalent).
> 
> There are many many programs that compute a time_t based on what I've
> called 'naive math' (since it is based on the naive assumption that
> leap seconds do not exist).  It is not uncommon to see something akin
> to:
> 	// compute Dec 23, 1988 12:34:54
> 	time_t t = (18 * 365 + 5) * 86400 + 12 * 3600 + 34 * 60 + 54;
> 
> (well, usually that's burried in the program's own implementation of
> gmtime, but you get the idea). 

Actually it duplicates mktime(), but mktime() does the same thing 
according to POSIX.1-2008.

> Also common is code that looks like:
> 
> 	time_t wakeup;
> 
> 	wakeup = time(NULL) + 86400;	/* Same time tomorrow */
> 	while (1) {
> 	        /* Do something */
> 		while (time(NULL) < wakeup)
> 	      		sleep (1);
> 		wakeup += 86400;	/* Same time tomorrow */
> 	}
> 
> or variations on this theme where they can assume a time of day
> computation and need no leap second tables.  Such code is POSIXly
> correct, but breaks with the 'right' timezones from Olson.
> 
> So time_t is effectively defined in POSIX to be:
> 
> 	d * 86400 + min(tod(x), 86399)
> 
> where d is the number of days since 01-01-1970, and tod is the second
> since midnight within the day.

I agree.

> : > Regardless, this just shows how complex the issue is. There seems that 
> : > there is no "correct" interpretation that everyone can agree with as a 
> : > basis. If there is I'll be much happier and go away a bit wiser.
> : 
> : The only interpretation that would make me happy is one where UTC no longer
> : requires leap seconds... but that is a different subject.
> 
> Yea, there's much opinion on the wisdom of that, or the lack of wisdom
> of that, to be had on this list...

It would not fully resolve the issue, but ease the problems, which is 
not enterly the same thing.

Cheers,
Magnus

From magnus at rubidium.dyndns.org  Mon Jan  5 00:42:55 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 06:42:55 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu>
References: <4960C988.6090005@erols.com>
	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>
	<5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu>
Message-ID: <49619DDF.7070506@rubidium.dyndns.org>

Rob,

Rob Seaman skrev:
> M. Warner Losh wrote:
> 
>> POSIX doesn't support leap seconds.
> 
> I'm curious.  Is this the only widely recognized shortcoming of POSIX?
> 
> I mean - either POSIX is riddled with numerous other mistakes - or this 
> is the only issue remaining to address before POSIX is perfected :-)
> 
> I suspect it is not the latter case, which suggests that there is a list 
> of other such instances where POSIX fails to implement long-standing 
> international standards.

Actually, if you do read the rationale and also the information I've got 
during private discussions it has become clear that it was the only 
solution they could agree on but not without much discussion and several 
proposals of improvement. There is room for improvements, but the 
current debate is mainly to make clear what is actually there and what 
is not there. It is not quite what you would expect.

Surely, this is not the only shortcoming of POSIX and the members of the 
committee seems pretty aware of this. I guess this is why they keep 
working on various improvements.

Cheers,
Magnus

From imp at bsdimp.com  Mon Jan  5 01:00:59 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 04 Jan 2009 23:00:59 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu>
References: <496157C4.2050300@erols.com>
	<20090104.191536.179953595.imp@bsdimp.com>
	<5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu>
Message-ID: <20090104.230059.635742094.imp@bsdimp.com>

In message: <5806D024-146D-43E4-AEA0-A7AA514E3EA4 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > POSIX doesn't support leap seconds.
: 
: I'm curious.  Is this the only widely recognized shortcoming of POSIX?

No.  There's others, but they are generally minor edge cases that
don't affect anything important.  Almost all the posix mistakes are
relegated to tty handling :).

: I mean - either POSIX is riddled with numerous other mistakes - or  
: this is the only issue remaining to address before POSIX is  
: perfected :-)
: 
: I suspect it is not the latter case, which suggests that there is a  
: list of other such instances where POSIX fails to implement long- 
: standing international standards.

This is the only international standard that I'm aware of that POSIX
implements wrong.  There are plenty of other international standards
that it doesn't implement, but those aren't really relevant (like,
say, ISO-9000).

The date handling can be used to implement non-conforming dates and
such, but as far as I know, the standard tools can be used to
implement conforming external representations.  This is unlike time_t
which is broken by design :(.

Warner

From jhawk at MIT.EDU  Mon Jan  5 01:06:34 2009
From: jhawk at MIT.EDU (John Hawkinson)
Date: Mon, 5 Jan 2009 01:06:34 -0500
Subject: [LEAPSECS] the leap second in the media
In-Reply-To: <alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk>
References: <alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk>
Message-ID: <20090105060634.GE29687@multics.mit.edu>

(chiming in a bit late...)

Tony Finch <dot at dotat.at> wrote on Thu,  1 Jan 2009
at 06:10:59 +0000 in <alpine.LSU.2.00.0901010602100.2395 at hermes-1.csi.cam.ac.uk>:

> Wednesday's PM on Radio 4 included an item about the way the keepers of
> the Big Ben clock handled the leap second. They slowed it down for several
> hours by removing a stack of old coins from a plate near the top of the
> pendulum to lower its centre of gravity. They replaced them again when it
> had lost a seond. Rubber seconds, 19th century style!

This is exactly how Unix systems handle changing the clock!
>From the Solaris adjtime(2) manpage:

DESCRIPTION
     The adjtime() function adjusts the system's  notion  of  the
     current  time  as returned by gettimeofday(3C), advancing or
     retarding it by the amount of time specified in  the  struct
     timeval pointed to by delta.

     The adjustment is effected by speeding up (if that amount of
     time is positive) or slowing down (if that amount of time is
     negative) the system's clock by some small percentage,  gen-
     erally a fraction of one percent. The time is always a mono-
     tonically increasing function. A  time  correction  from  an
     earlier call to adjtime() may not be finished when adjtime()
     is called again.

--jhawk at mit.edu
  John Hawkinson

From magnus at rubidium.dyndns.org  Mon Jan  5 01:19:22 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 07:19:22 +0100
Subject: [LEAPSECS] the leap second in the media
In-Reply-To: <20090105060634.GE29687@multics.mit.edu>
References: <alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk>
	<20090105060634.GE29687@multics.mit.edu>
Message-ID: <4961A66A.3000808@rubidium.dyndns.org>

John Hawkinson skrev:
> (chiming in a bit late...)
> 
> Tony Finch <dot at dotat.at> wrote on Thu,  1 Jan 2009
> at 06:10:59 +0000 in <alpine.LSU.2.00.0901010602100.2395 at hermes-1.csi.cam.ac.uk>:
> 
>> Wednesday's PM on Radio 4 included an item about the way the keepers of
>> the Big Ben clock handled the leap second. They slowed it down for several
>> hours by removing a stack of old coins from a plate near the top of the
>> pendulum to lower its centre of gravity. They replaced them again when it
>> had lost a seond. Rubber seconds, 19th century style!
> 
> This is exactly how Unix systems handle changing the clock!
>>From the Solaris adjtime(2) manpage:
> 
> DESCRIPTION
>      The adjtime() function adjusts the system's  notion  of  the
>      current  time  as returned by gettimeofday(3C), advancing or
>      retarding it by the amount of time specified in  the  struct
>      timeval pointed to by delta.
> 
>      The adjustment is effected by speeding up (if that amount of
>      time is positive) or slowing down (if that amount of time is
>      negative) the system's clock by some small percentage,  gen-
>      erally a fraction of one percent. The time is always a mono-
>      tonically increasing function. A  time  correction  from  an
>      earlier call to adjtime() may not be finished when adjtime()
>      is called again.

Not exactly, this is the old interface. Many uses a new interface when 
doing NTP to achieve better performance. Instead ntp_adjtime() is used.

The idea is similar thought. What happend was the the control loop was 
moved into the kernel for better performance. Implemented on many 
systems. For more info see:
http://www.cis.udel.edu/~mills/resource.html#micro

You could of course to some degree steer the clock on a machine by 
changing the computing load on it, as the tempco of most systems crystal 
is pretty bad. It would kinda work except when it is out of 
controlrange. I would not recommend such a tuning method, but it would 
be on the levels of those coins.

It is noteworthy that it is an old set of coins. Choosing a new set 
would require retuning of the set of coins being used. I would not mind 
seeing a measurement log from Big Ben...

Cheers,
Magnus

From msokolov at ivan.Harhan.ORG  Mon Jan  5 01:22:32 2009
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 5 Jan 2009 06:22:32 GMT
Subject: [LEAPSECS] [time-nuts] Leap Quirks
Message-ID: <0901050622.AA00754@ivan.Harhan.ORG>

Hello all,

This discussion about the meaning of UNIX and POSIX time_t in terms of
UTC/TAI/whatnot that has just moved here from the time-nuts list has
pushed some of my religious hot buttons, so I feel the rhetorical
imperative to state my position.

But first a disclaimer: I absolutely do not care about POSIX because it
is a standard which I refuse to bow down to.  I only care about UNIX,
the operating system that predates POSIX by at least a decade and a half.
I use Ancient UNIX systems which predate POSIX and will never-ever-ever
convert, so everything I say about UNIX time_t specifically applies to
non-POSIX, pre-POSIX and POSIX-defying UNIX systems, not to anything
POSIX-compliant.  Examples of systems I'm talking about are UNIX
Version 7 from 1979, UC Berkeley's 4.3BSD from 1986 and my own
4.3BSD-Quasijarus from which I send this E-mail in the present.

All that talk about whether UNIX time_t is supposed to track UTC or TAI
or whatever is totally wrong.  It has nothing to do with any kind of
precision timekeeping whatsoever, nor even with time itself in the
strict definition of that term.  Instead it is defined as a rotation
angle of a wall clock.  One good way to define Classic UNIX time_t would
be "the number of second marks by which the hands of a civil time clock
in Phoenix, Arizona have rotated since they displayed 1969-12-31T17:00:00".
(Or replace Phoenix, Arizona with any other civil jurisdiction that is
free of DST and adjust the time zone offset accordingly.)

The point is, it has everything to do with clocks in the non-precision
civil sense and nothing to do with time as seen by physicists and
metrologists.  Once again, UNIX time_t measures the rotation of clock
hands on some city tower in Phoenix, Arizona, *not* time.  If the hands
of a wall clock turn too slow or too fast relative to precision time,
time_t speeds up and slows down accordingly.  Angle, not time!

And while we are at it, in my definition a clock has absolutely nothing
to do with time.  A clock is a *civil* device (not a metrological one)
that tells people when to get up, when to go to bed, when to expect
meetings, phone calls, etc. and when to catch a bus to go to work or
school.  It has *absolutely nothing* to do with time as defined by
physicists.  (To be fair, it has nothing to do with Earth orientation
either, but the latter is a convenient reference to set clocks to in
the absence of a trusted higher civilisation.)

Of course those of you who choose to obey POSIX or whatever will probably
define time_t in some different way that takes precision timekeeping
into account and thus has some connection to time scales such as
UTC/TAI/whatever, but please realize that there are still non-POSIX
UNIX systems in the world and whenever you receive any kind of
communication over any network protocol from a non-POSIX UNIX system
under my control that contains a time_t value, that value will measure
the rotation angle of a clock in Phoenix, AZ, *NOT* time of any kind.
Nothing whatsoever to do with SI seconds or UTC or TAI, the units of my
time_t are tick marks on the round face of a Big Ben-style clock, not
SI seconds.  (Unfortunately Big Ben itself doesn't qualify because they
probably muck with it for DST; same story with the Kremlin tower clock
in Moscow.  Hence we need a civil clock of similar stature in a place
like Arizona where there's no DST abomination.)

MS

From msokolov at ivan.Harhan.ORG  Mon Jan  5 01:25:13 2009
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 5 Jan 2009 06:25:13 GMT
Subject: [LEAPSECS] [time-nuts] Leap Quirks
Message-ID: <0901050625.AA00774@ivan.Harhan.ORG>

M. Warner Losh <imp at bsdimp.com> wrote:

> Almost all the posix mistakes are
> relegated to tty handling :).

That's another major reason why I hate POSIX.  I will never adopt termios
and I'm very proud to have the original sgtty in 4.3BSD-Quasijarus instead!

MS

From imp at bsdimp.com  Mon Jan  5 01:42:49 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 04 Jan 2009 23:42:49 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <0901050622.AA00754@ivan.Harhan.ORG>
References: <0901050622.AA00754@ivan.Harhan.ORG>
Message-ID: <20090104.234249.31595721.imp@bsdimp.com>

In message: <0901050622.AA00754 at ivan.Harhan.ORG>
            msokolov at ivan.Harhan.ORG (Michael Sokolov) writes:
: under my control that contains a time_t value, that value will measure
: the rotation angle of a clock in Phoenix, AZ, *NOT* time of any kind.

Is that an adjusted or unadjusted clock? :)

Warner

From msokolov at ivan.Harhan.ORG  Mon Jan  5 01:46:31 2009
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 5 Jan 2009 06:46:31 GMT
Subject: [LEAPSECS] [time-nuts] Leap Quirks
Message-ID: <0901050646.AA00862@ivan.Harhan.ORG>

M. Warner Losh <imp at bsdimp.com> wrote:

> Is that an adjusted or unadjusted clock? :)

Adjusted for what?

MS

From phk at phk.freebsd.dk  Mon Jan  5 02:17:00 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 05 Jan 2009 07:17:00 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: Your message of "Sun, 04 Jan 2009 22:36:12 MST."
	<5806D024-146D-43E4-AEA0-A7AA514E3EA4@noao.edu> 
Message-ID: <80943.1231139820@critter.freebsd.dk>

In message <5806D024-146D-43E4-AEA0-A7AA514E3EA4 at noao.edu>, Rob Seaman writes:
>M. Warner Losh wrote:
>
>> POSIX doesn't support leap seconds.
>
>I'm curious.  Is this the only widely recognized shortcoming of POSIX?

No, POSIX has numerous defects and bad choices, but barring a major
effort by major governments, POSIX is what we have.

One particular horrible example of POSIX stupidity is the lack of
a pthread_mutex_assert() or the fact that pthread_cond_timedwait()
takes an absolute time as timeout, not time interval.

ISO-C has stupidities as well, I spent far more time on one of them
because because people didn't think clearly:

The strftime() function returns zero on error, or the length
of the string produced.

Now, imagine calling strftime("%p") in a locale which does not
use AM/PM indication because they are 24h based.

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 magnus at rubidium.dyndns.org  Mon Jan  5 02:23:07 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 08:23:07 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <0901050622.AA00754@ivan.Harhan.ORG>
References: <0901050622.AA00754@ivan.Harhan.ORG>
Message-ID: <4961B55B.4060107@rubidium.dyndns.org>

Michael,

Michael Sokolov skrev:
> Hello all,
> 
> This discussion about the meaning of UNIX and POSIX time_t in terms of
> UTC/TAI/whatnot that has just moved here from the time-nuts list has
> pushed some of my religious hot buttons, so I feel the rhetorical
> imperative to state my position.

You should be aware that the discussion was a discussion of what POSIX 
time_t and related POSIX functions are and are not providing. This is 
not to imply that it is THE perfect solution or has anything to do with 
precission timekeeping or for that matter the existence or not of leap 
seconds in the UTC to come.

> But first a disclaimer: I absolutely do not care about POSIX because it
> is a standard which I refuse to bow down to.  I only care about UNIX,
> the operating system that predates POSIX by at least a decade and a half.
> I use Ancient UNIX systems which predate POSIX and will never-ever-ever
> convert, so everything I say about UNIX time_t specifically applies to
> non-POSIX, pre-POSIX and POSIX-defying UNIX systems, not to anything
> POSIX-compliant.  Examples of systems I'm talking about are UNIX
> Version 7 from 1979, UC Berkeley's 4.3BSD from 1986 and my own
> 4.3BSD-Quasijarus from which I send this E-mail in the present.

Good for you. That the UNIX time_t is different from the POSIX time_t is 
one of the things which became clear during this thread. Something to 
know. You basically agree with this. Great.

> All that talk about whether UNIX time_t is supposed to track UTC or TAI
> or whatever is totally wrong.  It has nothing to do with any kind of
> precision timekeeping whatsoever, nor even with time itself in the
> strict definition of that term.  Instead it is defined as a rotation
> angle of a wall clock.  One good way to define Classic UNIX time_t would
> be "the number of second marks by which the hands of a civil time clock
> in Phoenix, Arizona have rotated since they displayed 1969-12-31T17:00:00".
> (Or replace Phoenix, Arizona with any other civil jurisdiction that is
> free of DST and adjust the time zone offset accordingly.)
> 
> The point is, it has everything to do with clocks in the non-precision
> civil sense and nothing to do with time as seen by physicists and
> metrologists.  Once again, UNIX time_t measures the rotation of clock
> hands on some city tower in Phoenix, Arizona, *not* time.  If the hands
> of a wall clock turn too slow or too fast relative to precision time,
> time_t speeds up and slows down accordingly.  Angle, not time!

The background for digging deep and discover what POSIX time_t was 
actually to discuss the availability of UTC and related timezone shifted 
variants to achieve local time as in civil time. This is not to achieve 
precise time in a metrologists sense, but there may very well be 
requirements for traceability for certain applications which is causing 
some of us some grief. Thus, talking in TAI or UTC form becomes 
necessary even if we are not talking metrologist quality of accuracy and 
stability.

> And while we are at it, in my definition a clock has absolutely nothing
> to do with time.  A clock is a *civil* device (not a metrological one)
> that tells people when to get up, when to go to bed, when to expect
> meetings, phone calls, etc. and when to catch a bus to go to work or
> school.  It has *absolutely nothing* to do with time as defined by
> physicists.  (To be fair, it has nothing to do with Earth orientation
> either, but the latter is a convenient reference to set clocks to in
> the absence of a trusted higher civilisation.)

Fine. But when we need coordinated time in computers we need some way to 
achieve it and some common time scale to measure along and adjust to. It 
can then be argued on the merits of vairious time scales for this 
purpose. The UTC with leap seconds and POSIX UTC to time_t mapping 
happends to be an unfortunate combination especially as we have leap 
seconds occuring.

We need to do these things for many reasons. Just realizing that POSIX 
does not provide exactly what we want is a good thing.

What you run on your systems is your thing and its all fine and dandy. 
We others may not have the same set of choices. I hope you don't have a 
problem with that. We need to solve those problems and have working 
solutions.

> Of course those of you who choose to obey POSIX or whatever will probably
> define time_t in some different way that takes precision timekeeping
> into account and thus has some connection to time scales such as
> UTC/TAI/whatever, but please realize that there are still non-POSIX
> UNIX systems in the world and whenever you receive any kind of
> communication over any network protocol from a non-POSIX UNIX system
> under my control that contains a time_t value, that value will measure
> the rotation angle of a clock in Phoenix, AZ, *NOT* time of any kind.

Well, we don't have a problem with that as such, however, IETF have 
specified UTC in their RFCs, such as RFC 3339 and assumed in for 
instance RFC5260 (altought not applicable to this case) so you are 
expected to deliver something which is at least similar to UTC in the 
emails you send. Not by us, but by IETF. It is there since this since it 
is convenient to have a common infrastructure for both time and format 
of time in order to make automatic detections of all various kinds. RFC 
3339 is on the standard track and is listed as a Proposed Standards. If 
you object to it, feel free to bring that issue to the IETF. This is not 
related to POSIX and is not directly correlated to how you choose to set 
your time_t, but related to how the emails out of your system looks. 
Then again, as long as nobody get you caught with sending horrendously 
wrong timestamps and blocking your email traffic you are probably home 
free never the less.

As for obeying POSIX, some of us must deliver POSIX so it is not much of 
a personal choice or preference. There is also possibilities to do 
things outside the real of POSIX which may be more appropriate for 
correct representations of various timescales such as UTC. This may 
still be outside the needs of high precission users but well within the 
needs of many real systems and this is the reason for us to discuss it.

Cheers,
Magnus

From magnus at rubidium.dyndns.org  Mon Jan  5 02:28:22 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 08:28:22 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <80943.1231139820@critter.freebsd.dk>
References: <80943.1231139820@critter.freebsd.dk>
Message-ID: <4961B696.7060103@rubidium.dyndns.org>

Poul-Henning,

Poul-Henning Kamp skrev:
> In message <5806D024-146D-43E4-AEA0-A7AA514E3EA4 at noao.edu>, Rob Seaman writes:
>> M. Warner Losh wrote:
>>
>>> POSIX doesn't support leap seconds.
>> I'm curious.  Is this the only widely recognized shortcoming of POSIX?
> 
> No, POSIX has numerous defects and bad choices, but barring a major
> effort by major governments, POSIX is what we have.
> 
> One particular horrible example of POSIX stupidity is the lack of
> a pthread_mutex_assert() or the fact that pthread_cond_timedwait()
> takes an absolute time as timeout, not time interval.
> 
> ISO-C has stupidities as well, I spent far more time on one of them
> because because people didn't think clearly:
> 
> The strftime() function returns zero on error, or the length
> of the string produced.
> 
> Now, imagine calling strftime("%p") in a locale which does not
> use AM/PM indication because they are 24h based.

It could be argued that:
A standard which is not revised constantly is a dead standard.

Thus:
A standard which does not have faults in it can't be revised constantly.

Cheers,
Magnus

From seaman at noao.edu  Mon Jan  5 02:46:54 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 00:46:54 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <0901050622.AA00754@ivan.Harhan.ORG>
References: <0901050622.AA00754@ivan.Harhan.ORG>
Message-ID: <F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>

Michael Sokolov wrote:

> Or replace Phoenix, Arizona with any other civil jurisdiction that  
> is free of DST and adjust the time zone offset accordingly.

If you're looking for an Arizona-based standard, surely Sedona is the  
benchmark :-)

	http://www.lovesedona.com/01.htm

Regarding Arizona, the Navajo Nation in the NE corner does observe  
DST.  The Hopis, completely surrounded by the Navajos, do not observe  
DST:

	http://www.timegenie.com/_images/arizona-timezone-map.gif

Hawaii is the only state that does not observe DST at all.  Kilauea is  
busily manufacturing new territory free of the hegemony of this  
blighted concept :-)

It is also remarkable that about one-fourth (12) of the U.S. states  
are bisected by timezones:

	http://www.miketodd.net/encyc/dst.htm

But since just over half the states don't adjoin a timezone boundary  
with another state (I count 27), the statistics are actually more  
remarkable - more than half of U.S. states near a timezone boundary  
have chosen the awkward route of splitting their timekeeping needs.   
(Statistics regarding national boundaries and provinces in other  
countries would be interesting to compare.)

I would take this as evidence that people actually care about solar  
time.  Others might see this as proof of how flexible people are in  
their conception of time.  Really it argues that half the state  
boundaries were put in the wrong places :-)

Rob


From zefram at fysh.org  Mon Jan  5 05:24:53 2009
From: zefram at fysh.org (Zefram)
Date: Mon, 5 Jan 2009 10:24:53 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090104.191536.179953595.imp@bsdimp.com>
References: <4960C988.6090005@erols.com> <49613050.6030503@rubidium.dyndns.org>
	<496157C4.2050300@erols.com>
	<20090104.191536.179953595.imp@bsdimp.com>
Message-ID: <20090105102452.GJ14473@fysh.org>

M. Warner Losh wrote:
>So time_t is effectively defined in POSIX to be:
>
>	d * 86400 + min(tod(x), 86399)
>
>where d is the number of days since 01-01-1970, and tod is the second
>since midnight within the day.

Actually it's simpler than that.  The expression given by POSIX amounts to

	d * 86400 + tod(x)

so a leap second appears identical to the first second of the next day,
rather than a repeat of the previous second.  What's actually implemented
by particular kernels varies; Linux, for example, does something in
between these, jumping backwards (by 1) a few milliseconds after the
start of the leap second.

-zefram

From magnus at rubidium.dyndns.org  Mon Jan  5 05:45:57 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 11:45:57 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105102452.GJ14473@fysh.org>
References: <4960C988.6090005@erols.com>
	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>
	<20090105102452.GJ14473@fysh.org>
Message-ID: <4961E4E5.8010908@rubidium.dyndns.org>

Zefram skrev:
> M. Warner Losh wrote:
>> So time_t is effectively defined in POSIX to be:
>>
>> 	d * 86400 + min(tod(x), 86399)
>>
>> where d is the number of days since 01-01-1970, and tod is the second
>> since midnight within the day.
> 
> Actually it's simpler than that.  The expression given by POSIX amounts to
> 
> 	d * 86400 + tod(x)
> 
> so a leap second appears identical to the first second of the next day,
> rather than a repeat of the previous second.  What's actually implemented
> by particular kernels varies; Linux, for example, does something in
> between these, jumping backwards (by 1) a few milliseconds after the
> start of the leap second.

Actually, this is just implementing the POSIX UTC to time_t mapping.

2008-12-31T23:59:60Z and 2009-01-01T00:00:00Z maps to the same POSIX 
time_t second so by reversing the stepping of second just done at the 
beginning of the leap second implements this.

The NTP time follows the same jump fashion, but with a different offset.

The figure at the bottom of
http://www.cis.udel.edu/~mills/leap.html
shows graphically what is going on and the table give the same in 
numbers. A POSIX time_t column could be added, but it would just be a 
static offset from the NTP seconds.

A simplified model of the POSIX time_t would be

time_t = d*86400 + h*3600 + m*60 + s

which helps to have written out when comparing the two cases.

Cheers,
Magnus

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

From zefram at fysh.org  Mon Jan  5 05:52:57 2009
From: zefram at fysh.org (Zefram)
Date: Mon, 5 Jan 2009 10:52:57 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
Message-ID: <20090105105257.GK14473@fysh.org>

Rob Seaman wrote:
>Coordinate leap seconds with leap days.  Introduce an integral number  
>of leap seconds each February 29th.  Discuss.

That would mean bigger leaps.  I think a 62-second minute (when most
minutes are of 60 seconds) is too great a disuniformity.  It would also
exceed the capacity of current leap second implementations, which know
that there can only be one leap second at a time.

The lower frequency of leaps would necessarily mean bigger excursions
of DUT1.  That's not a fatal problem, but you don't seem to be buying
much win with this much looser tracking.  There's also a risk that the
lower frequency of leaps would exacerbate the psychology of leap seconds
being an infrequent event.

February 29 isn't the only option for the leap day.  Traditionally the
leap day was February 24, though you can't have that one because leap
seconds are constrained to occur at the end of a month.  A more obvious
choice is December 31: the 366th day of the year, when most years only
go up to 365.

-zefram

From dot at dotat.at  Mon Jan  5 07:18:54 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 12:18:54 +0000
Subject: [LEAPSECS] the leap second in the media
In-Reply-To: <4961A66A.3000808@rubidium.dyndns.org>
References: <alpine.LSU.2.00.0901010602100.2395@hermes-1.csi.cam.ac.uk>
	<20090105060634.GE29687@multics.mit.edu>
	<4961A66A.3000808@rubidium.dyndns.org>
Message-ID: <alpine.LSU.2.00.0901051215190.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Magnus Danielson wrote:
>
> You could of course to some degree steer the clock on a machine by
> changing the computing load on it, as the tempco of most systems crystal
> is pretty bad. It would kinda work except when it is out of controlrange.

Alternatively you can use clock skew to infer computing load:

http://www.cl.cam.ac.uk/~sjm217/papers/#pub-ccs06hotornot

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOLE: VARIABLE 4 BECOMING EASTERLY 5 OR 6. MODERATE OR ROUGH. OCCASIONAL RAIN,
THEN FAIR. MODERATE OR GOOD, OCCASIONALLY POOR.

From seaman at noao.edu  Mon Jan  5 08:57:37 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 06:57:37 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <4961E4E5.8010908@rubidium.dyndns.org>
References: <4960C988.6090005@erols.com>
	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>
	<20090105102452.GJ14473@fysh.org>
	<4961E4E5.8010908@rubidium.dyndns.org>
Message-ID: <61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>

Magnus Danielson wrote:

> time_t = d*86400 + h*3600 + m*60 + s

Just thought I'd note an alternate interpretation.  In NOAO's widely  
distributed image processing system (IRAF) a sexagesimal number is a  
double precision floating point number, not an integer:

	12:34:56 = 12 + 34/60 + 56.0/3600

Wherever a float can appear, a sexagesimal string is permitted.  Our  
version of printf includes %h and %H for turning a binary float back  
into dd:mm:ss.s or hh:mm:ss.s.

A particular application may need to count integer seconds (as in our  
own date and time library, perhaps), but the need is remarkably  
infrequent.  For the vast majority of cases sexagesimal numbers behave  
like floats.

Rob Seaman
National Optical Astronomy Observatory

From jhardis at tcs.wap.org  Mon Jan  5 09:03:28 2009
From: jhardis at tcs.wap.org (Jonathan E. Hardis)
Date: Mon, 5 Jan 2009 09:03:28 -0500
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
References: <0901050622.AA00754@ivan.Harhan.ORG>
	<F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
Message-ID: <p06230903c587bf762ae5@[192.168.0.5]>

>It is also remarkable that about one-fourth (12) of the U.S. states 
>are bisected by timezones

14 states:

Alaska, Idaho, Oregon, Nevada, North Dakota, South Dakota, Nebraska, 
Kansas, Texas, Michigan, Indiana, Kentucky, Tennessee, and Florida

>I would take this as evidence that people actually care about solar time.

Of course they do ... at a tolerance of +/- 30 minutes.  You can't 
use this as an argument that people care about solar time at a 
tolerance of seconds.  Indeed, whenever the weather lady on the 
evening news tells me the times for sunrise and sunset, it is only to 
a resolution of 1 minute, and not corrected for different portions of 
the viewing area.

Time zones were established, and are maintained, for the convenience 
of commerce.  Your time zone has a lot to do with the nearest big 
city with which your community trades.

    - Jonathan

From magnus at rubidium.dyndns.org  Mon Jan  5 09:11:00 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Mon, 05 Jan 2009 15:11:00 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>
References: <4960C988.6090005@erols.com>	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>	<20090105102452.GJ14473@fysh.org>	<4961E4E5.8010908@rubidium.dyndns.org>
	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>
Message-ID: <496214F4.1090304@rubidium.dyndns.org>

Rob,

Rob Seaman skrev:
> Magnus Danielson wrote:
> 
>> time_t = d*86400 + h*3600 + m*60 + s
> 
> Just thought I'd note an alternate interpretation.  In NOAO's widely 
> distributed image processing system (IRAF) a sexagesimal number is a 
> double precision floating point number, not an integer:
> 
>     12:34:56 = 12 + 34/60 + 56.0/3600
> 
> Wherever a float can appear, a sexagesimal string is permitted.  Our 
> version of printf includes %h and %H for turning a binary float back 
> into dd:mm:ss.s or hh:mm:ss.s.
> 
> A particular application may need to count integer seconds (as in our 
> own date and time library, perhaps), but the need is remarkably 
> infrequent.  For the vast majority of cases sexagesimal numbers behave 
> like floats.

Hate to nitpick you, but that is a different representation, not a 
different interpretation.

The floating point number is thus in hours, is that more practical than 
say days?

Cheers,
Magnus

From adi at stav.org.il  Mon Jan  5 09:32:27 2009
From: adi at stav.org.il (Adi Stav)
Date: Mon, 5 Jan 2009 16:32:27 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
Message-ID: <20090105143227.GG6161@stav.org.il>

On Sun, Jan 04, 2009 at 08:58:29PM -0700, Rob Seaman wrote:
> Adi Stav wrote:
>
>> Then why 4 seconds? Because they could be predicted a decade in  
>> advance?  Isn't that putting the cart before the horses?
>
> Yes, indeed.  You asked a question.  I provided a guess.  Personally, I 
> think the current standard is better than allowing celestial coordinates 
> to slosh around by an arcminute, but it is not the astronomers here who 
> have refused to dicker.
>
>> If I reckon correctly, people on this list specified 20 or 60 minutes 
>> as their guesses for the limit
>
> Some people said such things.  Why lend them greater weight than  
> alternate opinions?

They don't have greater weight, but they have their own direct
justifications and so can be discussed by both those who agree and
disagree.

We know that human tolerance to DUT is higher than 20 minutes because we
don't usually bother to compensate for apparent solar time. We know that 
it is probably not much higher than one or two hours because time zones 
generally have about that resolution. We guess that it is might be about 
one hour because many areas in the world choose time zones that are about
one-hour offsets from their local mean time.

These justifications are not necessarily valid, or maybe there are other
or better justifications for smaller DUT maxima. I am just trying to
find out (for myself) what these are. This is why I asked.

> Nobody has specified anything.  Specifications relate to solution space.  
> We have yet to discover the requirements describing the problem space.  
> There is nothing to specify against.

True. I should have said instead "suggested", or "said".

>> Clearly, you think DUT should be smaller. Why? For practical reasons  
>> of astronomy? For other reasons?
>
> Yes and yes.  A static geographic offset is different from introducing a 
> permanent bias in the rate.  A zero-mean periodic variation as in the 
> equation of time is different from a permanent bias.  Seasonal step 
> function jumps are different yet again.
>
> Embargoing leap seconds (or their equivalent) for periods of decades or 
> centuries is the same as not making intercalary adjustments at all.

Why is that? Even the Gregorian reform does not come into effect except
every one or two centuries. Yet it is followed exactly.

> It 
> will introduce a tilted quadratic bias in the solar rate.  The issue 
> isn't about offsets at all, it is about preserving the correct functional 
> form of civil timekeeping.

(I hope) I fully understand this requirement. So I asked about the
maximal DUT instead.

> We have heard numerous times that the Gregorian calendar is acceptable  
> because the schedule is predictable.  

I can think of properties that make the Gregorian calendar acceptable 
and that not every UTC reform will necessarily have:

 * It does not introduce a new intercalary mechanism, and instead
   modifies (slightly) the frequency of a pre-existing and accepted one.
 * It is not only infinitely predictable, but also easy; every
   schoolchild can know it.

> But why is the Gregorian calendar 
> desirable?
>
> It is desirable because it stabilizes the civil calendar against the  
> natural annual rhythms of life on Earth AND because it does so at a fine 
> enough resolution to permit smoothing across the decades and centuries.  
> When considering dates 400 years from now - or in colonial America - we 
> don't have to wonder whether April occurs before or after the Vernal 
> Equinox.

This is a property going back to the Julian calendar. But I see your
meaning -- you are saying that one second is acceptable simply because 
it uses *our smallest standard* time unit (and four seconds likewise,
with a decade of advanced warning).

By the way, it can be argued that the smoothness property is not strictly 
necessary for calendars. Consider popular and long-used artihmetic 
lunisolar calendars, such as the Hebrew, Hindu, and Chinese calendars, 
that intercalate their years to a resolution of a month.

From phk at phk.freebsd.dk  Mon Jan  5 09:47:03 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 05 Jan 2009 14:47:03 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: Your message of "Mon, 05 Jan 2009 06:57:37 MST."
	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu> 
Message-ID: <85270.1231166823@critter.freebsd.dk>

In message <61D527C3-DE55-42A8-98A4-0C69BC3C3E93 at noao.edu>, Rob Seaman writes:
>Magnus Danielson wrote:

>In NOAO's widely  
>distributed image processing system (IRAF) a sexagesimal number is a  
>double precision floating point number, not an integer:

Yeah, the "struct timeval/timespec" mess of ISO-C/POSIX is seriously
barfable from a performance point of view.

The proper thing for the future is either a "int128_t" 64.64
fixedpoint time representation or a double ditto.

Fixed point holds some advantages on tiney embedded systems.

-- 
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 Jan  5 10:11:29 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 08:11:29 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105102452.GJ14473@fysh.org>
References: <496157C4.2050300@erols.com>
	<20090104.191536.179953595.imp@bsdimp.com>
	<20090105102452.GJ14473@fysh.org>
Message-ID: <20090105.081129.1586007667.imp@bsdimp.com>

In message: <20090105102452.GJ14473 at fysh.org>
            Zefram <zefram at fysh.org> writes:
: M. Warner Losh wrote:
: >So time_t is effectively defined in POSIX to be:
: >
: >	d * 86400 + min(tod(x), 86399)
: >
: >where d is the number of days since 01-01-1970, and tod is the second
: >since midnight within the day.
: 
: Actually it's simpler than that.  The expression given by POSIX amounts to
: 
: 	d * 86400 + tod(x)
: 
: so a leap second appears identical to the first second of the next day,
: rather than a repeat of the previous second.

That's what the broken down time translation results in.  However, I
don't think that POSIX specifies the 'proper' value for the leap
second because leap seconds are explicitly excluded from the spec.
The reason it maps to the above is due to the normalization rules for
the '60' part of the broken down time, not because it is a leap second
and is defined to map there.

: What's actually implemented
: by particular kernels varies; Linux, for example, does something in
: between these, jumping backwards (by 1) a few milliseconds after the
: start of the leap second.

FreeBSD too.  Any NTP based kernel does this.

Warner

From imp at bsdimp.com  Mon Jan  5 10:20:08 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 08:20:08 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <496214F4.1090304@rubidium.dyndns.org>
References: <4961E4E5.8010908@rubidium.dyndns.org>
	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>
	<496214F4.1090304@rubidium.dyndns.org>
Message-ID: <20090105.082008.776520750.imp@bsdimp.com>

In message: <496214F4.1090304 at rubidium.dyndns.org>
            Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: Rob,
: 
: Rob Seaman skrev:
: > Magnus Danielson wrote:
: > 
: >> time_t = d*86400 + h*3600 + m*60 + s
: > 
: > Just thought I'd note an alternate interpretation.  In NOAO's widely 
: > distributed image processing system (IRAF) a sexagesimal number is a 
: > double precision floating point number, not an integer:
: > 
: >     12:34:56 = 12 + 34/60 + 56.0/3600
: > 
: > Wherever a float can appear, a sexagesimal string is permitted.  Our 
: > version of printf includes %h and %H for turning a binary float back 
: > into dd:mm:ss.s or hh:mm:ss.s.
: > 
: > A particular application may need to count integer seconds (as in our 
: > own date and time library, perhaps), but the need is remarkably 
: > infrequent.  For the vast majority of cases sexagesimal numbers behave 
: > like floats.
: 
: Hate to nitpick you, but that is a different representation, not a 
: different interpretation.
: 
: The floating point number is thus in hours, is that more practical than 
: say days?

And how are leap seconds represented in this convention?

Warner

From imp at bsdimp.com  Mon Jan  5 10:19:45 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 08:19:45 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <p06230903c587bf762ae5@[192.168.0.5]>
References: <0901050622.AA00754@ivan.Harhan.ORG>
	<F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
	<p06230903c587bf762ae5@[192.168.0.5]>
Message-ID: <20090105.081945.1791037496.imp@bsdimp.com>

In message: <p06230903c587bf762ae5@[192.168.0.5]>
            "Jonathan E. Hardis" <jhardis at tcs.wap.org> writes:
: >It is also remarkable that about one-fourth (12) of the U.S. states 
: >are bisected by timezones
: 
: 14 states:
: 
: Alaska, Idaho, Oregon, Nevada, North Dakota, South Dakota, Nebraska, 
: Kansas, Texas, Michigan, Indiana, Kentucky, Tennessee, and Florida

In the case of Kansas, it is really only the extreme western counties
in a very thinly populated area where the timezone cut.  I thought
there was also a tiny portion of Colorado in the Central Time Zone
too, but a quick google says no.

The reason that time zone boundaries are so crazy is that they were
trying to keep groups of people that interact often on the same time
zone.  Otherwise we'd have nice, straight lines.

: >I would take this as evidence that people actually care about solar time.
: 
: Of course they do ... at a tolerance of +/- 30 minutes.  You can't 
: use this as an argument that people care about solar time at a 
: tolerance of seconds.  Indeed, whenever the weather lady on the 
: evening news tells me the times for sunrise and sunset, it is only to 
: a resolution of 1 minute, and not corrected for different portions of 
: the viewing area.
: 
: Time zones were established, and are maintained, for the convenience 
: of commerce.  Your time zone has a lot to do with the nearest big 
: city with which your community trades.

Time zones were the first step away from a local apparent solar time,
which had been used prior to that (more or less) to having larger
areas agree on what time it is.  If anything, I take it as evidence
that people care less about solar time now than they used to because
the variance in the local solar time to standard time varies much
more than it did prior to this shift.

Warner

From dot at dotat.at  Mon Jan  5 11:06:18 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 16:06:18 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <85270.1231166823@critter.freebsd.dk>
References: <85270.1231166823@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.0901051603040.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Poul-Henning Kamp wrote:
>
> The proper thing for the future is either a "int128_t" 64.64
> fixedpoint time representation or a double ditto.

Do you mean double as in the C type? Which is surely too small - you want
quad-precision FP or perhaps "double double" (paired doubles to get 112
bits of mantissa).

Or do you mean 256 bits of precision, in which case, boggle!

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: NORTHEAST 5 TO 7, OCCASIONALLY
GALE 8 EXCEPT IN HUMBER AND PLYMOUTH, DECREASING 4 AT TIMES LATER. MODERATE,
OCCASIONALLY ROUGH. WINTRY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From seaman at noao.edu  Mon Jan  5 11:09:37 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 09:09:37 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <496214F4.1090304@rubidium.dyndns.org>
References: <4960C988.6090005@erols.com>	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>	<20090105102452.GJ14473@fysh.org>	<4961E4E5.8010908@rubidium.dyndns.org>
	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>
	<496214F4.1090304@rubidium.dyndns.org>
Message-ID: <3951D01D-BCC5-4658-8422-E6AC126654D3@noao.edu>

Magnus Danielson wrote:

> Hate to nitpick you, but that is a different representation, not a  
> different interpretation.

Even in technical documentation, words retain their broader meanings.   
I was suggesting that instead of interpreting sexagesimal values as  
sets of integers, one can interpret them as single real values  
(whether fixed or floating point).  One also often interprets  
sexagesimal values as strings.  This may also be a question of  
representation.  And representation is generally an issue for the  
programmer.  Interpretation, an issue for the user.

> The floating point number is thus in hours, is that more practical  
> than say days?

Yes.  A civil clock expresses an angle in h:m:s.  Sexagesimal strings  
broadly represent (or are interpreted as) angles, e.g., latitude,  
longitude, declination, right ascension, galactic latitude and  
longitude, ecliptic latitude and longitude, great circle distances on  
the Earth or the celestial sphere, altitude/elevation and azimuth.   
Whether h:m:s or d:m:s (or decimal representations of hours or degrees  
or radians) these are angles all.

Hence the intuitive conversion between sidereal time and the "hour  
angle" of a telescope.

Rob


From phk at phk.freebsd.dk  Mon Jan  5 11:15:00 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 05 Jan 2009 16:15:00 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: Your message of "Mon, 05 Jan 2009 16:06:18 GMT."
	<alpine.LSU.2.00.0901051603040.10002@hermes-1.csi.cam.ac.uk> 
Message-ID: <85625.1231172100@critter.freebsd.dk>

In message <alpine.LSU.2.00.0901051603040.10002 at hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
>On Mon, 5 Jan 2009, Poul-Henning Kamp wrote:
>>
>> The proper thing for the future is either a "int128_t" 64.64
>> fixedpoint time representation or a double ditto.
>
>Do you mean double as in the C type? Which is surely too small - you want
>quad-precision FP or perhaps "double double" (paired doubles to get 112
>bits of mantissa).

True, it would probably have to be a "long double" of at least 80 bits.

-- 
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 Jan  5 11:14:37 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 09:14:37 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <alpine.LSU.2.00.0901051603040.10002@hermes-1.csi.cam.ac.uk>
References: <85270.1231166823@critter.freebsd.dk>
	<alpine.LSU.2.00.0901051603040.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <20090105.091437.139558891.imp@bsdimp.com>

In message: <alpine.LSU.2.00.0901051603040.10002 at hermes-1.csi.cam.ac.uk>
            Tony Finch <dot at dotat.at> writes:
: On Mon, 5 Jan 2009, Poul-Henning Kamp wrote:
: >
: > The proper thing for the future is either a "int128_t" 64.64
: > fixedpoint time representation or a double ditto.
: 
: Do you mean double as in the C type? Which is surely too small - you want
: quad-precision FP or perhaps "double double" (paired doubles to get 112
: bits of mantissa).
: 
: Or do you mean 256 bits of precision, in which case, boggle!

I think he means int128_t, for those systems that implement it.  A 128
bit integer that's interpreted by the time routines as a fixed point
number.  64 bits of second offset, and 64-bits of within the second
offset.

Warner

From seaman at noao.edu  Mon Jan  5 11:19:08 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 09:19:08 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105105257.GK14473@fysh.org>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105105257.GK14473@fysh.org>
Message-ID: <421FB837-F23F-4A16-B6F4-F26D1C58C6FA@noao.edu>

  Zefram wrote:

> Rob Seaman wrote:
>
>> Coordinate leap seconds with leap days.  Introduce an integral  
>> number of leap seconds each February 29th.  Discuss.
>
> There's also a risk that the lower frequency of leaps would  
> exacerbate the psychology of leap seconds being an infrequent event.

Countered, perhaps, by the much longer familiarity civilians have with  
leap days.

> February 29 isn't the only option for the leap day.  [...]  A more  
> obvious choice is December 31: the 366th day of the year, when most  
> years only go up to 365.

It seems very unlikely that leap day will move from February.  People  
are fond of February.  Also, a leap day at the end of December would  
be December 32nd :-)

Rob


From zefram at fysh.org  Mon Jan  5 11:27:35 2009
From: zefram at fysh.org (Zefram)
Date: Mon, 5 Jan 2009 16:27:35 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <421FB837-F23F-4A16-B6F4-F26D1C58C6FA@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105105257.GK14473@fysh.org>
	<421FB837-F23F-4A16-B6F4-F26D1C58C6FA@noao.edu>
Message-ID: <20090105162735.GM14473@fysh.org>

Rob Seaman wrote:
>Also, a leap day at the end of December would  
>be December 32nd :-)

Only if there were no February 29.  My point is that the leap day appears
to be at the end of the year if you don't bother with months and just
use day-of-year.  Just as the idea that February 29 is the leap day
originates in looking at the ordinal day-of-month.  Traditionally the
leap day was "ante diem bis VI Kalendas Martias", located some days
before the end of the month.

-zefram

From seaman at noao.edu  Mon Jan  5 11:39:28 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 09:39:28 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105143227.GG6161@stav.org.il>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
Message-ID: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>

Adi Stav wrote:

> We know that human tolerance to DUT is higher than 20 minutes  
> because we
> don't usually bother to compensate for apparent solar time. We know  
> that
> it is probably not much higher than one or two hours because time  
> zones
> generally have about that resolution. We guess that it is might be  
> about
> one hour because many areas in the world choose time zones that are  
> about
> one-hour offsets from their local mean time.
>
> These justifications are not necessarily valid, or maybe there are  
> other
> or better justifications for smaller DUT maxima. I am just trying to
> find out (for myself) what these are. This is why I asked.

Ok (to the second paragraph :-)

Lower limits are hard to pin down.  Human tolerance on a particular  
day is not the same thing as the tolerance over a year or a lifetime.   
Straining a tolerance for one human is not the same as straining it  
for 6 billion.  Human tolerances in general need to be interpreted in  
terms of our infrastructure, not just personal perception as we walk  
from parking lot to office.

The upper limit has been specified as a "statement against penal  
interest" by the ITU.  Public enemy  number one of leap seconds says  
an hour is the upper limit :-)

>> Embargoing leap seconds (or their equivalent) for periods of  
>> decades or
>> centuries is the same as not making intercalary adjustments at all.
>
> Why is that? Even the Gregorian reform does not come into effect  
> except
> every one or two centuries. Yet it is followed exactly.

Gregory revised the Julian calendar.  The fundamental standard remains  
rooted in what the ancients discovered.  The proper comparison is to  
the every four year scheduling of leap day opportunities - sometimes  
those opportunities remain nulled out, but they still exist.

The seasonal or diurnal trends in the calendar or clock need to be  
sampled frequently enough to avoid significant quantization errors.   
Leap seconds are productive from this point of view precisely because  
civilians can ignore them.

> By the way, it can be argued that the smoothness property is not  
> strictly
> necessary for calendars. Consider popular and long-used artihmetic
> lunisolar calendars, such as the Hebrew, Hindu, and Chinese calendars,
> that intercalate their years to a resolution of a month.

A very interesting observation.  What calendars does the world really  
depend on for various purposes?  That is, what is the market  
penetration of the Gregorian/Julian calendar?  I would guess nearly  
100% in Europe and North America.  What about the rest of the world?

Rob

From phk at phk.freebsd.dk  Mon Jan  5 11:44:45 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 05 Jan 2009 16:44:45 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: Your message of "Mon, 05 Jan 2009 09:19:08 MST."
	<421FB837-F23F-4A16-B6F4-F26D1C58C6FA@noao.edu> 
Message-ID: <85819.1231173885@critter.freebsd.dk>

In message <421FB837-F23F-4A16-B6F4-F26D1C58C6FA at noao.edu>, Rob Seaman writes:

>It seems very unlikely that leap day will move from February.  People  
>are fond of February.  Also, a leap day at the end of December would  
>be December 32nd :-)

Which would break incredibly badly thought out filsystem formats
like FAT which encodes the day-of-month in five bits.

-- 
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 Jan  5 11:44:52 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 09:44:52 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105.081945.1791037496.imp@bsdimp.com>
References: <0901050622.AA00754@ivan.Harhan.ORG>
	<F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
	<p06230903c587bf762ae5@[192.168.0.5]>
	<20090105.081945.1791037496.imp@bsdimp.com>
Message-ID: <27612000-5CCF-495B-9A00-0AB7DEA7F81E@noao.edu>

M. Warner Losh wrote:

> The reason that time zone boundaries are so crazy is that they were
> trying to keep groups of people that interact often on the same time
> zone.  Otherwise we'd have nice, straight lines.
>
> [...]
>
> Time zones were the first step away from a local apparent solar time,
> which had been used prior to that (more or less) to having larger
> areas agree on what time it is.  If anything, I take it as evidence
> that people care less about solar time now than they used to because
> the variance in the local solar time to standard time varies much
> more than it did prior to this shift.

Like I said, I interpret it as support for solar-based civil  
timekeeping.  Others interpret it as evidence of the opposite  
position, and the reality is that the state boundaries are simply in  
the wrong place :-)

Rob


From dot at dotat.at  Mon Jan  5 11:47:41 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 16:47:41 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
References: <0901050622.AA00754@ivan.Harhan.ORG>
	<F78068E2-FAC0-48CE-8E83-2792D8D79BA4@noao.edu>
Message-ID: <alpine.LSU.2.00.0901051616390.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Rob Seaman wrote:
>
> But since just over half the states don't adjoin a timezone boundary with
> another state (I count 27), the statistics are actually more remarkable - more
> than half of U.S. states near a timezone boundary have chosen the awkward
> route of splitting their timekeeping needs.

The reason for this is that it's LESS awkward to keep the same time as the
nearest major city than for time zone boundaries to follow state
boundaries.

> I would take this as evidence that people actually care about solar time.

DST became popular and continues to be popular because people like to
start their day soon after sunrise. DST is the only effective way of
getting everyone to make seasonal adjustments to their timetables so that
it is convenient to get up earlier in the summer.

The locations of timezone boundaries (and their tendency to drift
westwards) and the existence of DST are examples of how social
requirements override the scientific principles of time.

DST has nothing to do with solar time as defined by astronomers. If
anything it is a rebellion against astronomers' noon-based time.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SHANNON: CYCLONIC 4 OR 5, BECOMING SOUTHEASTERLY 3 OR 4. ROUGH. SHOWERS.
MODERATE OR GOOD.

From seaman at noao.edu  Mon Jan  5 12:23:49 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 10:23:49 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105.082008.776520750.imp@bsdimp.com>
References: <4961E4E5.8010908@rubidium.dyndns.org>
	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>
	<496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
Message-ID: <EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>

M. Warner Losh wrote:

> And how are leap seconds represented in this convention?

They aren't.  The choice of the underlying time or angular scale is an  
orthogonal issue.

Begin aside:

To comment further, the apparent separate fields of sexagesimal  
fractions are not generally not constrained, e.g.:

	cl> = 12:34:56
	12.582222222222
	cl> = -12:34:56
	-12.582222222222
	cl> = 12:34:56.789
	12.582441388889
	cl> = 123:456:789
	130.81916666667

("cl>" is the command language prompt.)

It will throw a syntax error if the hours/degrees or minutes field is  
not an integer, or if the minutes or seconds fields are negative.   
Other than that, minutes or seconds can overflow to your heart's  
content.  (Just like my microwave at home.)

For example:

	cl> = 12:34:59
	12.583055555556
	cl> = 12:34:60
	12.583333333333
	cl> = 12:35:00
	12.583333333333

Is this correct for a leap second?  Rather, it isn't representing a  
leap second at all.  The point of leap seconds is to jump outside the  
angular paradigm and correct an alignment issue at a fine enough  
resolution to be ignored for most purposes.

If some application needs to know about leap seconds, the data type of  
some parameter would be left as a string rather than a real and the  
application (or system function) would juggle the characters directly.

Common sense constraints are applied through the general purpose  
formatting library, e.g.:

	cl> printf ("%h\n", 12:34:60)
	12:35:00.0
	cl> printf ("%h\n", 12:59:60)
	13:00:00.0

Again, if there is some need to represent a leap second within the VOS  
or application, this would be tailored to the purpose.  Also, limits  
on the number of hours or degrees are not implicit in the  
representation, but explicit in the application.  Angles are sometime  
constrained to fall within 0:00:00 to 359:59:59.999, but also  
sometimes from -90:00:00 to +90:00:00, similarly with hours being  
packed into days.

Of course, the point of this is to permit arithmetic that treats each  
angle as a single value, rather than an awkward triple of integers (or  
two integers and a real):

	cl> printf ("%h\n", 12:34:59 - 01:23:45)
	11:11:14.0

One could imagine extending this to ISO-8601 date/time pairs, but it  
has never become a priority.  I have some purpose-built functions for  
my applications that need to handle ISO strings.  The date/time  
primitives in the VOS pass two separate values in typical field  
arrangements.  (The pair is atomic, of course.)

Loosely constrain input.  Explicitly constrain output.

End aside.

Rob

From imp at bsdimp.com  Mon Jan  5 12:54:34 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 10:54:34 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
References: <496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
	<EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
Message-ID: <20090105.105434.547436998.imp@bsdimp.com>

In message: <EE24F7F1-DEA0-4867-BD8A-89EDEC929C47 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: M. Warner Losh wrote:
: 
: > And how are leap seconds represented in this convention?
: 
: They aren't.  The choice of the underlying time or angular scale is an  
: orthogonal issue.

So leap seconds are hard, eh?

Warner

From seaman at noao.edu  Mon Jan  5 13:16:39 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 11:16:39 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105.105434.547436998.imp@bsdimp.com>
References: <496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
	<EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
	<20090105.105434.547436998.imp@bsdimp.com>
Message-ID: <5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>

M. Warner Losh wrote:

> So leap seconds are hard, eh?

You know, it isn't as if we haven't been talking about this stuff for  
nine years.  We all know where the bodies are buried.  Leap seconds  
can be a bit awkward.  Not having them is also awkward.  But for most  
purposes, a more frequent update schedule keeps individual updates (of  
whatever sort) below a threshold for causing pain.  Like I said, the  
point of a leap second is to be ignored.

The recent leap second passed (yet again) with no major issues.  That  
being the case, one could use this fact to argue that we're spending a  
lot of effort on a non-issue.  Rather, I'm happy to continue working  
toward a resolution satisfactory to all.  Simply ignoring the issue  
for a thousand years is not satisfactory.

Not to mention that hard problems are the fun ones :-)

However, I tendered the description of a floating point representation  
of sexagesimal values for reasons orthogonal to leap seconds.

Rob


From dot at dotat.at  Mon Jan  5 13:34:22 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 18:34:22 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
References: <496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
	<EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
	<20090105.105434.547436998.imp@bsdimp.com>
	<5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
Message-ID: <alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Rob Seaman wrote:
>
> The recent leap second passed (yet again) with no major issues.

Wrong.

Loads of Oracle RAC servers crashed because of a bug triggered by the
clock going backwards.

http://www.merit.edu/mail.archives/nanog/msg13857.html

Many time dissemination systems got it wrong, as usual.

I wonder why OS vendors don't ship ntpd preconfigured with a leapseconds
table that is updated as part of the OS's normal patching process. I hope
that would reduce the amount of manual maintenance required for stratum 1
servers and increase the reliability of NTP's leap second handling.

Obviously leap seconds are so important that we can't do without them,
but so unimportant that it doesn't matter that we can't get them to
work properly.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FORTIES CROMARTY FORTH: SOUTHWEST 4 OR 5, INCREASING 6 OR 7, PERHAPS GALE 8
LATER IN FORTIES, VEERING NORTHWEST LATER. MODERATE, OCCASIONALLY ROUGH LATER
IN FORTIES. RAIN LATER. MODERATE OR GOOD.

From msokolov at ivan.Harhan.ORG  Mon Jan  5 13:35:49 2009
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 5 Jan 2009 18:35:49 GMT
Subject: [LEAPSECS] [time-nuts] Leap Quirks
Message-ID: <0901051835.AA01796@ivan.Harhan.ORG>

Rob Seaman <seaman at noao.edu> wrote:

> If you're looking for an Arizona-based standard, surely Sedona is the  
> benchmark :-)
>
> http://www.lovesedona.com/01.htm

Yup, been there once for a UFO/spiritual conference.  Very beautiful
indeed.

MS

From imp at bsdimp.com  Mon Jan  5 13:50:13 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 11:50:13 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
References: <20090105.105434.547436998.imp@bsdimp.com>
	<5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
	<alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <20090105.115013.387220651.imp@bsdimp.com>

In message: <alpine.LSU.2.00.0901051819010.10002 at hermes-1.csi.cam.ac.uk>
            Tony Finch <dot at dotat.at> writes:
: On Mon, 5 Jan 2009, Rob Seaman wrote:
: >
: > The recent leap second passed (yet again) with no major issues.
: 
: Wrong.
: 
: Loads of Oracle RAC servers crashed because of a bug triggered by the
: clock going backwards.
: 
: http://www.merit.edu/mail.archives/nanog/msg13857.html
: 
: Many time dissemination systems got it wrong, as usual.

Add to that the whole Linux kernel hang problem that some users
experienced because there was a printf that was called with locks
held...  Usually it worked, but for a small percentage of users it
hung...

: I wonder why OS vendors don't ship ntpd preconfigured with a leapseconds
: table that is updated as part of the OS's normal patching process. I hope
: that would reduce the amount of manual maintenance required for stratum 1
: servers and increase the reliability of NTP's leap second handling.
 
Does ntpd actually use the leap seconds table in preference to what
remote systems are telling it?  I recall years ago trying to configure
things and not being able to make this work reliably...

: Obviously leap seconds are so important that we can't do without them,
: but so unimportant that it doesn't matter that we can't get them to
: work properly.

<nod>

Warner

From seaman at noao.edu  Mon Jan  5 14:06:41 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 12:06:41 -0700
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
References: <496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
	<EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
	<20090105.105434.547436998.imp@bsdimp.com>
	<5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
	<alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <51302552-875A-4E99-937C-BDBA26AE0BBD@noao.edu>

Tony Finch wrote:

> On Mon, 5 Jan 2009, Rob Seaman wrote:
>>
>> The recent leap second passed (yet again) with no major issues.
>
> Wrong.
>
> Loads of Oracle RAC servers crashed because of a bug triggered by the
> clock going backwards.
>
> http://www.merit.edu/mail.archives/nanog/msg13857.html

Where the statement is:

	"I had a couple of Oracle servers (Solaris 10) reboot a couple of  
minutes just before the leap second. All my other Solaris 10 boxes  
appear to have stayed up fine."

The phrasing doesn't even make it clear that this was causally  
connected to the leap second.  I assume that later messages in the  
thread clarify this.

It might help to standardize a definition of "major issue".  Our group  
uses JIRA to track issues.  We have two levels above major issue,  
namely "critical" and "blocker".  Leap seconds are clearly not a  
blocker, since we have moved past this one just like the previous  
ones.  Given that the current standard is viable for hundreds of  
years, it is also hard to rate them as critical.

> Many time dissemination systems got it wrong, as usual.
>
> I wonder why OS vendors don't ship ntpd preconfigured with a  
> leapseconds
> table that is updated as part of the OS's normal patching process. I  
> hope
> that would reduce the amount of manual maintenance required for  
> stratum 1
> servers and increase the reliability of NTP's leap second handling.

Sound like good ideas.  Fix the bug.  Improve the processes.

> Obviously leap seconds are so important that we can't do without them,
> but so unimportant that it doesn't matter that we can't get them to
> work properly.

Stabilizing civil time with respect to the slowly evolving diurnal  
rate is important.  You say so yourself:

	http://catless.ncl.ac.uk/Risks/25.50.html#subj1

If leap seconds are truly failing to satisfy a requirement for  
ignorability, we have mentioned many different possibilities over the  
years for stabilizing civil timekeeping.

The ITU proposal to simply ignore the whole thing for a thousand years  
is not one of these.

Rob


From imp at bsdimp.com  Mon Jan  5 14:31:50 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 12:31:50 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <51302552-875A-4E99-937C-BDBA26AE0BBD@noao.edu>
References: <5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
	<alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
	<51302552-875A-4E99-937C-BDBA26AE0BBD@noao.edu>
Message-ID: <20090105.123150.-116105504.imp@bsdimp.com>

In message: <51302552-875A-4E99-937C-BDBA26AE0BBD at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Tony Finch wrote:
: 
: > On Mon, 5 Jan 2009, Rob Seaman wrote:
: >>
: >> The recent leap second passed (yet again) with no major issues.
: >
: > Wrong.
: >
: > Loads of Oracle RAC servers crashed because of a bug triggered by the
: > clock going backwards.
: >
: > http://www.merit.edu/mail.archives/nanog/msg13857.html
: 
: Where the statement is:
: 
: 	"I had a couple of Oracle servers (Solaris 10) reboot a couple of  
: minutes just before the leap second. All my other Solaris 10 boxes  
: appear to have stayed up fine."
: 
: The phrasing doesn't even make it clear that this was causally  
: connected to the leap second.  I assume that later messages in the  
: thread clarify this.

Yes.  When time goes backwards, like ntpd forces for a leap second,
oracle servers reboot.

: It might help to standardize a definition of "major issue".  Our group  
: uses JIRA to track issues.  We have two levels above major issue,  
: namely "critical" and "blocker".  Leap seconds are clearly not a  
: blocker, since we have moved past this one just like the previous  
: ones.  Given that the current standard is viable for hundreds of  
: years, it is also hard to rate them as critical.

The Oracle bug is a critical bug.  It is a show stopper for anybody
that wants to keep up time high (which is everybody).  Saying that you
are forcing people to reboot just because there's a leap second is
clearly wrong.  It should have been fixed before the last one, and
needs to be fixed before the next one.  Trouble is that they are rare
enough that people think they have all the time in the world.  So they
get bumped down in priority and forgotten when the 6-month warning
comes.

I'm not sure that I'd rate the current system as 'viable' except in
the narrowest definition of the word meaning "the DUT1 drift rate
means we'll not likely need more than 2 leaps a year for hundreds of
years."

: > Many time dissemination systems got it wrong, as usual.
: >
: > I wonder why OS vendors don't ship ntpd preconfigured with a  
: > leapseconds
: > table that is updated as part of the OS's normal patching process. I  
: > hope
: > that would reduce the amount of manual maintenance required for  
: > stratum 1
: > servers and increase the reliability of NTP's leap second handling.
: 
: Sound like good ideas.  Fix the bug.  Improve the processes.

Let's make the disease more tolerable by frequent shots of whiskey. :)

: > Obviously leap seconds are so important that we can't do without them,
: > but so unimportant that it doesn't matter that we can't get them to
: > work properly.
: 
: Stabilizing civil time with respect to the slowly evolving diurnal  
: rate is important.  You say so yourself:
: 
: 	http://catless.ncl.ac.uk/Risks/25.50.html#subj1

I don't say so :).  And even if I did, there's better ways than the
currently implemented leap seconds to do it.  It is clearly showing
signs of strain...

Also, stopping the accumulation of leap seconds does not necessarily
mean that civil time will drift beyond tolerance of people since time
zones are a lot easier to adjust...  What the heck do I care if we're
6 hours behind UTC or 7, just so long as everybody I have to deal with
in my local area agrees.

: If leap seconds are truly failing to satisfy a requirement for  
: ignorability, we have mentioned many different possibilities over the  
: years for stabilizing civil timekeeping.
: 
: The ITU proposal to simply ignore the whole thing for a thousand years  
: is not one of these.

I think that this is actually a good thing.  We've only had precision
atomic time keeping for like 50 years.  We've only had leap seconds
for 35 years.  At best we have data for maybe a couple of hundred
years of the length of day trends with any high precision.  We have OK
data ranging back only a couple of thousand of years (average changes
based on the drifting of eclipses).  With this paucity of data, I'm
not sure that we can do planning for thousands of years.  Especially
since we know that our dance partner is fickle and prone to
tantrums...

Warner

From dot at dotat.at  Mon Jan  5 14:40:30 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 19:40:30 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105.115013.387220651.imp@bsdimp.com>
References: <20090105.105434.547436998.imp@bsdimp.com>
	<5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
	<alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
	<20090105.115013.387220651.imp@bsdimp.com>
Message-ID: <alpine.LSU.2.00.0901051931110.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, M. Warner Losh wrote:
>
> : I wonder why OS vendors don't ship ntpd preconfigured with a leapseconds
> : table that is updated as part of the OS's normal patching process. I hope
> : that would reduce the amount of manual maintenance required for stratum 1
> : servers and increase the reliability of NTP's leap second handling.
>
> Does ntpd actually use the leap seconds table in preference to what
> remote systems are telling it?  I recall years ago trying to configure
> things and not being able to make this work reliably...

Dunno - the documentation isn't clear, and the implementation seems to
have changed in various ways over time. Part of the problem is that the
protocol's support for disseminating the full table is mixed up with the
autokey authentication mechanism, though the current documentation on the
website makes it look easier than the man pages on my oldish FreeBSD box.
See the "leapfile" option at
http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
TYNE DOGGER: EASTERLY 3 OR 4, VEERING WESTERLY 5 TO 7. MODERATE. RAIN LATER.
GOOD BECOMING MODERATE.

From imp at bsdimp.com  Mon Jan  5 14:47:05 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 12:47:05 -0700 (MST)
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <alpine.LSU.2.00.0901051931110.10002@hermes-1.csi.cam.ac.uk>
References: <alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
	<20090105.115013.387220651.imp@bsdimp.com>
	<alpine.LSU.2.00.0901051931110.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <20090105.124705.-1108456119.imp@bsdimp.com>

In message: <alpine.LSU.2.00.0901051931110.10002 at hermes-1.csi.cam.ac.uk>
            Tony Finch <dot at dotat.at> writes:
: On Mon, 5 Jan 2009, M. Warner Losh wrote:
: >
: > : I wonder why OS vendors don't ship ntpd preconfigured with a leapseconds
: > : table that is updated as part of the OS's normal patching process. I hope
: > : that would reduce the amount of manual maintenance required for stratum 1
: > : servers and increase the reliability of NTP's leap second handling.
: >
: > Does ntpd actually use the leap seconds table in preference to what
: > remote systems are telling it?  I recall years ago trying to configure
: > things and not being able to make this work reliably...
: 
: Dunno - the documentation isn't clear, and the implementation seems to
: have changed in various ways over time. Part of the problem is that the
: protocol's support for disseminating the full table is mixed up with the
: autokey authentication mechanism, though the current documentation on the
: website makes it look easier than the man pages on my oldish FreeBSD box.
: See the "leapfile" option at
: http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html

Yea, that page hasn't changed since I tried this.  I'll have to do
some experiments locally to see if I can make this work...

Warner

From dot at dotat.at  Mon Jan  5 15:17:03 2009
From: dot at dotat.at (Tony Finch)
Date: Mon, 5 Jan 2009 20:17:03 +0000
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <51302552-875A-4E99-937C-BDBA26AE0BBD@noao.edu>
References: <496214F4.1090304@rubidium.dyndns.org>
	<20090105.082008.776520750.imp@bsdimp.com>
	<EE24F7F1-DEA0-4867-BD8A-89EDEC929C47@noao.edu>
	<20090105.105434.547436998.imp@bsdimp.com>
	<5C7FF13F-320E-4EB3-A63F-0064FCF2A40C@noao.edu>
	<alpine.LSU.2.00.0901051819010.10002@hermes-1.csi.cam.ac.uk>
	<51302552-875A-4E99-937C-BDBA26AE0BBD@noao.edu>
Message-ID: <alpine.LSU.2.00.0901051942090.10002@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Rob Seaman wrote:
>
> Stabilizing civil time with respect to the slowly evolving diurnal rate is
> important.  You say so yourself:
>
> 	http://catless.ncl.ac.uk/Risks/25.50.html#subj1

That post is not entirely serious :-) Perhaps I should post a followup
without my tongue in my cheek that explains the RISKS that the sunrise
time idea is supposed to make readers think about.

> The ITU proposal to simply ignore the whole thing for a thousand years
> is not one of these.

I should probably be clear that I use the term "civil time" to mean what
wall clocks say. You seem to use it to mean UT.

My opinion is that the time zone system is enough to cope with the offset
between civil time and atomic time (whether that's TAI or GPS or TI or UTC
without leap seconds). The TZ mechanism has a theoretical resolution of a
minute, but in common use we usually round offsets to the hour (apart from
a few brave jurisdictions). It has a theoretical range of over four days
which should suffice considerably further into the future than the current
UTC rules. It has a well-exercised mechanism for revising offsets that is
devolved, rather than requiring global consensus. I don't see why we need
more than one mechanism for resetting our clocks to match the hours of
sunlight.

The above is basically what I said in my RISKS item, except with the
absurd parts removed. Sunrise time's fine-grained DST adjustments are
crazy because they optimise for precision at the expense of ease of use.
Sounds like UTC's leap seconds...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
ROCKALL MALIN HEBRIDES BAILEY: SOUTHERLY VEERING WESTERLY 5 OR 6, INCREASING 7
FOR A TIME IN HEBRIDES, DECREASING 3 OR 4 LATER EXCEPT IN MALIN. MODERATE OR
ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From adi at stav.org.il  Mon Jan  5 16:05:08 2009
From: adi at stav.org.il (Adi Stav)
Date: Mon, 5 Jan 2009 23:05:08 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
Message-ID: <20090105210508.GI6161@stav.org.il>

On Mon, Jan 05, 2009 at 09:39:28AM -0700, Rob Seaman wrote:
>
> Lower limits are hard to pin down.  Human tolerance on a particular day 
> is not the same thing as the tolerance over a year or a lifetime.   
> Straining a tolerance for one human is not the same as straining it for 6 
> billion.  Human tolerances in general need to be interpreted in terms of 
> our infrastructure, not just personal perception as we walk from parking 
> lot to office.

How is that? That is to say, what problems could exceeding the
tolerance(s) cause? (Especially problems that time zones far from their 
reference meridians, DST switches twice a year, and the difference between 
mean and apparent solar time don't already cause). I'm not arguing that 
there arent's such problems, but I don't know what they are.

Only thing I can imagine that is not covered by time zones etc. is the 
minute of drift that will be experienced over a person's (or a system's) 
life time.

> The upper limit has been specified as a "statement against penal  
> interest" by the ITU.  Public enemy  number one of leap seconds says an 
> hour is the upper limit :-)

An hour makes a lot of sense from a usability point of view, because it
is the primary division of a day.

>>> Embargoing leap seconds (or their equivalent) for periods of decades 
>>> or
>>> centuries is the same as not making intercalary adjustments at all.
>>
>> Why is that? Even the Gregorian reform does not come into effect  
>> except
>> every one or two centuries. Yet it is followed exactly.
>
> Gregory revised the Julian calendar.  The fundamental standard remains  
> rooted in what the ancients discovered.  The proper comparison is to the 
> every four year scheduling of leap day opportunities - sometimes those 
> opportunities remain nulled out, but they still exist.

The Gregorian reform revised the Julian calendar, but it still had to be
introduced. It set a schedule that does not come into effect except once
every one or two centuries, which was followed to the letter. I think
this is impressive, even if it used a pre-existing mechanism.

A good parallel would be adding leap hours and using the existing DST
mechanism (not that I can't see other issues with it).

But here's a thing -- maybe suggestions for making leaps happen very
infrequently are seen as dishonest, "let it slide" in disguise. But it
doesn't have to be this way. I can see good, honest, technical reasons
for leaping every few centuries. You can use leaping mechanisms
that are simply not available when you have to leap every year or two. 
(For example, you can introduce a new time scale (UTC-n) every few 
centuries and deprecate the old one over decades as users switch to 
the new one. I can think of several technical advantages of such a 
system over leaping an existing time scale.) Another example -- the
Julian calendar did slide over a very long time, yet it did not stop 
people from fixing it, and that was even as its original definition 
did not prescribe the fix. If a definition of a time scale does
explicitly require a leap minute or hour in a very long time, why 
assume in advance that it will not be followed?

> The seasonal or diurnal trends in the calendar or clock need to be  
> sampled frequently enough to avoid significant quantization errors.   
> Leap seconds are productive from this point of view precisely because  
> civilians can ignore them.

I'm sorry, I don't understand :)

>> By the way, it can be argued that the smoothness property is not  
>> strictly
>> necessary for calendars. Consider popular and long-used artihmetic
>> lunisolar calendars, such as the Hebrew, Hindu, and Chinese calendars,
>> that intercalate their years to a resolution of a month.
>
> A very interesting observation.  What calendars does the world really  
> depend on for various purposes?  That is, what is the market penetration 
> of the Gregorian/Julian calendar?  I would guess nearly 100% in Europe 
> and North America.  What about the rest of the world?

I think they are used in conjuction with the Gregorian for different 
purposes, such as for public holidays of traditional origin. (As an 
anecdote, DST in Israel starts according to the Hebrew calendar but ends 
according to the Gregorian.) But I don't think it matters much for our 
purpose, because any culture which is in contact with the current global
civilization will be under a lot of pressure to adopt the Gregorian
calendar for many purposes, even if its traditional calendar is actually
superior for its needs. Prior to contact with the Western civilization,
the old Chinese calendar was used in China for a long time. I don't
think we have any reason to assume that the Gregorian calendar is 
superior to a lunisolar calendar and that those lunisolar cultures 
changed calendar for this reason rather than for reasons of culture and
trade influence.

From seaman at noao.edu  Mon Jan  5 18:31:44 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 16:31:44 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105210508.GI6161@stav.org.il>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
Message-ID: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>

Adi Stav wrote:

> what problems could exceeding the tolerance(s) cause?

Well covered in the archive.  For astronomy, 1 second of time is 15  
seconds of arc on the equator.  This is a large error (colossal for  
some purposes).  It doesn't appear that any other industry has  
actually performed a coherent risk analysis.  For some reason this is  
asserted to be the astronomers' responsibility.

> (Especially problems that time zones far from their reference  
> meridians, DST switches twice a year, and the difference between  
> mean and apparent solar time don't already cause).

This confuses periodic with secular effects, also in the archive.

> A good parallel would be adding leap hours and using the existing  
> DST mechanism


Reasons why leap hours won't work are in the archive.  There was a  
clear consensus from both sides of the aisle that the notion of leap  
hours is absurd.  Alternately, by relying on shifting timezones, there  
would be no underlying stabilized civil timescale permitting  
commonsense timekeeping inferences by humans.

By contrast, interval time is important to computers.  Computers are  
good at computing.

> I don't understand :)


Imagine a version of the Gregorian calendar that interpolates leap  
days only every 400 hundred years.  That would amount to about 3  
months at a time.  Since this is a whole season, it is equivalent to  
not stabilizing the calendar at all.

Leap hours or tweaking timezones can be interpreted the same way.  If  
intercalary adjustments are the width of a timezone, no practical  
stabilization is occurring.

Rob


From imp at bsdimp.com  Mon Jan  5 19:26:05 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Jan 2009 17:26:05 -0700 (MST)
Subject: [LEAPSECS] Reliability
In-Reply-To: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
Message-ID: <20090105.172605.-1782455306.imp@bsdimp.com>

In message: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Adi Stav wrote:
: 
: > what problems could exceeding the tolerance(s) cause?
: 
: Well covered in the archive.  For astronomy, 1 second of time is 15  
: seconds of arc on the equator.  This is a large error (colossal for  
: some purposes).  It doesn't appear that any other industry has  
: actually performed a coherent risk analysis.  For some reason this is  
: asserted to be the astronomers' responsibility.

There were three groups of people identified as caring where the earth
is pointing to a high degree of accuracy.

	(1) Astronomers so they know where to point their telescopes.
	(2) Space Engineers wishing to know where their satellites or
	    other objects of interest are.
	(3) Navigators that still rely on astral navigation.

The first group needs time accurate to a few milliseconds to point the
largest of their telescopes, less accurate for the smaller ones (with
1s being a very large error for all but the smallest scapes).  Having
time broadcast available, and having that time within 1s of UT allows
these smaller errors to be corrected in the mid to small telescopes.
The larger ones need daily updates of DUT1 to get the job done.  The
mid sized ones can cope well enough with the DUT1 broadcast to 100ms
in things like WWVB.  There's also software that's used in the
astronomy world that benefits from the DUT1 < 1s rule that would need
to be retooled.

The second group has even tigher tolerances than the first, since
their birds are moving much faster than planets and the servos have to
be both fast and accurate to track them.  These folks usually are in
the classified world, so little can be said for sure about them.  What
is known is they have very high precision timing gear and software
that takes the DUT1 difference into account, and may have 'back door'
information to the raw measurements that go into the daily numbers
that are published.  This group is most likely to be able to cope with
DUT1 since they have lots of $$$ to track these things.  Also, 'their'
might not imply titular ownership, merely interest.

Most astral navigation is done with GPS these days.  There are a
vanishingly small number of folks that do it by hand, listen to
shortwave broadcasts to get the time, etc.  The US Navy doesn't even
have the gear on board to do the astral navigation anymore, I'm told.
Most of the folks in this forum have written them off as not being a
constituency worth caring about, but they are mentioned here for
completeness.

All other users of time, it is widely agree, basically want everyone
to agree on a time, have the sun basically overhead around noon, and
do what they are told.  There's debate over what each of these loosey
goosey terms means, and what the boundaries are for them.

: > (Especially problems that time zones far from their reference  
: > meridians, DST switches twice a year, and the difference between  
: > mean and apparent solar time don't already cause).
: 
: This confuses periodic with secular effects, also in the archive.

Well, yes and no.  If you permanently shift an hour to account for the
drift of time, then it is no different than permanently shifting 1s.
The question is who does it and when.  An interesting debating point
as well.

There is an important point to be made here.  The reason that DUT1
matters to most people is for the sun overhead at noon feature.
Sliding time zones solves that issue for many people, although there
is much debate about the aesthetics of doing this.

: > A good parallel would be adding leap hours and using the existing  
: > DST mechanism
: 
: 
: Reasons why leap hours won't work are in the archive.  There was a  
: clear consensus from both sides of the aisle that the notion of leap  
: hours is absurd.  Alternately, by relying on shifting timezones, there  
: would be no underlying stabilized civil timescale permitting  
: commonsense timekeeping inferences by humans.

Leap hours in UTC.  Let's be clear what we're talking about.  Also, I
don't think that your assertion that there's no stabilized civil
timescale causing issues has a firm foundation, let alone one to draw
the conclusion that it is a problem.  If DUT1 and the timezone info
were known in a database (like timezones and leap seconds are today),
then historians would be able determine when things happened, where
the sun was etc with more or less the same precision they have today.
The computations would be harder, and it has been debated as to the
extent of the hardness (eg does it really matter or not).

: By contrast, interval time is important to computers.  Computers are  
: good at computing.

True, but they are only as good at computing as the programmers are at
writing code, and the test organizations are at validating that code.

: > I don't understand :)
: 
: Imagine a version of the Gregorian calendar that interpolates leap  
: days only every 400 hundred years.  That would amount to about 3  
: months at a time.  Since this is a whole season, it is equivalent to  
: not stabilizing the calendar at all.
: 
: Leap hours or tweaking timezones can be interpreted the same way.  If  
: intercalary adjustments are the width of a timezone, no practical  
: stabilization is occurring.

For the seasons, it is clear that this drift is intolerable.  At least
from the historical technological level of most farmers.  They rely on
the calendar to do their planing, harvesting, etc.  To have it drift
that much wrt the seasons is a big deal.

Contrast this with our daily life where apparent solar time drifts by
dozens of minutes over the course of a year (granted, around a mean).
DST moves time of day for most people by an hour forward in the
spring, back in the fall.  In such an environment, a 1 hour shift once
every thousand years or so doesn't seem like such a horrible idea.  It
wouldn't be that disruptive.  It also wouldn't be a leap-hour in the
UTC time scale, but rather just a DST without end once in 50
generations.

Of course, I doubt there'd be more than a couple of these shifts
before people realize that something else is needed.  There may never
be a shift, but instead a change to a whole new time system as well
that suits the needs of future generations better.  One that we cannot
imagine from this vantage point in time.  Can you imagine being alive
at the time of Christ and thinking you'd be able to measure the length
of the day so accurately that you'd detect variations at the 1e-8
level?  And even if you did, would you have the skills necessary to
work out all the implications of that in advance?  Or that there'd be
a standard written for it in a language that wasn't even around at the
time?  This suggests, at least to some, that predicting what people
will need and want over such long periods of time is difficult at
best.  Both sides use this as part of their argument: the
pro-leapsecond folks to say that it keeps things in sync, which gives
future generations more options.  The anti-leapsecond folks to say
that things will be so different, it just might not matter.

Warner

From magnus at rubidium.dyndns.org  Mon Jan  5 19:45:32 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 06 Jan 2009 01:45:32 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <3951D01D-BCC5-4658-8422-E6AC126654D3@noao.edu>
References: <4960C988.6090005@erols.com>	<49613050.6030503@rubidium.dyndns.org>	<496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>	<20090105102452.GJ14473@fysh.org>	<4961E4E5.8010908@rubidium.dyndns.org>	<61D527C3-DE55-42A8-98A4-0C69BC3C3E93@noao.edu>	<496214F4.1090304@rubidium.dyndns.org>
	<3951D01D-BCC5-4658-8422-E6AC126654D3@noao.edu>
Message-ID: <4962A9AC.7080709@rubidium.dyndns.org>

Rob Seaman skrev:
> Magnus Danielson wrote:
> 
>> Hate to nitpick you, but that is a different representation, not a 
>> different interpretation.
> 
> Even in technical documentation, words retain their broader meanings.  I 
> was suggesting that instead of interpreting sexagesimal values as sets 
> of integers, one can interpret them as single real values (whether fixed 
> or floating point).  One also often interprets sexagesimal values as 
> strings.  This may also be a question of representation.  And 
> representation is generally an issue for the programmer.  
> Interpretation, an issue for the user.

Actually, my point was that we was discussing a rather small topic, 
namely various short-hand interpretations of the POSIX UTC to time_t 
mapping. What you provided was not another interpretation of that 
mapping, but a different representation of broken down time into some 
linear scale, which is something different than an interpretation. So, 
you shifted away from the context given earlier in the thread.

Had not the context of what we was discussing been so narrow, I agree on 
the choice of wording.

>> The floating point number is thus in hours, is that more practical 
>> than say days?
> 
> Yes.  A civil clock expresses an angle in h:m:s.  Sexagesimal strings 
> broadly represent (or are interpreted as) angles, e.g., latitude, 
> longitude, declination, right ascension, galactic latitude and 
> longitude, ecliptic latitude and longitude, great circle distances on 
> the Earth or the celestial sphere, altitude/elevation and azimuth.  
> Whether h:m:s or d:m:s (or decimal representations of hours or degrees 
> or radians) these are angles all.
> 
> Hence the intuitive conversion between sidereal time and the "hour 
> angle" of a telescope.

Well, that they represent angles is quite clear, it was just that hour 
angle was more suitable than 360 degrees, fractional day or something. 
Thus, is there some specific usefullness in hour-angles in particular?
I can settle for traditional practice... I can't say I know the practice 
of large telescopes.

Cheers,
Magnus

From magnus at rubidium.dyndns.org  Mon Jan  5 20:05:36 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 06 Jan 2009 02:05:36 +0100
Subject: [LEAPSECS] [time-nuts] Leap Quirks
In-Reply-To: <20090105.081129.1586007667.imp@bsdimp.com>
References: <496157C4.2050300@erols.com>	<20090104.191536.179953595.imp@bsdimp.com>	<20090105102452.GJ14473@fysh.org>
	<20090105.081129.1586007667.imp@bsdimp.com>
Message-ID: <4962AE60.7050406@rubidium.dyndns.org>

M. Warner Losh skrev:
> In message: <20090105102452.GJ14473 at fysh.org>
>             Zefram <zefram at fysh.org> writes:
> : M. Warner Losh wrote:
> : >So time_t is effectively defined in POSIX to be:
> : >
> : >	d * 86400 + min(tod(x), 86399)
> : >
> : >where d is the number of days since 01-01-1970, and tod is the second
> : >since midnight within the day.
> : 
> : Actually it's simpler than that.  The expression given by POSIX amounts to
> : 
> : 	d * 86400 + tod(x)
> : 
> : so a leap second appears identical to the first second of the next day,
> : rather than a repeat of the previous second.
> 
> That's what the broken down time translation results in.  However, I
> don't think that POSIX specifies the 'proper' value for the leap
> second because leap seconds are explicitly excluded from the spec.
> The reason it maps to the above is due to the normalization rules for
> the '60' part of the broken down time, not because it is a leap second
> and is defined to map there.

Actually, when you read the rationale it become clear that they where 
quite aware of how leap seconds does work. It is not fair to say they 
totally ignored it. It is more fair to say that the chose a time_t 
representation that does not allow leap seconds to be uniquely 
represented but rahter maintained the time_t % 86400 == 0 aspect for 
midnight as they thought most systems where best served by this 
definition. That this definition causes some of us grief is another thing.

A peculiar aspect of the defined mapping is however that POSIX midnight 
(time_t % 86400 == 0) occurs twice (two continous seconds) when a leap 
second is inserted such that it should trigger midnight 1 second prior 
to UTC midnight, 86400 seconds after the previous midnight and 86401 
seconds before the next.
There is a little chance that some software could double-trigger on the 
midnight event. Duplicating 23:59:59 is safer in this regard.

> : What's actually implemented
> : by particular kernels varies; Linux, for example, does something in
> : between these, jumping backwards (by 1) a few milliseconds after the
> : start of the leap second.
> 
> FreeBSD too.  Any NTP based kernel does this.

Many kernels implement the NTP interface, more or less straight as given 
I beleive.

Cheers,
Magnus

From ashtongj at comcast.net  Mon Jan  5 20:17:56 2009
From: ashtongj at comcast.net (Gerard Ashton)
Date: Mon, 5 Jan 2009 20:17:56 -0500
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105.172605.-1782455306.imp@bsdimp.com>
Message-ID: <D1B1CCA10DEC4EABBE228DDCF3D15AEF@grendel>

An addition to the list set forth by M. Warner is surveyors
who use star or sun sightings to establish precise directions
of lines (to an accuracy of less than one arcminute). Although
some surveyors do this with GPS, many surveyors do not because
of the expense of the equipment (about two orders of magnitude
more expensive than recreation-grade GPS receivers) or because
they conduct their operations in forests or other areas with
poor GPS reception. On the other hand, they have the technical
sophistication to compute the time even if DUT > 1 s.

-----Original Message-----
From: leapsecs-bounces at leapsecond.com
[mailto:leapsecs-bounces at leapsecond.com] On Behalf Of M. Warner Losh
Sent: Monday, January 05, 2009 7:26 PM
To: leapsecs at leapsecond.com; seaman at noao.edu
Subject: Re: [LEAPSECS] Reliability


In message: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:
: Adi Stav wrote:
: 
: > what problems could exceeding the tolerance(s) cause?
: 
: Well covered in the archive.  For astronomy, 1 second of time is 15  
: seconds of arc on the equator.  This is a large error (colossal for  
: some purposes).  It doesn't appear that any other industry has  
: actually performed a coherent risk analysis.  For some reason this is  
: asserted to be the astronomers' responsibility.

There were three groups of people identified as caring where the earth
is pointing to a high degree of accuracy.

	(1) Astronomers so they know where to point their telescopes.
	(2) Space Engineers wishing to know where their satellites or
	    other objects of interest are.
	(3) Navigators that still rely on astral navigation.

The first group needs time accurate to a few milliseconds to point the
largest of their telescopes, less accurate for the smaller ones (with
1s being a very large error for all but the smallest scapes).  Having
time broadcast available, and having that time within 1s of UT allows
these smaller errors to be corrected in the mid to small telescopes.
The larger ones need daily updates of DUT1 to get the job done.  The
mid sized ones can cope well enough with the DUT1 broadcast to 100ms
in things like WWVB.  There's also software that's used in the
astronomy world that benefits from the DUT1 < 1s rule that would need
to be retooled.

The second group has even tigher tolerances than the first, since
their birds are moving much faster than planets and the servos have to
be both fast and accurate to track them.  These folks usually are in
the classified world, so little can be said for sure about them.  What
is known is they have very high precision timing gear and software
that takes the DUT1 difference into account, and may have 'back door'
information to the raw measurements that go into the daily numbers
that are published.  This group is most likely to be able to cope with
DUT1 since they have lots of $$$ to track these things.  Also, 'their'
might not imply titular ownership, merely interest.

Most astral navigation is done with GPS these days.  There are a
vanishingly small number of folks that do it by hand, listen to
shortwave broadcasts to get the time, etc.  The US Navy doesn't even
have the gear on board to do the astral navigation anymore, I'm told.
Most of the folks in this forum have written them off as not being a
constituency worth caring about, but they are mentioned here for
completeness.

All other users of time, it is widely agree, basically want everyone
to agree on a time, have the sun basically overhead around noon, and
do what they are told.  There's debate over what each of these loosey
goosey terms means, and what the boundaries are for them.

: > (Especially problems that time zones far from their reference  
: > meridians, DST switches twice a year, and the difference between  
: > mean and apparent solar time don't already cause).
: 
: This confuses periodic with secular effects, also in the archive.

Well, yes and no.  If you permanently shift an hour to account for the
drift of time, then it is no different than permanently shifting 1s.
The question is who does it and when.  An interesting debating point
as well.

There is an important point to be made here.  The reason that DUT1
matters to most people is for the sun overhead at noon feature.
Sliding time zones solves that issue for many people, although there
is much debate about the aesthetics of doing this.

: > A good parallel would be adding leap hours and using the existing  
: > DST mechanism
: 
: 
: Reasons why leap hours won't work are in the archive.  There was a  
: clear consensus from both sides of the aisle that the notion of leap  
: hours is absurd.  Alternately, by relying on shifting timezones, there  
: would be no underlying stabilized civil timescale permitting  
: commonsense timekeeping inferences by humans.

Leap hours in UTC.  Let's be clear what we're talking about.  Also, I
don't think that your assertion that there's no stabilized civil
timescale causing issues has a firm foundation, let alone one to draw
the conclusion that it is a problem.  If DUT1 and the timezone info
were known in a database (like timezones and leap seconds are today),
then historians would be able determine when things happened, where
the sun was etc with more or less the same precision they have today.
The computations would be harder, and it has been debated as to the
extent of the hardness (eg does it really matter or not).

: By contrast, interval time is important to computers.  Computers are  
: good at computing.

True, but they are only as good at computing as the programmers are at
writing code, and the test organizations are at validating that code.

: > I don't understand :)
: 
: Imagine a version of the Gregorian calendar that interpolates leap  
: days only every 400 hundred years.  That would amount to about 3  
: months at a time.  Since this is a whole season, it is equivalent to  
: not stabilizing the calendar at all.
: 
: Leap hours or tweaking timezones can be interpreted the same way.  If  
: intercalary adjustments are the width of a timezone, no practical  
: stabilization is occurring.

For the seasons, it is clear that this drift is intolerable.  At least
from the historical technological level of most farmers.  They rely on
the calendar to do their planing, harvesting, etc.  To have it drift
that much wrt the seasons is a big deal.

Contrast this with our daily life where apparent solar time drifts by
dozens of minutes over the course of a year (granted, around a mean).
DST moves time of day for most people by an hour forward in the
spring, back in the fall.  In such an environment, a 1 hour shift once
every thousand years or so doesn't seem like such a horrible idea.  It
wouldn't be that disruptive.  It also wouldn't be a leap-hour in the
UTC time scale, but rather just a DST without end once in 50
generations.

Of course, I doubt there'd be more than a couple of these shifts
before people realize that something else is needed.  There may never
be a shift, but instead a change to a whole new time system as well
that suits the needs of future generations better.  One that we cannot
imagine from this vantage point in time.  Can you imagine being alive
at the time of Christ and thinking you'd be able to measure the length
of the day so accurately that you'd detect variations at the 1e-8
level?  And even if you did, would you have the skills necessary to
work out all the implications of that in advance?  Or that there'd be
a standard written for it in a language that wasn't even around at the
time?  This suggests, at least to some, that predicting what people
will need and want over such long periods of time is difficult at
best.  Both sides use this as part of their argument: the
pro-leapsecond folks to say that it keeps things in sync, which gives
future generations more options.  The anti-leapsecond folks to say
that things will be so different, it just might not matter.

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


From magnus at rubidium.dyndns.org  Mon Jan  5 20:53:58 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 06 Jan 2009 02:53:58 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>	<20090104094438.GD6161@stav.org.il>	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>	<20090104211501.GE6161@stav.org.il>	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
Message-ID: <4962B9B6.1050005@rubidium.dyndns.org>

Rob Seaman skrev:
> Adi Stav wrote:
> 
>> We know that human tolerance to DUT is higher than 20 minutes because we
>> don't usually bother to compensate for apparent solar time. We know that
>> it is probably not much higher than one or two hours because time zones
>> generally have about that resolution. We guess that it is might be about
>> one hour because many areas in the world choose time zones that are about
>> one-hour offsets from their local mean time.
>>
>> These justifications are not necessarily valid, or maybe there are other
>> or better justifications for smaller DUT maxima. I am just trying to
>> find out (for myself) what these are. This is why I asked.
> 
> Ok (to the second paragraph :-)
> 
> Lower limits are hard to pin down.  Human tolerance on a particular day 
> is not the same thing as the tolerance over a year or a lifetime.  
> Straining a tolerance for one human is not the same as straining it for 
> 6 billion.  Human tolerances in general need to be interpreted in terms 
> of our infrastructure, not just personal perception as we walk from 
> parking lot to office.
> 
> The upper limit has been specified as a "statement against penal 
> interest" by the ITU.  Public enemy  number one of leap seconds says an 
> hour is the upper limit :-)
> 
>>> Embargoing leap seconds (or their equivalent) for periods of decades or
>>> centuries is the same as not making intercalary adjustments at all.
>>
>> Why is that? Even the Gregorian reform does not come into effect except
>> every one or two centuries. Yet it is followed exactly.
> 
> Gregory revised the Julian calendar.  The fundamental standard remains 
> rooted in what the ancients discovered.  The proper comparison is to the 
> every four year scheduling of leap day opportunities - sometimes those 
> opportunities remain nulled out, but they still exist.

One should recall that the Gregorian leap day rules where just a 
improvement on the static leap day scheme of the Julian calendar so that 
it better matched the earths spinning around the sun. They also made a 
correction for the accumulate error to restore phase relationships.
This static scheme is not an exact mechanism, as the underlying 
mechanism is not exactly mirrored, but rather estimated with sufficient 
precission to be usefull over several centuries. Eventually we will need 
to revise it again, correct for the accumulated phase error and make an 
improved correction algorithm. Essentially, it is not entierly static, 
it is infact a dynamic scheme but with a very long time inbetween 
adjustments, which is sufficient considering the speed of events.
The adjustments does take time to incoperate, infact some have still not 
included them.

The leap second is essentially the same thing, but with a very short 
reshedule scheme which unfortunatly coincide with the adjustment 
oppertunities being used (actually there is 6 oppertunities on every 
decission, but a preference to only use the last). Inbetween we do have 
a static scheme. Part of the problem is the life-time of a decision over 
the static scheme provided. The actual technicalities of introducing a 
leap second would remain the same, but a longer schedule would cause 
less of a problem on the issue when they would need to be introduced.

Cheers,
Magnus

From magnus at rubidium.dyndns.org  Mon Jan  5 20:56:04 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 06 Jan 2009 02:56:04 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <85819.1231173885@critter.freebsd.dk>
References: <85819.1231173885@critter.freebsd.dk>
Message-ID: <4962BA34.1050409@rubidium.dyndns.org>

Poul-Henning Kamp skrev:
> In message <421FB837-F23F-4A16-B6F4-F26D1C58C6FA at noao.edu>, Rob Seaman writes:
> 
>> It seems very unlikely that leap day will move from February.  People  
>> are fond of February.  Also, a leap day at the end of December would  
>> be December 32nd :-)
> 
> Which would break incredibly badly thought out filsystem formats
> like FAT which encodes the day-of-month in five bits.

Among many other systems... this would make leap second akes feel like a 
very little itch. Evil man, evil.

Cheers,
Magnus

From mgy1912 at cox.net  Mon Jan  5 21:05:03 2009
From: mgy1912 at cox.net (Brian Garrett)
Date: Mon, 5 Jan 2009 18:05:03 -0800
Subject: [LEAPSECS] Reliability
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
Message-ID: <E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>


----- Original Message ----- 
From: "M. Warner Losh" <imp at bsdimp.com>
To: <leapsecs at leapsecond.com>; <seaman at noao.edu>
Sent: Monday, January 05, 2009 4:26 PM
Subject: Re: [LEAPSECS] Reliability


>
> All other users of time, it is widely agree, basically want everyone
> to agree on a time, have the sun basically overhead around noon, and
> do what they are told.  There's debate over what each of these loosey
> goosey terms means, and what the boundaries are for them.
>
>
> There is an important point to be made here.  The reason that DUT1
> matters to most people is for the sun overhead at noon feature.
> Sliding time zones solves that issue for many people, although there
> is much debate about the aesthetics of doing this.
>
>
Not being a member of the technical communities to whom this issue of leap 
seconds matters most, there's a limit on what I can contribute to this 
discussion.  However, I believe I can safely say that you time lords need 
not worry about what the general public thinks in regard to having clock 
time match the sun's position in the sky, or the "noon becomes midnight" 
scenario.  The unwarshed (sic) masses may have cared about that when society 
was still mostly agrarian (maybe farmers still do, but even they have to 
contend with DST imposed by us city folk :)), but very, very few of us get 
up with the chickens as a cultural necessity anymore.  Trust me, whatever 
becomes of leap seconds and DUT1, Joe the Plumber will be just fine.  For 
purposes of precise time and time interval, science and technology aren't 
merely the primary issue, they're the ONLY issue.


> Of course, I doubt there'd be more than a couple of these shifts
> before people realize that something else is needed.  There may never
> be a shift, but instead a change to a whole new time system as well
> that suits the needs of future generations better.  One that we cannot
> imagine from this vantage point in time.  Can you imagine being alive
> at the time of Christ and thinking you'd be able to measure the length
> of the day so accurately that you'd detect variations at the 1e-8
> level?  And even if you did, would you have the skills necessary to
> work out all the implications of that in advance?  Or that there'd be
> a standard written for it in a language that wasn't even around at the
> time?  This suggests, at least to some, that predicting what people
> will need and want over such long periods of time is difficult at
> best.  Both sides use this as part of their argument: the
> pro-leapsecond folks to say that it keeps things in sync, which gives
> future generations more options.  The anti-leapsecond folks to say
> that things will be so different, it just might not matter.
>
Well said.  The recurrent discussion of what imminent changes in timekeeping 
might mean for our posterity 500+ years from now is irrelevant because we 
have no way of knowing what their timekeeping needs or preferences might be.


Brian 


From seaman at noao.edu  Mon Jan  5 21:16:28 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Jan 2009 19:16:28 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090105.172605.-1782455306.imp@bsdimp.com>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
Message-ID: <798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>

M. Warner Losh wrote:

> It also wouldn't be a leap-hour in the UTC time scale, but rather  
> just a DST without end once in 50 generations.

Is it too much to ask that an attempt be made to describe how the  
logistics would work?

> Of course, I doubt there'd be more than a couple of these shifts  
> before people realize that something else is needed.

Design that solution instead.

> There may never be a shift, but instead a change to a whole new time  
> system as well that suits the needs of future generations better.   
> One that we cannot imagine from this vantage point in time.


Huh?  Astronomers toss around concepts of black holes, dark energy,  
microlensing and exoplanets, but humanity will evolve into some  
species unimaginable to a generation raised on Arthur C. Clarke and  
Philip K. Dick?

> Can you imagine being alive at the time of Christ and thinking you'd  
> be able to measure the length of the day so accurately that you'd  
> detect variations at the 1e-8 level?

An artificial comparison.  There has been more evolution of our  
science and culture in the past 100 years than the previous 2000.   
Also, nobody is suggesting civil timekeeping needs to trace solar time  
to better than the tenth second currently implemented.  Rather, the  
ITU wants to degrade this by close to 5 orders of magnitude.

While we shouldn't expect Bill and Ted to have many (or even any)  
details right, it is eminently practical for even primordial ooze such  
as us to speculate on implications thousands of years hence.  Having a  
plan that later proves incomplete is better than having no plan at all.

And the obvious refrain - use GPS or some other perfectly acceptable  
and already available option and leave Universal Time to the people  
who value it.  We get it that you think UT is a pointless exercise.   
Use something else instead.

> And even if you did, would you have the skills necessary to work out  
> all the implications of that in advance?  Or that there'd be a  
> standard written for it in a language that wasn't even around at the  
> time?

Do we believe that the Julian and Gregorian calendars were promulgated  
in English? :-)

Yes, I do believe this group is very skillful.  I wonder why we're so  
shy about putting those skills to good use designing a better  
timekeeping solution, rather than seeking an easy way out?

Rob


From dot at dotat.at  Tue Jan  6 04:59:53 2009
From: dot at dotat.at (Tony Finch)
Date: Tue, 6 Jan 2009 09:59:53 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
Message-ID: <alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Brian Garrett wrote:
>
> However, I believe I can safely say that you time lords need not worry
> about what the general public thinks in regard to having clock time
> match the sun's position in the sky, or the "noon becomes midnight"
> scenario. The unwarshed (sic) masses may have cared about that when
> society was still mostly agrarian (maybe farmers still do, but even they
> have to contend with DST imposed by us city folk :)), but very, very few
> of us get up with the chickens as a cultural necessity anymore.

The reason DST exists is to more closely sync our activities to sunrise.
People do care about hours of daylight, but the alignment doesn't need to
be very precise. 12:00 will never drift to midnight because we'll adjust
our timezones to compensate (assuming no changes in our cultural
relationship to time).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHWESTERLY VEERING NORTHERLY, 6 TO GALE
8, DECREASING 5 IN VIKING LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH
LATER. RAIN THEN WINTRY SHOWERS. MODERATE OR POOR, BECOMING GOOD.

From dot at dotat.at  Tue Jan  6 05:12:33 2009
From: dot at dotat.at (Tony Finch)
Date: Tue, 6 Jan 2009 10:12:33 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
Message-ID: <alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Rob Seaman wrote:
>
> Is it too much to ask that an attempt be made to describe how the logistics
> would work?

Exactly the same way that current time zones work. Every so often,
jurisdictions that become dissatisfied with their current timezone offset
or DST arrangements because of increasing DUT1 or because a politician is
under-employed will have a discussion which may or may not result in a
change.

Note that there's no need for global co-ordination. Each country (or
county) can change when it is convenient for them. The effect would
probably be a shifting of timezone boundaries in lumps and bumps that
averages out to the overall DUT1 drift.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: WESTERLY OR SOUTHWESTERLY, VEERING
NORTHWESTERLY, 5 TO 7, DECREASING 4 OR 5 LATER. SLIGHT OR MODERATE. RAIN THEN
MAINLY FAIR. MODERATE OR GOOD.

From zefram at fysh.org  Tue Jan  6 06:10:34 2009
From: zefram at fysh.org (Zefram)
Date: Tue, 6 Jan 2009 11:10:34 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <4962B9B6.1050005@rubidium.dyndns.org>
References: <20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<4962B9B6.1050005@rubidium.dyndns.org>
Message-ID: <20090106111034.GN14473@fysh.org>

Magnus Danielson wrote:
>                                                      They also made a 
>correction for the accumulate error to restore phase relationships.

Except that this correction was faulty.  By the mid 16th century, the
phase relationship between the seasons and the calendar had shifted
about 12.5 days since the inception of the Julian calendar (45 BCE).
Applying the knowledge that went into constructing the Gregorian calendar,
an attempt to correct for this shift would have amounted to skipping 12
calendar dates.  (They slightly underestimated the degree of shift.)

Instead they skipped 10 calendar dates.  This was because they didn't
aim to restore the original phase relationship of the Julian calendar.
Instead, they aimed to restore the already-shifted phase relationship
that had existed at the time of the Council of Nicea (325 CE).  The phase
shift from then until the calendar reform was about 9.8 days.

So they synchronised (as best they could) to the wrong phase, locking
into the calendar the very error they were supposedly fixing.

People are dumb.  (Sorry, I've run out of highbrow conclusions to draw
from this sort of thing.)

-zefram

From magnus at rubidium.dyndns.org  Tue Jan  6 06:50:46 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 06 Jan 2009 12:50:46 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106111034.GN14473@fysh.org>
References: <20090104094438.GD6161@stav.org.il>	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>	<20090104211501.GE6161@stav.org.il>	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>	<20090105143227.GG6161@stav.org.il>	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>	<4962B9B6.1050005@rubidium.dyndns.org>
	<20090106111034.GN14473@fysh.org>
Message-ID: <49634596.3090702@rubidium.dyndns.org>

Zefram skrev:
> Magnus Danielson wrote:
>>                                                      They also made a 
>> correction for the accumulate error to restore phase relationships.
> 
> Except that this correction was faulty.  By the mid 16th century, the
> phase relationship between the seasons and the calendar had shifted
> about 12.5 days since the inception of the Julian calendar (45 BCE).
> Applying the knowledge that went into constructing the Gregorian calendar,
> an attempt to correct for this shift would have amounted to skipping 12
> calendar dates.  (They slightly underestimated the degree of shift.)
> 
> Instead they skipped 10 calendar dates.  This was because they didn't
> aim to restore the original phase relationship of the Julian calendar.
> Instead, they aimed to restore the already-shifted phase relationship
> that had existed at the time of the Council of Nicea (325 CE).  The phase
> shift from then until the calendar reform was about 9.8 days.
> 
> So they synchronised (as best they could) to the wrong phase, locking
> into the calendar the very error they were supposedly fixing.
> 
> People are dumb.  (Sorry, I've run out of highbrow conclusions to draw
> from this sort of thing.)

This basically suggest that making the correction points to far away 
also makes it a real risk of loosing the reference they where ment to 
adjust to. So you need something sufficiently distant not to be too 
annoying and sufficiently often reoccuring that it can be done correctly.

Cheers,
Magnus

From seaman at noao.edu  Tue Jan  6 08:30:00 2009
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 6 Jan 2009 06:30:00 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
	<alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
Message-ID: <846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>

Tony Finch wrote:

> The reason DST exists is to more closely sync our activities to  
> sunrise.


The reason DST exists is because it has become a self-propagating  
cultural meme.

Your April Fool's post on risks may be the most coherent analysis I've  
read on the subject.  (Not trying to be ironic.)  In general, this  
list (sad to say - now I'm being ironic :-) represents the species'  
hoard of knowledge on certain topics.

Where I grew up in the U.S. mid-Atlantic states, the most obvious  
effect of DST was to extend the usable hours of daylight for Summer  
evenings.  (Perhaps some other narrative applies at higher or lower  
latitudes?)  Since we were off school, the morning issues were  
meaningless.  And workers go to work when their bosses tell them to.   
The time they own for themselves and their families is after work.

Recently, all discussions of DST are framed in turns of energy.  It  
seems like every argument for DST (saves energy for lighting in the  
mornings) is countered by some argument against (increases cooling  
costs in the evenings).  If DST were really a mechanism for managing  
our natural daylight resource, rather than a naive attempt at PR  
regarding petroleum resources, it would be applied in the Winter when  
the daylight is in shortest supply.

Rob


From dot at dotat.at  Tue Jan  6 09:14:15 2009
From: dot at dotat.at (Tony Finch)
Date: Tue, 6 Jan 2009 14:14:15 +0000
Subject: [LEAPSECS] time zones and DST
In-Reply-To: <846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
	<alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
	<846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>
Message-ID: <alpine.LSU.2.00.0901061332390.10002@hermes-1.csi.cam.ac.uk>

On Tue, 6 Jan 2009, Rob Seaman wrote:
>
> Your April Fool's post on risks may be the most coherent analysis I've
> read on the subject [of DST].

Thanks :-)

> Where I grew up in the U.S. mid-Atlantic states, the most obvious effect of
> DST was to extend the usable hours of daylight for Summer evenings.  (Perhaps
> some other narrative applies at higher or lower latitudes?)

Same everywhere as far as I can tell.

> Since we were off school, the morning issues were meaningless.  And
> workers go to work when their bosses tell them to.  The time they own
> for themselves and their families is after work.

Right. People generally prefer to use their evenings for recreation rather
than socializing in the mornings before work. Hence shifting work closer
to sunrise in the summer to get lighter evenings at the expense of the
less-used mornings. If you read David Prerau's history of DST it becomes
clear that it isn't possible to get bosses to agree on an earlier summer
timetable except by changing the clocks. http://www.seizethedaylight.com/

DST became popular in the 20th century because of the increase in
urbanization and the consequent increase in the time-related coupling of
our activities. This made it harder for individuals and organizations to
set their timetables according to their own preferences. The number of
organizations makes it impossible to get consensus on a co-ordinated
timetable change, so it has to be done by the government dictating when to
change the clocks.

This is why DST is a sensible solution to the problem of the mismatch
between natural human preferences and inflexible timetables based on mean
solar time.

> Recently, all discussions of DST are framed in turns of energy.

As you say, that is a red herring. It's similar in that respect to the
arguments made in Scotland (where winter days are not long enough for
daylight to cover both the morning and evening commute) about the
relationship between accident rates and choice of time zone. Whenever an
English politician suggests switching to CET to match the continent, the
Scots insist they will stay on GMT because they say children will get hurt
on the roads going to school. In truth, being on GMT means the accidents
happen in the evening instead, and the real reason for resisting change is
they prefer the sun to rise before work.

(The efficiency argument may have had some merit for war economies, but
DST would have been discarded in peacetime like other war measures were it
not popular for reasons other than efficiency.)

> If DST were really a mechanism for managing our natural daylight resource,
> rather than a naive attempt at PR regarding petroleum resources, it would be
> applied in the Winter when the daylight is in shortest supply.

Your phrasing there makes it sound like you think DST increases the supply
of daylight. Obviously it doesn't. It just improves the match between our
timetables and sunrise, reducing the amount of wasted light in the early
morning. There's no wasted light in winter mornings, so it doesn't make
sense to have DST then.

Having said that, there is a general tendency for time zones to move so
that they are centred further west than their nominal meridian. The
Central European and North American Central time zones are good examples.
This has the effect of making sunrise later in the winter than it would
otherwise be, in those areas near the edges of the time zones - that is, a
kind of winter DST, though often with even more DST in the summer.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
ROCKALL MALIN: SOUTHERLY IN SOUTH AT FIRST, AND BECOMING VARIABLE 4 IN NORTH
FOR A TIME, OTHERWISE MAINLY WESTERLY OR SOUTHWESTERLY, 4 OR 5, OCCASIONALLY
6. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.

From seaman at noao.edu  Tue Jan  6 11:36:28 2009
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 6 Jan 2009 09:36:28 -0700
Subject: [LEAPSECS] time zones and DST
In-Reply-To: <alpine.LSU.2.00.0901061332390.10002@hermes-1.csi.cam.ac.uk>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
	<alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
	<846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>
	<alpine.LSU.2.00.0901061332390.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <FFB8120C-3F04-4A2F-80D9-B1B581DC8D7F@noao.edu>

Tony Finch wrote:

> This is why DST is a sensible solution to the problem of the  
> mismatch between natural human preferences and inflexible timetables  
> based on mean solar time.

I don't think "inflexible" is the right choice of words, but I'll let  
it pass to make a more basic point.  DST only offers the opportunity  
for sensible seasonal solutions.  In the absence of coherent  
government oversight (an oxymoron if ever there was), no such solution  
will be sensible.

I continue to question whether DST is the right platform for  
accommodating secular shifts in the underlying worldwide civil  
timescale.  Some sort of longitudinal study would be required to build  
a case for any "solution" that doesn't stabilize the timescale.

> Your phrasing there makes it sound like you think DST increases the  
> supply of daylight.

No, just that the pressure to do the job right is greater when the  
resource is in shorter supply.  Since DST is actually applied  
precisely when it spills over both further into the morning and  
further into the evening hours, I question whether your explanation is  
complete or consistent.

> Having said that, there is a general tendency for time zones to move  
> so that they are centred further west than their nominal meridian.

As with other clock and calendrical issues, there is rather a tendency  
to overgeneralize.  For instance, it would be very interesting to  
contrast DST policies in the southern hemisphere with those in the  
north.  The Earth is very asymmetric north and south and such a study  
would be likely to reveal interesting usage patterns relating to  
underlying human factors.

Rob


From seaman at noao.edu  Tue Jan  6 11:45:52 2009
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 6 Jan 2009 09:45:52 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
	<05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu>
Message-ID: <4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu>

To return to a previous point, Tony Finch wrote:

> Note that there's no need for global co-ordination. Each country (or  
> county) can change when it is convenient for them. The effect would  
> probably be a shifting of timezone boundaries in lumps and bumps  
> that averages out to the overall DUT1 drift.

Some requirements (in general, the most important ones) apply to the  
results of implementing a system, not to the manner of implementing it.

These spiraling lumps and bumps in time are not acceptable.  Perhaps  
we might ask a few historians or folks from other long point-of-view  
professions whether there is a need for global coordination?  Time  
isn't just about what happens today.  Time has permanence in our  
records and histories.

(Also, I'm not sure saying "the politicians will fix it" is your most  
successful tactical point :-)

Leap seconds represent authentic intercalary corrections.  (So would  
leap hours - with the small caveat that they cannot be implemented.)   
On the other hand, the lumps and bumps from the timezone gimmick both  
accelerate with time, and pile higher and higher, one on top of the  
other.  Real time (the solar time that drives politicians in each  
county or country to reluctantly deal with this issue) will get  
further and further from civil time.  As a result, civil time will  
mean less and less.

As with the notion of leap hours, the lumps and bumps are really more  
like the Himalayas.

We need to stabilize civil time just like we need to stabilize the  
civil calendar and on a schedule not too dramatically different.

Rob



From dot at dotat.at  Tue Jan  6 12:12:37 2009
From: dot at dotat.at (Tony Finch)
Date: Tue, 6 Jan 2009 17:12:37 +0000
Subject: [LEAPSECS] time zones and DST
In-Reply-To: <FFB8120C-3F04-4A2F-80D9-B1B581DC8D7F@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68>
	<alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
	<846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>
	<alpine.LSU.2.00.0901061332390.10002@hermes-1.csi.cam.ac.uk>
	<FFB8120C-3F04-4A2F-80D9-B1B581DC8D7F@noao.edu>
Message-ID: <alpine.LSU.2.00.0901061640580.10002@hermes-1.csi.cam.ac.uk>

On Tue, 6 Jan 2009, Rob Seaman wrote:
> Tony Finch wrote:
>
> > This is why DST is a sensible solution to the problem of the mismatch
> > between natural human preferences and inflexible timetables based on mean
> > solar time.
>
> I don't think "inflexible" is the right choice of words, but I'll let it pass
> to make a more basic point.

The individual timetables aren't inflexible, but the aggregate of all of
them is.

> DST only offers the opportunity for sensible seasonal solutions.  In the
> absence of coherent government oversight (an oxymoron if ever there
> was), no such solution will be sensible.

Right. Prerau's history provides plenty of examples.

> No, just that the pressure to do the job right is greater when the
> resource is in shorter supply.  Since DST is actually applied precisely
> when it spills over both further into the morning and further into the
> evening hours, I question whether your explanation is complete or
> consistent.

Don't be confused by the name: it isn't about "saving" daylight. Winter
time already makes best use of daylight when there's less available.
In the summer there's more daylight, but the early morning daylight is
wasted, so we move the clocks so that we can make better use of the extra
light.

DST can be viewed as a version of my "sunrise time" idea that has been
simplified so that it's acceptable for practical use - i.e. roughly
adjusting clocks to follow sunrise rather than noon, which has the effect
of giving you light later into the evening in the summer.

> > Having said that, there is a general tendency for time zones to move
> > so that they are centred further west than their nominal meridian.
>
> As with other clock and calendrical issues, there is rather a tendency to
> overgeneralize.  For instance, it would be very interesting to contrast DST
> policies in the southern hemisphere with those in the north.

Southern timezones are biased westwards for the same reason as northern
ones - the sun rises later in the west there too. It isn't a seasonal
effect so there's no north/south difference. What is different is the
calendar months in which DST is applied.

There seems to be less agreement over DST schedules in the south - they
don't have large co-ordinated blocks following the same schedule like
North America and Europe. Australia doesn't have a federal schedule, for
example. I guess this is because there aren't any similarly large highly
developed and densely poulated areas in the south.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
ROCKALL MALIN: MAINLY SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING
VARIABLE 3 FOR A TIME. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.

From dot at dotat.at  Tue Jan  6 12:47:28 2009
From: dot at dotat.at (Tony Finch)
Date: Tue, 6 Jan 2009 17:47:28 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
	<05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu>
	<4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu>
Message-ID: <alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>

On Tue, 6 Jan 2009, Rob Seaman wrote:

> To return to a previous point, Tony Finch wrote:
>
> > Note that there's no need for global co-ordination. Each country (or
> > county) can change when it is convenient for them. The effect would
> > probably be a shifting of timezone boundaries in lumps and bumps that
> > averages out to the overall DUT1 drift.
>
> These spiraling lumps and bumps in time are not acceptable.

They're certainly not very tidy :-) It's how DST works today, and
obviously this pisses off people like us who like technical stuff to be
implemented with more care and foresight than politicians use when mucking
about with clocks.

> (Also, I'm not sure saying "the politicians will fix it" is your most
> successful tactical point :-)

:-) I don't expect them to fix it, I expect them to continue fumbling with
it in much the same way as they do now - which is an inconvenience we know
how to deal with, both socially and in software (unlike leap seconds).

> On the other hand, the lumps and bumps from the timezone gimmick both
> accelerate with time, and pile higher and higher, one on top of the
> other.

Yes, that's the point, but they accelerate much much slower than leap
seconds, and the pile becomes unweildy ten times further in the future
than the UTC rules.

> Real time (the solar time that drives politicians in each county or
> country to reluctantly deal with this issue) will get further and
> further from civil time.  As a result, civil time will mean less and
> less.

I think for "real time" you mean "local civil time", and for "civil time"
you mean "atomic time".

The way we avoid the problems caused by politicians fiddling with
timezones is by using UTC instead of local time. In the future that role
would be taken by atomic time. Yes it won't trivially relate to any kind
of local time at any place on earth, like UTC and GMT, but that isn't what
we need it for.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
ROCKALL MALIN: MAINLY SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING
VARIABLE 3 FOR A TIME. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.

From mgy1912 at cox.net  Tue Jan  6 15:21:34 2009
From: mgy1912 at cox.net (Brian Garrett)
Date: Tue, 6 Jan 2009 12:21:34 -0800
Subject: [LEAPSECS] Reliability
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu><20090105.172605.-1782455306.imp@bsdimp.com><E8D0F3D992CB4511BDDD7652AB2341D2@company48fcb68><alpine.LSU.2.00.0901060953470.8944@hermes-1.csi.cam.ac.uk>
	<846AC677-690C-4B67-B48A-BFB7F14F6757@noao.edu>
Message-ID: <0163006B465442AE80036C67173AFCC5@company48fcb68>


----- Original Message ----- 
From: "Rob Seaman" <seaman at noao.edu>
To: "Leap Second Discussion List" <leapsecs at leapsecond.com>
Sent: Tuesday, January 06, 2009 5:30 AM
Subject: Re: [LEAPSECS] Reliability


> Tony Finch wrote:
>
>> The reason DST exists is to more closely sync our activities to
>> sunrise.
>
>
> The reason DST exists is because it has become a self-propagating
> cultural meme.
>
Gotta agree on this one.  I like long summer evenings as much as the next 
guy, but to be realistic, DST is an idea whose time has come and gone.  They 
didn't have air conditioning, massive automobile traffic, or 24/7 business 
operations back in William Willet's day.

> Your April Fool's post on risks may be the most coherent analysis I've
> read on the subject.  (Not trying to be ironic.)  In general, this
> list (sad to say - now I'm being ironic :-) represents the species'
> hoard of knowledge on certain topics.
>
> Where I grew up in the U.S. mid-Atlantic states, the most obvious
> effect of DST was to extend the usable hours of daylight for Summer
> evenings.  (Perhaps some other narrative applies at higher or lower
> latitudes?)  Since we were off school, the morning issues were
> meaningless.  And workers go to work when their bosses tell them to.
> The time they own for themselves and their families is after work.
>
> Recently, all discussions of DST are framed in turns of energy.  It
> seems like every argument for DST (saves energy for lighting in the
> mornings) is countered by some argument against (increases cooling
> costs in the evenings).  If DST were really a mechanism for managing
> our natural daylight resource, rather than a naive attempt at PR
> regarding petroleum resources, it would be applied in the Winter when
> the daylight is in shortest supply.
>
Most of us  have long suspected that this notion of DST saving energy is 
bollocks, and now we have proof:
http://www2.bren.ucsb.edu/~kotchen/links/DSTpaper.pdf  Lucky for Congress 
that this paper didn't come out until after the decision was made to extend 
DST. (Because, you know, that worked so well during the Ford 
administration...)


Brian


From seaman at noao.edu  Tue Jan  6 15:52:04 2009
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 6 Jan 2009 13:52:04 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090105.172605.-1782455306.imp@bsdimp.com>
	<798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
	<05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu>
	<4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu>
	<alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>
Message-ID: <CC851808-C190-47B2-8846-DDF8244AF668@noao.edu>

Tony Finch wrote:

> I think for "real time" you mean "local civil time", and for "civil  
> time"
> you mean "atomic time".

Not precisely, but that's the gist.

> In the future that role would be taken by atomic time. Yes it won't  
> trivially relate to any kind
> of local time at any place on earth, like UTC and GMT, but that  
> isn't what we need it for.

This is the part I disagree with.  "Global civil time" (the underlying  
timescale for the numerous local civil time variants) needs to be  
stationary with respect to mean solar time.  The requirements for  
civil timekeeping are much broader than the technological issues (that  
we're all tediously familiar with).

Rob


From adi at stav.org.il  Tue Jan  6 16:35:19 2009
From: adi at stav.org.il (Adi Stav)
Date: Tue, 6 Jan 2009 23:35:19 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
References: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
Message-ID: <20090106213519.GK6161@stav.org.il>

Thank you for the discussion so far.

On Mon, Jan 05, 2009 at 04:31:44PM -0700, Rob Seaman wrote:
> Adi Stav wrote:
>
>> what problems could exceeding the tolerance(s) cause?
>
> Well covered in the archive.  For astronomy, 1 second of time is 15  
> seconds of arc on the equator.  This is a large error (colossal for some 
> purposes).  It doesn't appear that any other industry has actually 
> performed a coherent risk analysis.  For some reason this is asserted to 
> be the astronomers' responsibility.

Right. Well, both my memory of the archives and M. Warner Losh's summary
have uses that need to be aware of UT (actually, I think local sidereal
time, or ET in some cases, so that have to perform conversions either
way). I was referring, rather to issues with civil time having a large DUT. 

I am trying to identify a requirement for civil time having a low (say,
below 30 minutes) DUT. So far, I can think of the common legacy of legal 
time being mean solar time at some longitude, but that's about it.

>> (Especially problems that time zones far from their reference  
>> meridians, DST switches twice a year, and the difference between mean 
>> and apparent solar time don't already cause).
>
> This confuses periodic with secular effects, also in the archive.

A secural effect will eventually cause infinite DUT by definition. 
That's why I started with a question regarding a concrete bound on DUT.
Unless you mean that with any concrete bound on DUT, intercalation will
become more and more frequent? Or I miss your point again?

>> A good parallel would be adding leap hours and using the existing DST 
>> mechanism
>
> Reasons why leap hours won't work are in the archive.  There was a clear 
> consensus from both sides of the aisle that the notion of leap hours is 
> absurd.  Alternately, by relying on shifting timezones, there would be no 
> underlying stabilized civil timescale permitting commonsense timekeeping 
> inferences by humans.

I said I don't think it's a good idea necessarily, only that it is the
parallel of the Gregorian reform.

But what do you think about my suggestion of phasing the time standard 
every few centuries when the standard's DUT reaches 30 minutes? Won't it 
make leap hours workable?

>> I don't understand :)
>
> Imagine a version of the Gregorian calendar that interpolates leap days 
> only every 400 hundred years.  That would amount to about 3 months at a 
> time.  Since this is a whole season, it is equivalent to not stabilizing 
> the calendar at all.
>
> Leap hours or tweaking timezones can be interpreted the same way.  If  
> intercalary adjustments are the width of a timezone, no practical  
> stabilization is occurring.

Ah, I see. (Although, of course, half an hour or an hour in a day is much 
less harmful than a season in a year.)

From adi at stav.org.il  Tue Jan  6 16:40:43 2009
From: adi at stav.org.il (Adi Stav)
Date: Tue, 6 Jan 2009 23:40:43 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
Message-ID: <20090106214043.GM6161@stav.org.il>

On Sun, Jan 04, 2009 at 08:58:29PM -0700, Rob Seaman wrote:
> Here's a notion I don't recall seeing before on the list:
>
> Coordinate leap seconds with leap days.  Introduce an integral number of 
> leap seconds each February 29th.  Discuss.

February 29th does not start and end all over the world at the same
time. Some time zones will get the leap during the 28th, others in March
the 1st.

Another suggestion in the same vain: standardize all the time zones of
the world to two specific dates for starting and ending DST (if they use 
it). Add leap seconds at one of those dates only.

From nimh at pipe.nl  Tue Jan  6 17:31:52 2009
From: nimh at pipe.nl (Nero Imhard)
Date: Tue, 6 Jan 2009 23:31:52 +0100
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106213519.GK6161@stav.org.il>
References: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090106213519.GK6161@stav.org.il>
Message-ID: <69091203-17DE-40C7-918A-953E34863ECA@pipe.nl>


On 2009-01-06, at 22:35, Adi Stav wrote:
> I am trying to identify a requirement for civil time having a low  
> (say,
> below 30 minutes) DUT.

I would say that the actual requirement is for DUT to stay within a  
small interval. Of course this also implies a low DUT, but debating  
the need for a low magnitude tends obscure the real issue: the size of  
the interval within which DUT is allowed to wander.

The assertion has been made that DUT could grow to 30 minutes or even  
an hour just fine because people also tolerate not living exactly on  
the central meridian of their time zone and also cope with DST.

I believe this to be false. People's tolerance for being some fixed  
time offset (modulo 1 DST hour) away from their "time meridian" has  
nothing to do with their tolerance for this value to drift.

N

From tvb at LeapSecond.com  Tue Jan  6 17:34:55 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Tue, 6 Jan 2009 14:34:55 -0800
Subject: [LEAPSECS] Reliability
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu><20090105.172605.-1782455306.imp@bsdimp.com><798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu><alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk><05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu><4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu><alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>
	<CC851808-C190-47B2-8846-DDF8244AF668@noao.edu>
Message-ID: <2C081EA5682D48218D085ECA2E2D6023@pc52>

> This is the part I disagree with.  "Global civil time" (the underlying  
> timescale for the numerous local civil time variants) needs to be  
> stationary with respect to mean solar time.  The requirements for  

Rob,

A problem is what defines your "stationary" (what bandwidth)
and what defines "mean" (what averaging time). Or, another
way to put it, why in your opinion, are leap seconds OK but
leap tenth-seconds, or leap minutes, or leap hours not OK?
Each of these preserve, to one degree or another, the notion
of stationary wrt solar time.

/tvb


From seaman at noao.edu  Tue Jan  6 17:56:56 2009
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 6 Jan 2009 15:56:56 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106214043.GM6161@stav.org.il>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090106214043.GM6161@stav.org.il>
Message-ID: <36E042E0-52AA-4067-9D94-054C72565B0C@noao.edu>

Adi Stav wrote:

> Rob Seaman wrote:
>>
>
>> Coordinate leap seconds with leap days.  Introduce an integral  
>> number of leap seconds each February 29th.  Discuss.
>
> February 29th does not start and end all over the world at the same  
> time.

This is no different than the end of December or June.  In fact, the  
current standard already permits leap seconds to be issued at the end  
of February, and that would sometimes mean February 29th.

> Some time zones will get the leap during the 28th, others in March  
> the 1st.

The leap occurs at midnight UTC on 30 June or 31 December.  These  
dates apply west of Greenwich, e.g., we saw the leap second in Tucson  
at 5 pm on New Years Eve.  East of Greenwich it is already the morning  
of 1 July or 1 January when the leap second occurs.

Confusion doesn't happen near the IDL since it is just before noon on  
the first day of the month on one side of the line or just after noon  
on the last day of the preceding month on the other side.

So just as with all the other months (and all are currently  
permissible), the leap second occurs in all localities on the last day  
of one month or the first day of the next.  It never occurs on day N-1.

I don't think any of this affects the interpretation of the word  
"coordinate".  It does, perhaps, emphasize that intercalary  
corrections to the calendar are made in coordination with our clocks  
(29 February begins at 0h local time).  And it should emphasize that  
intercalary corrections to our clocks have to be made in coordination  
with our calendar (1231T235960Z or 0630T235960Z).

The civil clock is a subdivision of the civil calendar.

Rob

From adi at stav.org.il  Wed Jan  7 01:31:15 2009
From: adi at stav.org.il (Adi Stav)
Date: Wed, 7 Jan 2009 08:31:15 +0200
Subject: [LEAPSECS] Reliability
In-Reply-To: <69091203-17DE-40C7-918A-953E34863ECA@pipe.nl>
References: <27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090106213519.GK6161@stav.org.il>
	<69091203-17DE-40C7-918A-953E34863ECA@pipe.nl>
Message-ID: <20090107063115.GP6161@stav.org.il>

On Tue, Jan 06, 2009 at 11:31:52PM +0100, Nero Imhard wrote:
>
> I believe this to be false. People's tolerance for being some fixed time 
> offset (modulo 1 DST hour) away from their "time meridian" has nothing to 
> do with their tolerance for this value to drift.

I see. And how would such intolerance come into effect? The little old
lady who will eventally walk to church in the dark on winter Sundays has
been suggested, but that was rather tongue-in-cheek :)

I'd say the little old lady's tolerance for maximum drifting DUT is no 
less than a minute or two, because her watch isn't that accurate anyhow
and she sets it from time to time.

From clive at davros.org  Wed Jan  7 04:08:35 2009
From: clive at davros.org (Clive D.W. Feather)
Date: Wed, 7 Jan 2009 09:08:35 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <36E042E0-52AA-4067-9D94-054C72565B0C@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090106214043.GM6161@stav.org.il>
	<36E042E0-52AA-4067-9D94-054C72565B0C@noao.edu>
Message-ID: <20090107090835.GV60802@davros.org>

Rob Seaman said:
> The leap occurs at midnight UTC on 30 June or 31 December.  These  
> dates apply west of Greenwich, e.g., we saw the leap second in Tucson  
> at 5 pm on New Years Eve.  East of Greenwich it is already the morning  
> of 1 July or 1 January when the leap second occurs.

I know what you're trying to say, but I'm several hundred metres east of
Greenwich and I saw the leap second on 31 December, not 1 January.

Which is one more point on the "don't care about mean solar time" side.

> Confusion doesn't happen near the IDL since it is just before noon on  
> the first day of the month on one side of the line or just after noon  
> on the last day of the preceding month on the other side.

Except New Zealand is, I believe, in zone +13 at this time of year. So it
was 12:59:60 on 1 January.

-- 
Clive D.W. Feather     | If you lie to the compiler,
clive at davros.org       | it will get its revenge.
http://www.davros.org  |   - Henry Spencer

From dan at tobias.name  Wed Jan  7 09:01:24 2009
From: dan at tobias.name (Daniel R. Tobias)
Date: Wed, 07 Jan 2009 09:01:24 -0500
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>,
	<798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>,
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
Message-ID: <49646F64.11204.119174AE@dan.tobias.name>

On 6 Jan 2009 at 10:12, Tony Finch wrote:

> Note that there's no need for global co-ordination. Each country (or
> county) can change when it is convenient for them. The effect would
> probably be a shifting of timezone boundaries in lumps and bumps that
> averages out to the overall DUT1 drift.

...thus ending up with a time zone map even more chaotic and 
convoluted and ever-changing than the current one, something I 
wouldn't have thought to be possible.

And after a few millennia, UTC will actually be a complete day or 
more removed from the local civil time in any place.  This will be 
very confusing in places like Wikipedia comment signature datestamps, 
which use UTC.  (Wikipedia edit histories also use UTC by default, 
but can be configured by users to display in their preferred time 
zone.)

Also in a few millennia, when the need to alter the Gregorian 
calendar to correct for alignment with the seasons comes up, that 
will open the question of whether such calendar alterations apply to 
UTC, to local time systems, or both.  The keepers of UTC as a strict 
atomic time standard will undoubtedly oppose any alteration to its 
calendar rules, but if the local time zones are still officially 
based on it (even if shifted by an offset of multiple days by then) 
then it wouldn't make sense to change the calendar rules for them but 
not UTC, so another big fight on whatever the equivalent of Internet 
mailing lists is in that era will be anticipated.

-- 
== 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  Wed Jan  7 08:37:45 2009
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 7 Jan 2009 06:37:45 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106213519.GK6161@stav.org.il>
References: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090106213519.GK6161@stav.org.il>
Message-ID: <E45806DB-D27E-46E2-87EE-1735486B95A9@noao.edu>

Adi Stav wrote:

> But what do you think about my suggestion of phasing the time standard
> every few centuries when the standard's DUT reaches 30 minutes?  
> Won't it make leap hours workable?

I suspect that none of the factions will welcome repeated  
redefinitions of a fundamental standard.

Rob


From seaman at noao.edu  Wed Jan  7 10:13:42 2009
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 7 Jan 2009 08:13:42 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <2C081EA5682D48218D085ECA2E2D6023@pc52>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu><20090105.172605.-1782455306.imp@bsdimp.com><798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu><alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk><05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu><4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu><alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>
	<CC851808-C190-47B2-8846-DDF8244AF668@noao.edu>
	<2C081EA5682D48218D085ECA2E2D6023@pc52>
Message-ID: <E4E12486-CAF4-4362-AE6E-56F05EAAADAC@noao.edu>

Tom Van Baak wrote:

> why in your opinion, are leap seconds OK but leap tenth-seconds, or  
> leap minutes, or leap hours not OK?  Each of these preserve, to one  
> degree or another, the notion of stationary wrt solar time.

I'll refrain from references to current practice.  We often get  
tangled in assertion of "you can't do that!"

I would say that a leap tenth-second or leap minute are within the  
bounds of possibility simply based on size.  A leap hour is far too  
big a jump.  The point of intercalation is to make a succession of  
changes which are individually of small enough amplitude to be ignored  
(or, at least, ignorable).

The latency between intercalation events must be short enough to  
permit smoothing over historical periods - say, a few decades.  Too  
short is also not good.  I think tenth-second events would be needed  
too frequently.  Clearly some here believe one-second intercalation  
events occur too frequently :-)

On the other hand, permitting a long delay between events - or rather,  
between scheduling opportunities for events - risks losing the  
corporate knowledge to handle the events properly.  Others here  
believe leap seconds are already demonstrating that :-)

One great benefit of leap seconds is that there is a simple mechanism  
for introducing them into the flow of time marks.  (The original  
design is pretty clever, actually.)  A leap minute would likely be  
added as an additional last minute to the UTC day, basically 60  
straight leap seconds.

I suppose a leap tenth-second would correspond to a slightly longer  
final second to a day.  One advantage of this is that (for the next  
few hundred years) a rigid schedule could be instituted.  Something  
like add (or subtract) an integral number of tenth-seconds each and  
every 31 December.  The schedule remains fixed, the amplitude varies.  
This has similarities to the various timeslicing schemes that were  
mentioned - oh - five years into the discussion.

There are prior posts on why it would be very difficult to interpose  
an additional hour, basically because hours are individually tagged in  
each time zone, whereas each minute can cleanly add a 60th second and  
each hour a 60th minute.  That is, in Greenwich the leap hour could be  
a 25th hour, but in Tucson it would fall between the end of the 17th  
and the beginning of the 18th hours.  (Among other logistical issues.)

So, with the caveat that I really do believe that we should be  
focusing on collecting requirements to characterize the problem,  
rather than speculating on possible solutions, here is a score card:

leap tenth-seconds:
	small amplitude (too small?  some might see these as rubber seconds)
	too frequent operationally?
	not so infrequent we could ignore them
	split-second mechanism needed to implement

leap seconds
	small amplitude
	marginally too frequent (meaning people obviously disagree)
	marginally too infrequent (to force programmers to handle correctly :-)
	mechanism already deployed (obviously people disagree :-)

leap minutes
	marginally acceptable amplitude (for some purposes, DUT1 would have  
to adapt)
	not frequent enough operationally (but not outside the bounds of  
reality)
	too infrequent to maintain corporate knowledge
	mechanism possible

leap hours
	unacceptable amplitude (waayy unacceptable)
	not frequent enough operationally (by any interpretation)
	too infrequent (whole civilizations would come and go)
	mechanism is impossible

Like I said, if the alternative is the ITU giving up on civil  
timekeeping entirely, we can likely reach some sort of consensus to  
extend scheduling based on a relaxed approximation of some sort.

My personal preference is either to maintain the current status quo  
(although extending the schedule without relaxing DUT1 should also be  
possible) OR to redesign the system entirely from the ground up, eg.,  
Steve Allen's zoneinfo concept.

There clearly is resistance to admitting that there are two different  
underlying concepts of civil timekeeping that must both be honored.   
Embracing this will be the quickest way to reach a new equilibrium.

Rob

From imp at bsdimp.com  Wed Jan  7 10:45:09 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed, 07 Jan 2009 08:45:09 -0700 (MST)
Subject: [LEAPSECS] Reliability
In-Reply-To: <49646F64.11204.119174AE@dan.tobias.name>
References: <798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
	<49646F64.11204.119174AE@dan.tobias.name>
Message-ID: <20090107.084509.-1975970201.imp@bsdimp.com>

In message: <49646F64.11204.119174AE at dan.tobias.name>
            "Daniel R. Tobias" <dan at tobias.name> writes:
: On 6 Jan 2009 at 10:12, Tony Finch wrote:
: 
: > Note that there's no need for global co-ordination. Each country (or
: > county) can change when it is convenient for them. The effect would
: > probably be a shifting of timezone boundaries in lumps and bumps that
: > averages out to the overall DUT1 drift.
: 
: ...thus ending up with a time zone map even more chaotic and 
: convoluted and ever-changing than the current one, something I 
: wouldn't have thought to be possible.
: 
: And after a few millennia, UTC will actually be a complete day or 
: more removed from the local civil time in any place.  This will be 
: very confusing in places like Wikipedia comment signature datestamps, 
: which use UTC.  (Wikipedia edit histories also use UTC by default, 
: but can be configured by users to display in their preferred time 
: zone.)

Where a few is like 6 or 7.  See
http://www.ucolick.org/~sla/leapsecs/dutc.html for the timelines on
that.  In 5000BC mankind was a collection of hunter gathers that was
just learning how to farm.  The Pyramids of Giza, for example, were
built around 2500BC.  The earliest known hieroglyphics appear around
3200BC in pre-dynastic Egypt.  It has been pointed out that we've also
accelerated the rate of technology, so the next 7k years are going to
see way more development than the last 7k.  I don't think anybody can
make any meaningful predictions out 7k years.  After all, Wikipedia
has only been around 7, so worrying about what it will be like in 7k
years seems a bit premature or presumptuous.

: Also in a few millennia, when the need to alter the Gregorian 
: calendar to correct for alignment with the seasons comes up, that 
: will open the question of whether such calendar alterations apply to 
: UTC, to local time systems, or both.  The keepers of UTC as a strict 
: atomic time standard will undoubtedly oppose any alteration to its 
: calendar rules, but if the local time zones are still officially 
: based on it (even if shifted by an offset of multiple days by then) 
: then it wouldn't make sense to change the calendar rules for them but 
: not UTC, so another big fight on whatever the equivalent of Internet 
: mailing lists is in that era will be anticipated.

The error rate for the Gregorian calendar is like 1 day in 4k years,
so it will take a very long time for enough error to accumulate that
people will want to do something.  There have been proposals to make
years ending in 4000 not be leap years to correct, but nothing
official has happened on this yet.  The Gregorian calendar has a
tolerance of about +/- just over a day, so equinox varies between
20-dec at 20:47UT and 23-dec at 0:18 UT.

Warner

From seaman at noao.edu  Wed Jan  7 11:05:53 2009
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 7 Jan 2009 09:05:53 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090107.084509.-1975970201.imp@bsdimp.com>
References: <798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu>
	<alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk>
	<49646F64.11204.119174AE@dan.tobias.name>
	<20090107.084509.-1975970201.imp@bsdimp.com>
Message-ID: <A1C85F84-721E-445A-97A4-F4C8EB638839@noao.edu>

M. Warner Losh wrote:

> I don't think anybody can make any meaningful predictions out 7k  
> years.

The Sun will still shine.  The Earth will still spin.  Lunar tides  
will continue their billion year trend.  A solar second will be  
incrementally a bit longer yet than an SI second.

If humans still exist, they will remain very similar anatomically and  
physiologically to the Cro Magnons of 50,000 years ago.  Either we  
will have restrained our darker selves and preserved the environment -  
or we won't.  I would suggest that either way our great^N  
grandchildren will care more about diurnal rhythms, rather than less.

Meanwhile, computing devices in the 91st century are not likely to  
suffer from the ills of POSIX.  Even SI units may not still exist.   
The simple fact of the existence of multiple kinds of timekeeping  
standards won't throw our big domed overlords into a tizzy:

	http://www.ufomystic.com/wp-content/uploads/outerlimits_os_05.jpg

Work to improve the infrastructure we have, not degrade the  
fundamental standards underlying the infrastructure.  If UTC doesn't  
do what you want, use GPS and leave universal time to the people who  
use it and like it.

Rob


From dot at dotat.at  Wed Jan  7 13:58:29 2009
From: dot at dotat.at (Tony Finch)
Date: Wed, 7 Jan 2009 18:58:29 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106214043.GM6161@stav.org.il>
References: <5665ECCE-78A5-47A4-BAD0-51CF88852096@noao.edu>
	<alpine.LSU.2.00.0901021840540.26975@hermes-1.csi.cam.ac.uk>
	<2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090106214043.GM6161@stav.org.il>
Message-ID: <alpine.LSU.2.00.0901071856510.7820@hermes-1.csi.cam.ac.uk>

On Tue, 6 Jan 2009, Adi Stav wrote:
>
> Another suggestion in the same vain: standardize all the time zones of
> the world to two specific dates for starting and ending DST (if they use
> it). Add leap seconds at one of those dates only.

That would require the period of DST to be exactly half the year, so that
the north and south get the same amount of it. However DST is usually
applied for more than half the year.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: VARIABLE 3 OR 4 BECOMING SOUTHERLY 5 TO 7 THEN
VEERING WESTERLY. MODERATE OR ROUGH. OCCASIONAL SNOW THEN RAIN. MODERATE OR
GOOD, OCCASIONALLY POOR AT FIRST.

From dot at dotat.at  Wed Jan  7 14:01:07 2009
From: dot at dotat.at (Tony Finch)
Date: Wed, 7 Jan 2009 19:01:07 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <20090106213519.GK6161@stav.org.il>
References: <ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<20090106213519.GK6161@stav.org.il>
Message-ID: <alpine.LSU.2.00.0901071859080.7820@hermes-1.csi.cam.ac.uk>

On Tue, 6 Jan 2009, Adi Stav wrote:
>
> Right. Well, both my memory of the archives and M. Warner Losh's summary
> have uses that need to be aware of UT (actually, I think local sidereal
> time, or ET in some cases, so that have to perform conversions either
> way).

No-one uses ET any more. It has been replaced by TT (which is based on
atomic time).

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: VARIABLE 3 OR 4 BECOMING SOUTHERLY 5 TO 7 THEN
VEERING WESTERLY. MODERATE OR ROUGH. OCCASIONAL SNOW THEN RAIN. MODERATE OR
GOOD, OCCASIONALLY POOR AT FIRST.

From dot at dotat.at  Wed Jan  7 14:09:21 2009
From: dot at dotat.at (Tony Finch)
Date: Wed, 7 Jan 2009 19:09:21 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
Message-ID: <alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>

On Mon, 5 Jan 2009, Rob Seaman wrote:
>
> Alternately, by relying on shifting timezones, there would be no
> underlying stabilized civil timescale permitting commonsense timekeeping
> inferences by humans.

What do you mean by "stabilized" here? Atomic time is the basis of our
most stable time scales. I don't think perturbing a timescale to follow
the erratic slow-down of the earth can reasonably be called "stabilizing"
it.

What common-sense inferences do you have in mind? Most common sense is
wrong, especially when it comes to time.

> Imagine a version of the Gregorian calendar that interpolates leap days
> only every 400 hundred years.  That would amount to about 3 months at a
> time. Since this is a whole season, it is equivalent to not stabilizing
> the calendar at all.
>
> Leap hours or tweaking timezones can be interpreted the same way.

Not really. An hour in a day is more like a couple of weeks in a year, not
three months. Two weeks is less than the variability caused by intercalary
months in lunisolar calendars.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
BISCAY SOUTHEAST FITZROY: NORTHEASTERLY 4 OR 5, INCREASING 6 AT TIMES.
MODERATE, OCCASIONALLY ROUGH IN SOUTHEAST FITZROY. MAINLY FAIR. MAINLY GOOD.

From dot at dotat.at  Wed Jan  7 14:33:07 2009
From: dot at dotat.at (Tony Finch)
Date: Wed, 7 Jan 2009 19:33:07 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <E4E12486-CAF4-4362-AE6E-56F05EAAADAC@noao.edu>
References: <11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu><20090105210508.GI6161@stav.org.il><AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu><20090105.172605.-1782455306.imp@bsdimp.com><798D75D5-7226-40A1-A820-4AFD282E3442@noao.edu><alpine.LSU.2.00.0901061000490.8944@hermes-1.csi.cam.ac.uk><05F51331-0556-4931-A4C0-23A57EE4E386@noao.edu><4BB507FB-7ED0-431D-AD54-E9B0D12FDFF7@noao.edu><alpine.LSU.2.00.0901061713380.10002@hermes-1.csi.cam.ac.uk>
	<CC851808-C190-47B2-8846-DDF8244AF668@noao.edu>
	<2C081EA5682D48218D085ECA2E2D6023@pc52>
	<E4E12486-CAF4-4362-AE6E-56F05EAAADAC@noao.edu>
Message-ID: <alpine.LSU.2.00.0901071929250.7820@hermes-1.csi.cam.ac.uk>

On Wed, 7 Jan 2009, Rob Seaman wrote:
>
> On the other hand, permitting a long delay between events - or rather,
> between scheduling opportunities for events - risks losing the corporate
> knowledge to handle the events properly.

The good thing about timezones is the code to implement them and alter
them is exercised all the time.

> One great benefit of leap seconds is that there is a simple mechanism for
> introducing them into the flow of time marks.

So simple it usually doesn't work!

> There clearly is resistance to admitting that there are two different
> underlying concepts of civil timekeeping that must both be honored.
> Embracing this will be the quickest way to reach a new equilibrium.

Just treat UT as another timezone offset from TI, alongside all the other
earth-oriented timezones.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
NORTHWEST FITZROY SOLE: EASTERLY OR SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6 LATER
IN WEST. MODERATE, OCCASIONALLY ROUGH LATER IN WEST. MAINLY FAIR. MAINLY GOOD.

From phk at phk.freebsd.dk  Wed Jan  7 14:35:49 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 07 Jan 2009 19:35:49 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: Your message of "Wed, 07 Jan 2009 19:33:07 GMT."
	<alpine.LSU.2.00.0901071929250.7820@hermes-1.csi.cam.ac.uk> 
Message-ID: <4356.1231356949@critter.freebsd.dk>

In message <alpine.LSU.2.00.0901071929250.7820 at hermes-1.csi.cam.ac.uk>, Tony Fi
nch writes:
>On Wed, 7 Jan 2009, Rob Seaman wrote:
>>
>> On the other hand, permitting a long delay between events - or rather,
>> between scheduling opportunities for events - risks losing the corporate
>> knowledge to handle the events properly.
>
>The good thing about timezones is the code to implement them and alter
>them is exercised all the time.

...and that politicians who are too enthusiatically mucking about with them,
will face the consequences, by the (voting) hands of the affected electorate.

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  Wed Jan  7 16:00:01 2009
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 7 Jan 2009 14:00:01 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>
Message-ID: <3451EBFE-8B1A-4479-ABB5-B7AFC01AD551@noao.edu>

Tony Finch wrote:

> What do you mean by "stabilized" here? Atomic time is the basis of  
> our most stable time scales. I don't think perturbing a timescale to  
> follow the erratic slow-down of the earth can reasonably be called  
> "stabilizing" it.

Civil timekeeping (the underlying global timescale that ties all our  
local timescales together into a unified whole) has requirements  
derived from two parent classes - interval timekeeping and Earth  
orientation timekeeping.  In the absence of a full blown rubber second  
implementation, the Earth orientation part of that requires tempering  
to optimize (or perhaps more accurately, satisfice) its utility.

(I could venture into a paean to Ernst Mach and point out that to  
flatlanders living on Earth it is the motions of the celestial sphere  
that are erratic, but I will restrain myself :-)

I've been trying on different terms for this tempering, for instance,  
keeping civil timekeeping "stationary" with respect to diurnal  
trends.  One could compare this (loosely) to the notion of  
"disciplining" a clock as in NTP.

The term "stabilization" I borrowed from work I've been doing with  
numerical compression algorithms for scientific imaging data with a  
Poisson noise model, as in the "generalized Anscombe variance  
stabilization" transform.

Precisely because the Earth's motions are erratic, they benefit from  
enforcing a clock discipline that keeps an arbitrary zero point (some  
shrubbery in the park surrounding the Greenwich Observatory)  
stationary in phase through an arbitrary number of cycles.

> What common-sense inferences do you have in mind?

Simple utilitarian inferences regarding the world around us.

> Most common sense is wrong, especially when it comes to time.

Reference to some study supporting this assertion?  Humans make  
decisions based on mental models.  Those models and the resulting  
decisions do not have to be vetted against quantum chromodynamics or  
magneto-hydrodynamics to be deemed "right".  Again, I'll recommend  
Steven Pinker's book "The Stuff of Thought" for a discussion of the  
basis of an inherent model of physics contained in the structure of  
human language.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20090107/e197c148/attachment.htm>

From dot at dotat.at  Thu Jan  8 14:42:07 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 8 Jan 2009 19:42:07 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <3451EBFE-8B1A-4479-ABB5-B7AFC01AD551@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>
	<3451EBFE-8B1A-4479-ABB5-B7AFC01AD551@noao.edu>
Message-ID: <alpine.LSU.2.00.0901081939311.7820@hermes-1.csi.cam.ac.uk>

On Wed, 7 Jan 2009, Rob Seaman wrote:
>
> > What common-sense inferences do you have in mind?
>
> Simple utilitarian inferences regarding the world around us.

Such as? I can't think of anything simple enough to count as common sense
which depends on the relation between UT1 and the various local times.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH: EAST VEERING SOUTHEAST 3 OR 4, OCCASIONALLY 5
EXCEPT IN DOVER. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

From seaman at noao.edu  Thu Jan  8 15:30:08 2009
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 8 Jan 2009 13:30:08 -0700
Subject: [LEAPSECS] Reliability
In-Reply-To: <alpine.LSU.2.00.0901081939311.7820@hermes-1.csi.cam.ac.uk>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>
	<3451EBFE-8B1A-4479-ABB5-B7AFC01AD551@noao.edu>
	<alpine.LSU.2.00.0901081939311.7820@hermes-1.csi.cam.ac.uk>
Message-ID: <9E704261-8D01-412D-AD74-8D91100D11A9@noao.edu>

Tony Finch wrote:

> Such as? I can't think of anything simple enough to count as common  
> sense
> which depends on the relation between UT1 and the various local times.


As with most issues discussed on this list, questions need to be  
framed properly before they can be addressed.

The key role that UTC plays in framing the "simple utilitarian  
inferences regarding the world around us" that I mentioned is as a  
prediction of UT1.  UT1 itself is only known retroactively.

Similarly, UTC (and GPS) provide access to TAI, which we have been  
informed time and again is some mystical perfect timescale unsuitable  
for use by mere humans.  (Or rather, it isn't UTC per se, but the  
various realizations of UTC that provide dual access to interval and  
Earth orientation timescales.)

Universally (to use that word metaphorically yet again), we do not use  
the "various local times" to compute or intuit global assertions about  
our world.  Which is to say, we may observe that the Sun is up or down  
at some particular moment, but to predict the behavior tomorrow we  
always tie into Universal Time in some fashion.

Currently access to UTC is automatically supplied (for both simple and  
complex utilitarian purposes) because it is built into the system of  
standard time zones.

The ITU proposal would sunder this.  Yes, we could cheat some of the  
purposes some of the time, and some other purposes all of the time,  
but most definitely not all of the purposes forever.

The real answer to "I can't think of" queries is to point out that  
these are explicit pleas to engage in a process of requirement  
discovery.  Neither God nor science reside in the gaps of our  
imagination.

Rob


From dot at dotat.at  Fri Jan  9 11:02:25 2009
From: dot at dotat.at (Tony Finch)
Date: Fri, 9 Jan 2009 16:02:25 +0000
Subject: [LEAPSECS] Reliability
In-Reply-To: <9E704261-8D01-412D-AD74-8D91100D11A9@noao.edu>
References: <2EDED853-A26C-4FD7-B444-E2135969325B@noao.edu>
	<20090104094438.GD6161@stav.org.il>
	<ABA4F1CB-ED30-448E-9F12-0AF2A4AE5C28@noao.edu>
	<20090104211501.GE6161@stav.org.il>
	<27EDF481-1216-49B9-ACD3-26FFEB1CA82F@noao.edu>
	<4975F35B-47C9-4069-8559-565B3AEBA04B@noao.edu>
	<43EF13B7-AF2E-4286-ACEE-425C88FC9D81@noao.edu>
	<53CB0FCE-23A1-4E12-92CD-A977F38F5103@noao.edu>
	<20090105143227.GG6161@stav.org.il>
	<11278DD0-1C14-43BD-AFBF-27C8A731A9D7@noao.edu>
	<20090105210508.GI6161@stav.org.il>
	<AE6C787C-1725-48CB-BBA8-4A1BBE06DDEB@noao.edu>
	<alpine.LSU.2.00.0901071903430.7820@hermes-1.csi.cam.ac.uk>
	<3451EBFE-8B1A-4479-ABB5-B7AFC01AD551@noao.edu>
	<alpine.LSU.2.00.0901081939311.7820@hermes-1.csi.cam.ac.uk>
	<9E704261-8D01-412D-AD74-8D91100D11A9@noao.edu>
Message-ID: <alpine.LSU.2.00.0901091601520.7820@hermes-1.csi.cam.ac.uk>

On Thu, 8 Jan 2009, Rob Seaman wrote:
>
> The key role that UTC plays in framing the "simple utilitarian inferences
> regarding the world around us" that I mentioned is as a prediction of UT1.
> UT1 itself is only known retroactively.

I still don't know what these inferences are.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
SOUTH UTSIRE: WEST 4 OR 5 BACKING SOUTH 5 TO 7, PERHAPS GALE 8 LATER. MODERATE
OR ROUGH. MAINLY FAIR. MODERATE OR GOOD.