Re: [LEAPSECS] Coming of age in the solar system

2010-09-03 Thread M. Warner Losh
In message: <6c773408-836c-4d2a-9d37-0a8b7111e...@noao.edu>
Rob Seaman  writes:
: I've just realized that the archive for the early years of this list
: is offline, otherwise I'd be pointing to discussions about how leap
: seconds are just an issue of representation, about how atomic time
: (an unending sequence of ticks) shouldn't be using sexagesimal at
: all, and about why the SI unit of time should really never have been
: called the "second" in the first place.

And I'd be pointing to those same discussions where actual
practitioners discuss the difficulty in the phrase "just an issue of
representation."  Conceptually it is easy, but so many people get it
wrong, and international standards make it impossible to get it
right.  There's both too much automation in leap seconds, and not
enough.  Nobody cares enough to solve the whole problem, and 'success'
in the software world sadly seems to be defined as 'didn't panic the
OS and eventually it sorted itself out' rather than 'got the time
right around a leap second.'

I've said many times: leap seconds happen to unpredictably to be on
the radar of most people.  They happen too suddenly to always get the
budget they need (nobody likes a mid-year surprise that there will be
a leap second next quarter, so your carefully laid plans go awry).

If they were on a regular schedule, where on the average we tried for
a |DUT1| < 10s, (or 5s or whatever) we'd have a better chance of
getting them right.  Managers would know when to schedule time,
testers would know they could test not just one leap second, but maybe
5 or 10 leap seconds to make sure the software worked.  Software
products could get a longer shelf life.  Sadly, there's no serious
discussion of this middle ground outside of this list.

Of course, it would be cheaper for the software folks to never have to
worry about it again.  That would also make them predictable.

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


Re: [LEAPSECS] Coming of age in the solar system

2010-09-03 Thread Rob Seaman
The flip side of timekeeping on a spinning pebble skipping through the cosmos 
is that nothing prevents *also* benefitting from an atomic timescale devoid of 
the dreaded irregular radix.

Civil time = mean solar time
Techie time = atomic clock ensemble

Have your cake and eat it, too!

...although one wouldn't think that a bunch of poindexters who can build an 
ensemble of atomic clocks out of second-hand flux capacitors and 
scratch-and-dent dilithium crystals would be thrown into a tizzy by any radix, 
irregular or not.

I've just realized that the archive for the early years of this list is 
offline, otherwise I'd be pointing to discussions about how leap seconds are 
just an issue of representation, about how atomic time (an unending sequence of 
ticks) shouldn't be using sexagesimal at all, and about why the SI unit of time 
should really never have been called the "second" in the first place.

Rob
--

On Sep 3, 2010, at 9:03 PM, M. Warner Losh wrote:

> In message: <9ff72199-4479-43a4-b988-516e5336e...@noao.edu>
>Rob Seaman  writes:
> : Q: Why was the SI second chosen such that 24x60x60 of them fit into one 
> solar day?
> : A: Because everybody else keeps time by the Sun - sexagesimally since the 
> Sumerians.
> 
> Except on leap second day, when the sexagesimalliness breaks with an
> irregular radix.  In effect, the proposal to stop inserting leap
> seconds restores this invariant that goes back to the Sumerians by
> eliminating the irregular radix :)
> 
> Warner

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] Coming of age in the solar system

2010-09-03 Thread Michael Sokolov
M. Warner Losh  wrote:

> Except on leap second day, when the sexagesimalliness breaks with an
> irregular radix.

Yup, that's why I seriously dislike leap seconds and prefer rubber
seconds instead.  (By the latter I mean something like Marcus Kuhn's
UTS aka UTC-SLS.)

> In effect, the proposal to stop inserting leap
> seconds restores this invariant that goes back to the Sumerians by
> eliminating the irregular radix :)

Except that the cure (disconnecting the concept of a day from the
sunrise/sunset cycle) is worse than the disease (the leap second
silliness).  Rubber seconds a la UTS/UTC-SLS eliminate the 23:59:60
insanity *without* killing mean solar time.

But at least with the darned leap seconds my time_t disagrees with UTC
"legal time" only during the short interval during which I make my
time_t clock advance by 10 units over the course of 11 SI seconds; if
ITU has their way, I and the world will set out on a course of ever-
increasing time drift.

(That is, at the present time I schedule a batch of 10 elongated seconds,
each equal to 1.1 SI s in duration, at the same time when Daniel Gambis
schedules a leap second.  But I am fully prepared to do it on my own:
when the evil ITU comes forward to take away Monsieur Gambis' authority
to issue leap seconds, I will NOT bend over like a submissive and switch
to living my life on a timescale that's decoupled from MST.  Instead I
will simply start scheduling elongated or perhaps shortened time_t
seconds on my non-POSIX UNIX systems on my own, and still live my life
on a timescale that is anchored to MST.)

Goddess Bless,
MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] Coming of age in the solar system

2010-09-03 Thread Rob Seaman
I meant to credit Timothy Ferris for the borrowed subject line:  


http://www.harpercollins.com/books/Coming-Age-Milky-Way-Timothy-Ferris/?isbn=9780060535957

Apologies!

On Sep 3, 2010, at 5:55 PM, Rob Seaman wrote:

> Q: How long is one Earth day?
> A: The sidereal rotation period of the Earth is 86164 SI seconds (23h56m4s).
> 
> Q: Why was the SI second not specified to be 86164/86400 as long to make this 
> come out an even 24 hours?
> A: Because only those who study the stars need to keep time by them.
> 
> Q: Why was the SI second chosen such that 24x60x60 of them fit into one solar 
> day?
> A: Because everybody else keeps time by the Sun - sexagesimally since the 
> Sumerians.
> 
> One "day" doesn't mean one day by the stars.  One day is one day by the Sun - 
> that is, "one mean solar day".  A day is indeed the sidereal period of the 
> Earth, simply adjusted to subtract off one rotation/year due to our lapping 
> the Sun.
> 
> Q: How many days are in one Earth year?
> A: Having circled the Sun, the Earth will have rotated 366.25 times:
> 
>   24(60)(60)/86164 x 365.25 = 365.25 + 1
> 
> All this talk of the political vagaries of DST offsets or of the apparent 
> wanderings of the Sun in the sky (the Earth is tilted and its orbit is 
> elliptical) are red herrings.  They confuse modest periodic effects with the 
> unbounded secular (monotonic and accelerating) effect that ceasing leap 
> seconds would cause.  By seeking to redefine UTC, the ITU is mucking with the 
> definition of the word "day".  I don't see how this is within the purview of 
> the International Telecommunications Union.
> 
> Warner asks:
>   Q: "And why does MEAN solar time matter more than ACTUAL solar time?"
>   Q: "And what flavor of MEAN solar time is best?"
>   Q: "What does solar time mean on mars, the moon, etc?"
> 
> A: Mean solar time (ignoring legal tap dancing on the head of a pin about the 
> definition of "GMT") matters because it *is* "actual" solar time.  It has not 
> previously mattered what flavor - the ITU is "breaking the symmetry" of UTC 
> and GMT.  What humans have already done during trips to Mars and to the Moon 
> is to structure mission operations in concert with local sunrise and sunset.  
> Presumably the equation of time on other solar system bodies will be taken 
> into account just as on Earth.  It is not as if the ITU has a coherent plan 
> for timekeeping needs on the other planets any more so than they do on Earth. 
>  
> 
>   ITU = flat-earthers
> 
> Civil timekeeping is based on mean solar time because our clocks are 
> fractional representations of the calendar.  The only reason the ITU is able 
> to contemplate this cheat of redefining UTC (originally defined as the 
> "general equivalent" of GMT) is because the rate of atomic clocks was chosen 
> to be very similar to the canonical rate of solar clocks.  It was chosen to 
> be similar to our ubiquitous solar clocks because civil timekeeping was 
> recognized to be equivalent to mean solar time.
> 
> Clocks go round and round - and so do we.
> 
> Rob Seaman
> National Optical Astronomy Observatory
> --
> 
> "It cannot be that axioms established by argumentation can suffice for the 
> discovery of new works, since the subtlety of nature is greater many times 
> than the subtlety of argument."
> - Sir Francis Bacon
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] Coming of age in the solar system

2010-09-03 Thread M. Warner Losh
In message: <9ff72199-4479-43a4-b988-516e5336e...@noao.edu>
Rob Seaman  writes:
: Q: Why was the SI second chosen such that 24x60x60 of them fit into one solar 
day?
: A: Because everybody else keeps time by the Sun - sexagesimally since the 
Sumerians.

Except on leap second day, when the sexagesimalliness breaks with an
irregular radix.  In effect, the proposal to stop inserting leap
seconds restores this invariant that goes back to the Sumerians by
eliminating the irregular radix :)

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


[LEAPSECS] Coming of age in the solar system

2010-09-03 Thread Rob Seaman
Q: How long is one Earth day?
A: The sidereal rotation period of the Earth is 86164 SI seconds (23h56m4s).

Q: Why was the SI second not specified to be 86164/86400 as long to make this 
come out an even 24 hours?
A: Because only those who study the stars need to keep time by them.

Q: Why was the SI second chosen such that 24x60x60 of them fit into one solar 
day?
A: Because everybody else keeps time by the Sun - sexagesimally since the 
Sumerians.

One "day" doesn't mean one day by the stars.  One day is one day by the Sun - 
that is, "one mean solar day".  A day is indeed the sidereal period of the 
Earth, simply adjusted to subtract off one rotation/year due to our lapping the 
Sun.

Q: How many days are in one Earth year?
A: Having circled the Sun, the Earth will have rotated 366.25 times:

24(60)(60)/86164 x 365.25 = 365.25 + 1

All this talk of the political vagaries of DST offsets or of the apparent 
wanderings of the Sun in the sky (the Earth is tilted and its orbit is 
elliptical) are red herrings.  They confuse modest periodic effects with the 
unbounded secular (monotonic and accelerating) effect that ceasing leap seconds 
would cause.  By seeking to redefine UTC, the ITU is mucking with the 
definition of the word "day".  I don't see how this is within the purview of 
the International Telecommunications Union.

Warner asks:
   Q: "And why does MEAN solar time matter more than ACTUAL solar time?"
   Q: "And what flavor of MEAN solar time is best?"
   Q: "What does solar time mean on mars, the moon, etc?"

A: Mean solar time (ignoring legal tap dancing on the head of a pin about the 
definition of "GMT") matters because it *is* "actual" solar time.  It has not 
previously mattered what flavor - the ITU is "breaking the symmetry" of UTC and 
GMT.  What humans have already done during trips to Mars and to the Moon is to 
structure mission operations in concert with local sunrise and sunset.  
Presumably the equation of time on other solar system bodies will be taken into 
account just as on Earth.  It is not as if the ITU has a coherent plan for 
timekeeping needs on the other planets any more so than they do on Earth.  

ITU = flat-earthers

Civil timekeeping is based on mean solar time because our clocks are fractional 
representations of the calendar.  The only reason the ITU is able to 
contemplate this cheat of redefining UTC (originally defined as the "general 
equivalent" of GMT) is because the rate of atomic clocks was chosen to be very 
similar to the canonical rate of solar clocks.  It was chosen to be similar to 
our ubiquitous solar clocks because civil timekeeping was recognized to be 
equivalent to mean solar time.

Clocks go round and round - and so do we.

Rob Seaman
National Optical Astronomy Observatory
--

"It cannot be that axioms established by argumentation can suffice for the 
discovery of new works, since the subtlety of nature is greater many times than 
the subtlety of argument."
- Sir Francis Bacon
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Tony Finch
On 3 Sep 2010, at 21:02, Nero Imhard  wrote:
> 
> But indeed DST has its own costly problems. The burden of moving all clocks 
> twice a year, made worse because every microwave and refrigerator comes with 
> its own clock these days (none of which are self-setting of course), falls on 
> the shoulders of the entire population, a significant part of which is 
> becoming quite fed up with the practice.

But it is also extremely popular. People would be more comfortable counting 
time from sunrise rather than noon, but to do so would be even more 
inconvenient than dealing with east-west differences in mean solar time. So 
instead DST gives us a very rough and arbitrary approximation to the ideal. 
(What is ideal for astronomers is not for everyday usage.)

Tony.
--
f.anthony.n.finchhttp://dotat.at/
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On 3 Sep 2010, at 22:14, Rob Seaman  wrote:

> Greenwich Mean Time is the Mean Solar Time in Greenwich.  Is this its 
> "historical astronomical meaning"?  Or is this its "definition"?

The former, because in current usage it is a synonym for UTC (which I do not 
regard as an astronomical timescale, though you can reasonably argue otherwise 
if your required precision is 1 - 10 seconds).

Tony.
--
f.anthony.n.finchhttp://dotat.at/
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Rob Seaman
On Sep 3, 2010, at 12:19 PM, M. Warner Losh wrote:

> I think that this is why the leap second proposals say they won't
> disseminate DUT1 anymore.  All they really mean by that, I think, is
> that we'll measure it, we'll pubish it, but the time broadcasts will
> reset it to '0' and users should note that it isn't available that way
> anymore.

There are no "leap second proposals" - plural - there's just the insipid TF.460 
redefinition being maneuvered behind closed doors through the byzantine ITU 
bureaucracy.

If both supporters and conscientious objectors are using words like "I think" 
it means the proposal isn't clear in its intent.  Why is that?

Either the legalistic document - or some publicly accessible gloss on same - 
should be clear enough to understand the issues and intent of the changes - 
that is, should comprise a coherent systems engineering plan.

Rob

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Ian Batten


On 3 Sep 2010, at 20:19, M. Warner Losh wrote:


I think that this is why the leap second proposals say they won't
disseminate DUT1 anymore.  All they really mean by that, I think, is
that we'll measure it, we'll pubish it, but the time broadcasts will
reset it to '0' and users should note that it isn't available that way
anymore.


I suspect that system that are consuming DUT1 are not exactly at the  
thrusting forefront of modern development.   So a piece of equipment  
that consumes DUT1 from MSF (and we can only speculate about what that  
equipment might be) could be of an arbitrary age, and could well be  
operating on autopilot with several iterations (or even generations)  
of staff having passed.   I don't know when the current format was  
agreed , but Wikipedia implies 1967.


So "users should note" is an interesting concept.  Firstly, it's not  
clear how you'd tell them: even BBC1 running idents saying "Next,  
Eastenders, but first an announcement for people who have equipment  
that consumes DUT1" may not work, as people may not realise the  
equipment they're using is included.  And secondly, as it's most  
likely that equipment is consuming DUT1 to do something astro-y,  
rather than just displaying for decoration, even if people can be  
told, quite what are they expected to do about it?


Secondly, there may be systems that don't bother to process DUT1, but  
nonetheless rely on its being <1s.For example, astro-navigation is  
still taught, and I suspect that although 1s doesn't matter, 10s might  
(someone who's used a sextant in anger can tell us the precisions that  
are normal).   Obviously, the correction can be supplied out of band,  
but all those mechanisms will need to be set up.


ian

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Rob Seaman
Greenwich Mean Time is the Mean Solar Time in Greenwich.  Is this its 
"historical astronomical meaning"?  Or is this its "definition"?
--
On Sep 3, 2010, at 10:49 AM, Tony Finch wrote:

> On Fri, 3 Sep 2010, Rob Seaman wrote:
>> On Sep 3, 2010, at 2:18 AM, Tony Finch wrote:
>> 
>>> If you are syncing to what is now called "GMT" you are syncing to UTC
>>> because they are now in practice exact synonyms.
>> 
>> And this is precisely what the ITU is planning to break.
> 
> I'm not sure that's true. The only de jure definition of GMT is "civil
> time in the UK in winter". The British government and its agencies
> currently implement GMT as equivalent to UTC. If the ITU change the
> definition of GMT, and if the British government continues to follow ITU
> recommendations and to disregard the historical astronomical meaning of
> GMT, then the equivalence will continue.
> 
> Tony.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread M. Warner Losh
In message: <1009032024.aa04...@ivan.harhan.org>
msoko...@ivan.harhan.org (Michael Sokolov) writes:
: * From what I understand the 4.4BSD-derived BSD systems have
:   switched to using the "posix" versions of the Olson tz files.

It is still an option to use the "right" versions of the files, but as
you say, there's a number of issues with that, so the default on
FreeBSD is to use the posix versions.

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


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Michael Sokolov
Ian Batten  wrote:

> I have a dim memory, based on wrestling with one of the *BSD's NTP  
> implementation in the mid 1990s, that one Unix decided to tick TAI  
> rather than UTC and move leap-seconds into userspace.  But it's all  
> very dim...

Olson's tz implementation did that at an early point in its history.
Timeline of its adoption in BSD-land:

* 4.3BSD-Tahoe had one of the earliest versions of the tz library which
  did not concern itself with such things.  (I.e., it still ran on a
  vague "GMT" rather than anything more precisely defined like UTC or
  TAI.)  That's what my current 4.3BSD-Quasijarus systems have, although
  I don't really use the tz part of it: I always run everything with
  "localtime" set to GMT (like in the headers of this E-mail).

* By 4.4BSD time the Olson library had developed the infamous "posix"
  and "right" files.  4.4BSD shipped with the "right" config by default,
  so indeed it attempted to run the kernel on TAI and do the leap
  seconds in userland.  The problem with that approach is that if the
  user/sysadmin never updates the leap second table (e.g., ignorant of
  its existence) and sets the system time from a wall clock via the date
  command, the resutling kernel time will be something in between TAI
  and UTC, more like UTC shifted by some constant offset corresponding
  to the # of leap seconds at the time of the OS release.

* From what I understand the 4.4BSD-derived BSD systems have
  switched to using the "posix" versions of the Olson tz files.

MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Nero Imhard
Warner,

On 2010-09-03, at 20:04, M. Warner Losh wrote:

> : The difference doesn't matter, the fact that the difference is constant 
> does.
> 
> I'm asking these question: Why does it matter so much?

Because UTC was defined this way. Staying close to UT was its very design goal 
and is its main defining property. That's the only point, in fact.

If people, countries, scientists, etc. choose between time scales, we have to 
assume the choice is deliberate, and, by necessity, based on the properties of 
these time scales. 

> What does
> keeping things in sync buy you that merely measuring the difference
> and knowing that number doesn't?

I don't know. I don't have to. It's irrelevant to the debate. It all depends on 
your requirements. These dictate your choice of time scale.

If governments (through whatever agencies) decide that civil time is better off 
referring to another time scale (one that's uniform and lacks leap seconds) I 
guess that would be entirely reasonable. Personally I think it would be a pity 
*but that is irrelevant*. If civil time is based on another time scale, and 
radio time signals stop disseminating UTC, I'll have to get it from elsewhere 
if I really need it. Bummer. I'll cope.

But the one thing I vehemently oppose is having to accommodate a change in an 
existing definition, and having to cope with the semantic confusion that will 
arise from it. I'll feel insulted and become frustrated, maybe even enraged, by 
such irresponsible behaviour from (what I had assumed was) some kind of 
standards body.

> Why must UTC be used as the method
> to synchronize "noon and the sun is approx overhead" when we have wide
> timezones that already do that function?  Does the cost of
> synchronizing to UTC exceed the benefits from synchronizing there and
> not at a different, easier to change level?

Maybe not. Again, it all depends on your requirements. In the "UTC debate" I 
guess it's up to the legislators, who need a notion of official time.

> Given the changes in how
> time is used, propagated, etc, in the last 20, 50 or 100 years, does
> it make sense to reevaluate things?

Yes. Of course. By all means, reevaluate and decide if UTC still meets your 
needs.

> Those are the questions I'm asking...

Now the one you're not asking, which is at the core of the ITU/UTC-issue as I 
see it (and I'm quoting myself here):

[is it] appropriate/ethical/allowed to change the definition of a widely used 
existing time scale in mid-flight rather than construct new or use existing 
time scales according to whatever requirements you may have (and others may not 
have)?

THAT is the question I keep asking.

> Oh, and with Daylight Savings Time, the difference isn't even constant
> anymore.

Well, DST has more to do with civil time than UTC. But indeed DST has its own 
costly problems. The burden of moving all clocks twice a year, made worse 
because every microwave and refrigerator comes with its own clock these days 
(none of which are self-setting of course), falls on the shoulders of the 
entire population, a significant part of which is becoming quite fed up with 
the practice. If the ITU wants to do something useful, they start lobbying 
against DST. And I'm quite serious here.

> And why does MEAN solar time matter more than ACTUAL solar
> time?  And what flavor of MEAN solar time is best?  What does solar
> time mean on mars, the moon, etc?

Irrelevant questions. The one central to the debate stays: why on earth 
redefine an existing time scale? (and I always feel like adding "are you out of 
your mind??")

I have the feeling that I'm repeating myself (like so many of the people here) 
and that we're going in circles. This is what I wrote to you almost exactly a 
year ago:

Valid points are being raised about leap seconds being royal PITAs for the
purposes of the ITU, and it is only reasonable that they want to get rid
of them.

But I'm quite disappointed that the question on the table continues to be
"should UTC abandon leap seconds?", while the relevant question is "should
the ITU stop using/broadcasting a time scale that is causing trouble?".

I'm worried that this hasn't even been considered by WP7A.

Decoupling UTC and UT isn't [even] wrong in a way related to ITU's actual 
problem
(which makes the whole thing so disturbing); it's wrong in itself.

I honestly don't believe that over the last year, anyone has addressed this, 
let alone has begun to convince me that ITU's proposal isn't too silly to even 
discuss (were it not for the fact that they are actually pushing it).

shaking my head in disbelief and dismay...

Nero


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread M. Warner Losh
In message: <7a21eaec-bb0a-4966-a8db-86b084df0...@batten.eu.org>
Ian Batten  writes:
: > do we
: > have enough of a community of |DUT1| < 1s to justify the costs to the
: > rest of the world, or is it time that this crowd shoulder the costs of
: > the raw data they need?
: 
: Of course, one issue is that it's not a matter of |DUT1|<1s, but
: having DUT1 at all.  The formats by which DUT1 is propagated in time
: signals deeply assume <1, so if it became >1 it couldn't be propagated
: in those signals.  Which means that any and all equipment that
: consumes it is instantly broken, as it can't recover UT1.  Even if the
: format could accommodate >1, of course, one assumes that almost all
: sane implementations would sanity check the value of DUT1 to confirm
: it's <1, so would reject the larger value anyway.
: 
: You could modify the format, but you'd have to do so in a way which
: didn't then break all the equipment that wants UTC but pokes around in
: the extra data to recover the date, or the summer time indicator, or
: whatever.  And it would involve replacing all the UT1 equipment
: anyway.
: 
: I don't know, and I suspect the ITU don't either, how much (if,
: indeed, there is any) equipment is currently consuming the DUT1
: portion of the national time standards, and why.

I think that this is why the leap second proposals say they won't
disseminate DUT1 anymore.  All they really mean by that, I think, is
that we'll measure it, we'll pubish it, but the time broadcasts will
reset it to '0' and users should note that it isn't available that way
anymore.

I lump all the gear that (a) needs to know about it and (b) does
something with it in the same boat.  There is a danger here, however
if the (b) is display it to the user who then doesn't know that
something is amiss and believes '0'.

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


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 11

2010-09-03 Thread Tom Van Baak

Does someone capture and archive these amazing discussions?  Pardon
silly questions from a newcomer.


Please see:

http://six.pairlist.net/mailman/listinfo/leapsecs

For archives prior to 2007 contact me offline.

Thanks,
/tvb
www.LeapSecond.com


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Joseph S. Myers
On Thu, 2 Sep 2010, M. Warner Losh wrote:

> In message: <722f0d89-cbfa-423a-9c9e-6d919ded9...@batten.eu.org>
> Ian Batten  writes:
> : >
> : > I'd wager that UTC, whatever its realization, would likely trump any
> : > locally written laws.
> : 
> : It'll be interesting in the UK
> : 
> : * There's no doubt that UK legal time is GMT, Interpretation Act 1978,
> : * S.9
> : 
> : *  There's no doubt that whatever GMT is, it's solar, and there's no
> : *  doubt that whatever UTC is, it isn't solar and would be even less
> : *  solar without leap seconds,
> : 
> : * There's no doubt that proposed legislation to change UK legal time to
> : * UTC failed to be passed in 1997, and an extensive history of the issue
> : * got read into Hansard.
> : 
> : You'd have a hell of a job showing UK time was UTC in the face of
> : that.
> 
> Do you have references to case law that confirms this interpretation?

I see no reason the principle from Curtis v. March (1858) 3 H & N 866 that 
"Neither can the time be altered by a railway company whose railway passes 
through the place, nor by any person who regulates the clock in the 
town-hall." would not apply today to say that the time is as specified by 
law and not by those who set time signals, although that part of the 
judgment may not be binding precedent.  I have previously here noted 
Miller v. Community Links Trust Ltd (UKEAT/0486/07) as evidence that a 
nine-second time difference (between legal time and time signals) would be 
sufficient to be litigated.

http://www.uakron.edu/law/lawreview/v36/docs/parrish36.1.pdf

(previously discussed on this list in December 2006) makes interesting 
reading for those concerned with how courts might rule if there were 
differences between de facto and de jure time; it's certainly not a 
foregone conclusion either way.

-- 
Joseph S. Myers
j...@polyomino.org.uk
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 11

2010-09-03 Thread Finkleman, Dave
Does someone capture and archive these amazing discussions?  Pardon
silly questions from a newcomer.

This kind of knowledgeable exchange is what the ITU is missing.  There
are sound technical reasons for retaining or dispensing with the leap
second.  They need to be exposed, and the proponent of each should
consider what others would have to do in order to accommodate an
alternative.  This discussion thread does that but only to a small
audience of geeks.  

To reveal my bias, if the situation is this arguable, why change
anything?  We conjecture that whatever the cost or inconvenience of
living with the leap second, the costs and difficulties of deprecating
the leap second might be greater.  It is most a matter of who pays the
bill.

Dave Finkleman
Senior Scientist
Center for Space Standards and Innovation
Analytical Graphics, Inc.
7150 Campus Drive
Colorado Springs, CO 80920
 
Phone:  719-510-8282 or 719-321-4780
Fax:  719-573-9079
 
Discover CSSI data downloads, technical webinars, publications, and
outreach events at www.CenterForSpace.com.
-Original Message-
From: leapsecs-boun...@leapsecond.com
[mailto:leapsecs-boun...@leapsecond.com] On Behalf Of
leapsecs-requ...@leapsecond.com
Sent: Friday, September 03, 2010 1:01 PM
To: leapsecs@leapsecond.com
Subject: LEAPSECS Digest, Vol 45, Issue 11

Send LEAPSECS mailing list submissions to
leapsecs@leapsecond.com

To subscribe or unsubscribe via the World Wide Web, visit
http://six.pairlist.net/mailman/listinfo/leapsecs
or, via email, send a message with subject or body 'help' to
leapsecs-requ...@leapsecond.com

You can reach the person managing the list at
leapsecs-ow...@leapsecond.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of LEAPSECS digest..."


Today's Topics:

   1. Re: h2g2 (Nero Imhard)
   2. Re: LEAPSECS Digest, Vol 45, Issue 1 (Tony Finch)
   3. Re: LEAPSECS Digest, Vol 45, Issue 1 (Tony Finch)
   4. Re: h2g2 (M. Warner Losh)
   5. Re: h2g2 (Michael Sokolov)
   6. Re: h2g2 (Ian Batten)
   7. Re: LEAPSECS Digest, Vol 45, Issue 1 (Poul-Henning Kamp)
   8. Re: h2g2 (Paul Sheer)


--

Message: 1
Date: Fri, 3 Sep 2010 19:37:37 +0200
From: Nero Imhard 
Subject: Re: [LEAPSECS] h2g2
To: Leap Second Discussion List 
Message-ID: <67efec27-33c2-4d35-a48f-f7be2ed7d...@pipe.nl>
Content-Type: text/plain; charset=us-ascii


On 2010-09-03, at 15:56, p...@2038bug.com wrote:

>> on the SAME time.  Nobody cares here that solar time and civil time
>> are 43 minutes off. 
> 
> *I* care 

Warner seems to be missing (or ignoring?) the point.

The difference doesn't matter, the fact that the difference is constant
does.

N



--

Message: 2
Date: Fri, 3 Sep 2010 18:49:29 +0100
From: Tony Finch 
Subject: Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1
To: Leap Second Discussion List 
Message-ID:

Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Sep 2010, Rob Seaman wrote:
> On Sep 3, 2010, at 2:18 AM, Tony Finch wrote:
>
> > If you are syncing to what is now called "GMT" you are syncing to
UTC
> > because they are now in practice exact synonyms.
>
> And this is precisely what the ITU is planning to break.

I'm not sure that's true. The only de jure definition of GMT is "civil
time in the UK in winter". The British government and its agencies
currently implement GMT as equivalent to UTC. If the ITU change the
definition of GMT, and if the British government continues to follow ITU
recommendations and to disregard the historical astronomical meaning of
GMT, then the equivalence will continue.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5
TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE
OR
ROUGH. RAIN THEN FAIR. GOOD.


--

Message: 3
Date: Fri, 3 Sep 2010 19:06:34 +0100
From: Tony Finch 
Subject: Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1
To: Leap Second Discussion List 
Message-ID:

Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Sep 2010, Zefram wrote:

> Tony Finch wrote:
> >As we have seen there are a lot of intricate
> >details whose necessity people can legitimately disagree about and no
way
> >to determine an official consensus. Which is why I say that
astronomical
> >GMT doesn't exist.
>
> Interesting argument.  I disagree with your central point: I don't
> think an official realisation of GMT is required in order for GMT to
> meaningfully exist.

Note that in the above I'm talking about astronomical GMT. There is an
official realisation of legal GMT, and it is UTC. If you create a new
astronomical timescale it would be wrong to claim it is GMT. GMT(Zefram)
is probably OK though :-)

> Making a clear distinction between ideal and realisation smells like
> modern behaviour; considering the many different

Re: [LEAPSECS] h2g2

2010-09-03 Thread Paul Sheer


> I really liked your earlier idea of setting up an NTP server that would
> serve a smooth, variable-rate timescale like UT1 or UTS or UTC-SLS, and
> have an associated pledge to continue serving this form of Earth-following
> time regardless of what the ITU does to UTC.  I am thinking along very
> similar lines myself.

really, it would be a bit of a gimmick

if you are serious though and implement some server and client
softare - I'd be happy to host the downloads and deploy on
2038bug.com


> But as long as you and I continue to operate our own law-defiant NTP
> servers which serve our realization of Earth time instead of the s**t
> that ITU peddles, those nature-loving people who wish to live their
> personal lives on mean solar time can simply choose to point their own
> ntpd instances at our servers instead of those following the ITU -
> problem solved.

well the number of user's we are likely to accrue would be
small - most people that use NTP need their servers to stay
within a few milliseconds of everyone else - that is *why*
they use NTP.

-paul




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Poul-Henning Kamp
In message , Tony F
inch writes:

>If the ITU change the
>definition of GMT, and if the British government continues to follow ITU
>recommendations and to disregard the historical astronomical meaning of
>GMT, then the equivalence will continue.

Just to highlight how laughable the retroimperialist love for GMT is:

Which exact meridian are we talking about again ?

Are we talking about the meridian Airy drew through his telescope or
the one we actually use, about 100m east of his telescope ?

Did anybody in England gather an orderly mob around GMT, to protect
its imperial virginity, when the WGS84 redefinition of the geodesic
origo changed it by five and a half second ?

Let me remind you that WGS84 _also_ redefined UTC.

Can we please drop this nonsense now ?

Or at least queue it, where it belongs, behind the still pending
tax-refund for the 12 missing days in september 1752 ?

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Ian Batten

do we
have enough of a community of |DUT1| < 1s to justify the costs to the
rest of the world, or is it time that this crowd shoulder the costs of
the raw data they need?


Of course, one issue is that it's not a matter of |DUT1|<1s, but  
having DUT1 at all.  The formats by which DUT1 is propagated in time  
signals deeply assume <1, so if it became >1 it couldn't be propagated  
in those signals.   Which means that any and all equipment that  
consumes it is instantly broken, as it can't recover UT1.  Even if the  
format could accommodate >1, of course, one assumes that almost all  
sane implementations would sanity check the value of DUT1 to confirm  
it's <1, so would reject the larger value anyway.


You could modify the format, but you'd have to do so in a way which  
didn't then break all the equipment that wants UTC but pokes around in  
the extra data to recover the date, or the summer time indicator, or  
whatever.  And it would involve replacing all the UT1 equipment anyway.


I don't know, and I suspect the ITU don't either, how much (if,  
indeed, there is any) equipment is currently consuming the DUT1  
portion of the national time standards, and why.


ian

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Michael Sokolov
p...@2038bug.com wrote:

> > Nobody cares here that solar time and civil time
> > are 43 minutes off. 
>
> *I* care 

I do too!

> but I'm not important - I'm just one person 

There are TWO of us now!

> many people might care and many people are not getting to make
> the decision because the decision is being made for them. 

That is why I am making preparations for generating my own synthetic
time scale that is steered to serve a realization of MST, contingency
plans for the day when we may no longer be able to depend on Daniel
Gambis to do it for us.

I really liked your earlier idea of setting up an NTP server that would
serve a smooth, variable-rate timescale like UT1 or UTS or UTC-SLS, and
have an associated pledge to continue serving this form of Earth-following
time regardless of what the ITU does to UTC.  I am thinking along very
similar lines myself.

> further, it's not a decision we can *ever* go back on once it is
> made because reversing back to solar to time would be politically
> far too difficult to get collaboration on. 

But as long as you and I continue to operate our own law-defiant NTP
servers which serve our realization of Earth time instead of the s**t
that ITU peddles, those nature-loving people who wish to live their
personal lives on mean solar time can simply choose to point their own
ntpd instances at our servers instead of those following the ITU -
problem solved.

Furthermore, there are still quite a few countries left on Earth whose
system of rulership is very non-Western.  Perhaps we can convince Raul
Castro or Hugo Chavez to use MST instead of ITU time as the basis of
legal time in Cuba or Venezuela, and to take their time reference from
our "rebel" NTP servers?  Or perhaps we can team with the folks in the
Arab world who are working on the Mecca Time idea?

I would be very willing to work with *anyone* who is in favor of
Earth-anchored time.

> that some NASA/ITU/whoever people find leap seconds "inconvenient"
> for programmers is NOT sufficient reason to ever have started
> pursuing this agenda. 

Total agreement!

MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread M. Warner Losh
In message: <67efec27-33c2-4d35-a48f-f7be2ed7d...@pipe.nl>
Nero Imhard  writes:
: 
: On 2010-09-03, at 15:56, p...@2038bug.com wrote:
: 
: >> on the SAME time.  Nobody cares here that solar time and civil time
: >> are 43 minutes off. 
: > 
: > *I* care 
: 
: Warner seems to be missing (or ignoring?) the point.
: 
: The difference doesn't matter, the fact that the difference is constant does.

I'm asking these question: Why does it matter so much?  What does
keeping things in sync buy you that merely measuring the difference
and knowing that number doesn't?  Why must UTC be used as the method
to synchronize "noon and the sun is approx overhead" when we have wide
timezones that already do that function?  Does the cost of
synchronizing to UTC exceed the benefits from synchronizing there and
not at a different, easier to change level?  Given the changes in how
time is used, propagated, etc, in the last 20, 50 or 100 years, does
it make sense to reevaluate things?

We've undergone a fairy radical paradigm shift in how time is used and
consumed in the past 20 years.  Doesn't it make sense to reevaluate
the system to make sure those items that used to be no big deal but
have become big cost items still fit the needs of the majority of the
users?  Time was when there were hundreds of different fields that
relied on having good time to know where they were (navigators,
surveyors, etc), but with GPS eliminating those users of UTC, do we
have enough of a community of |DUT1| < 1s to justify the costs to the
rest of the world, or is it time that this crowd shoulder the costs of
the raw data they need?

Those are the questions I'm asking...

Oh, and with Daylight Savings Time, the difference isn't even constant
anymore.  And why does MEAN solar time matter more than ACTUAL solar
time?  And what flavor of MEAN solar time is best?  What does solar
time mean on mars, the moon, etc?

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


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On Fri, 3 Sep 2010, Zefram wrote:

> Tony Finch wrote:
> >As we have seen there are a lot of intricate
> >details whose necessity people can legitimately disagree about and no way
> >to determine an official consensus. Which is why I say that astronomical
> >GMT doesn't exist.
>
> Interesting argument.  I disagree with your central point: I don't
> think an official realisation of GMT is required in order for GMT to
> meaningfully exist.

Note that in the above I'm talking about astronomical GMT. There is an
official realisation of legal GMT, and it is UTC. If you create a new
astronomical timescale it would be wrong to claim it is GMT. GMT(Zefram)
is probably OK though :-)

> Making a clear distinction between ideal and realisation smells like
> modern behaviour; considering the many different meanings of "GMT" that
> have already been identified, I would not be surprised at it being
> irretrievably ambiguous in this respect.

Yes, definitely. I'm stretching when I claim that the practical realities
of time in the UK are enough to unambiguously define GMT == UTC
(obviously, or we wouldn't be having this discussion).

> Does anyone have relevant historical documentation on the philosophical
> definition of GMT?

This is brief and sketchy:
http://www.nmm.ac.uk/explore/astronomy-and-time/astronomy-facts/history/the-longitude-of-greenwich

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On Fri, 3 Sep 2010, Rob Seaman wrote:
> On Sep 3, 2010, at 2:18 AM, Tony Finch wrote:
>
> > If you are syncing to what is now called "GMT" you are syncing to UTC
> > because they are now in practice exact synonyms.
>
> And this is precisely what the ITU is planning to break.

I'm not sure that's true. The only de jure definition of GMT is "civil
time in the UK in winter". The British government and its agencies
currently implement GMT as equivalent to UTC. If the ITU change the
definition of GMT, and if the British government continues to follow ITU
recommendations and to disregard the historical astronomical meaning of
GMT, then the equivalence will continue.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Nero Imhard

On 2010-09-03, at 15:56, p...@2038bug.com wrote:

>> on the SAME time.  Nobody cares here that solar time and civil time
>> are 43 minutes off. 
> 
> *I* care 

Warner seems to be missing (or ignoring?) the point.

The difference doesn't matter, the fact that the difference is constant does.

N

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Paul Sheer
> : 
> : *I* care 
> : 
> : but I'm not important - I'm just one person 
> 
> So do you live [...]

here we have dst

> You are already [...]

agreed

> 
> : many people might care and many people are not getting to make
> : the decision because the decision is being made for them. 
> 
> That decision was made in the last half of the nineteenth century:
> Standard time already decoupled local solar time from the time that
> the clocks read.

and leap seconds helps it keep up

> 
> : further, it's not a decision we can *ever* go back on once it is
> : made because reversing back to solar to time would be politically
> : far too difficult to get collaboration on. 
> 
> Yes, but why do you care?

Why? Simple:

leap seconds are not a serious problem - just an inconveniance.

we can stop leap seconds at *any* time - what is the rush to do it in
*this* generation?

we have had proper timekeeping for less than a hundred years - a *short*
time.

we have no idea what the future will bring.

and the future is vast compared to this 100 years.

we *may* come to regret the decision for reasons we cannot foresee.

we are discovering new physics all the time - rather let a few
generations go by before we decide anything.


> 
> : therefore it is a decision that must be made very very carefully. 
> : 
> : that some NASA/ITU/whoever people find leap seconds "inconvenient"
> : for programmers is NOT sufficient reason to ever have started
> : pursuing this agenda. 
> 
> And why can't we just keep track of the accumulation for the
> relatively small number of applications that care?  Why can't we
> adjust timezones as the drift becomes larger every few hundred years
> or so?  What genuine benefit is served by keeping UTC in sync to
> England?  If corrections can be made and published, how are the
> different astronomical applications made significantly harder?


just because there appears to be no reason not to do something,
does not follow that we *must* proceed with it.


> 
> : > leap hour will ever happen, but I won't be around to see it one way or
> : > another. 
> : 
> : so really, your argument is to try convince people to only consider
> : eventualities that occur within the space of their lifetime? 
> : 
> : darwin takes care of this attitude - it's sort of guaranteed 
> 
> Listen to my argument: I'm saying that a leap hour just doesn't
> matter.  We've found a better way to keep time than the earth.  We

it may not matter now.

but not even astute students of philosophy like yourself cannot predict
in 500 years whether we may look back and regret the decision.


> bollixed up [...]

you exagerate - I've worked in *every* kind of IT environment and leap
seconds have never been a problem

> 
> But, of course, redefining the second now to make up for historical
> mistakes is out of the question. 

you don't say


> None of this has to do with my not caring about posterity. 

i can't tell if this means yes or no to you caring?


> space, and keeping time better than the Earth, it is time to question
> how absolute are our needs for this synchronization, and whether the
> complexity is generates is worth the cost it imposes.
> 

again you exagerate - it's not really a problem

i think this has more to do with certain IT people wanting to be
purists than the fact that anyone's livelyhood is materially affected.

-paul






___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Rob Seaman
On Sep 3, 2010, at 2:18 AM, Tony Finch wrote:

> If you are syncing to what is now called "GMT" you are syncing to UTC because 
> they are now in practice exact synonyms.

And this is precisely what the ITU is planning to break.  This very entrenched 
assumption will no longer be valid.

Reminds me of the lyrics to "Istanbul (not Constantinople)":

"UTC was Greenwich Mean Time
Now it's UTC, not GMT..."

Rob

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Steve Allen
On Fri 2010-09-03T17:45:34 +0100, Zefram hath writ:
> I don't think an official realisation of GMT is required in order
> for GMT to meaningfully exist.

That means it cannot be a precision time scale, for there is
no authority to define a single realization.

What the ITU-R is righly tasked to do is to specify a time scale to be
used in broadcasts, and that does need to be a precision time scale,
so that time scale needs a definition by an authority.

> Does anyone have relevant historical documentation on the philosophical
> definition of GMT?

GMT is what time it was at the RGO meridian circle as interpolated
from moment to moment by the best clock they had.
It did not exist in any form prior to 1675.
In response to the need to synchronize trans-oceanic telegraphy
and as a result of a diplomatic coup hosted by the United States
GMT became the basis for worldwide time.

The extent to which local civil time needs to be a precision time
scale is a different question, and the ITU-R has no direct authority
over that.  What we're going to see is whether the ITU-R points
jurisdictions toward a greater understanding of the need to be careful
about specifying time, or whether we are seeing another diplomatic
coup in progress.

--
Steve Allen WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99855
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Zefram
Tony Finch wrote:
>As we have seen there are a lot of intricate
>details whose necessity people can legitimately disagree about and no way
>to determine an official consensus. Which is why I say that astronomical
>GMT doesn't exist.

Interesting argument.  I disagree with your central point: I don't
think an official realisation of GMT is required in order for GMT to
meaningfully exist.  The details that need to be sorted out are indeed
problems in defining GMT, but we don't need an official decision about
which definition is the proper one.  We can perfectly well decide
for ourselves which version of GMT we are interested in, and realise
that version of GMT.  If interoperability with the historical official
realisation is important, we would want to take care to define GMT as
closely as possible to the de facto definition behind that realisation.

I think ultimately I'm perceiving GMT (or each flavour of GMT) as
a Platonic time scale, akin to TT, whereas (despite your choice of
terminology) you're perceiving it more as a realisation of a time scale,
akin to TT(TAI).  The historical official realisation of GMT no longer
exists.  You see this as meaning that GMT no longer exists, whereas I
am open to new realisations of GMT.  Making a clear distinction between
ideal and realisation smells like modern behaviour; considering the many
different meanings of "GMT" that have already been identified, I would
not be surprised at it being irretrievably ambiguous in this respect.
Does anyone have relevant historical documentation on the philosophical
definition of GMT?

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread M. Warner Losh
In message: <20100903160248.ga16...@lake.fysh.org>
Zefram  writes:
: Ian Batten wrote:
: >I have a dim memory, based on wrestling with one of the *BSD's NTP  
: >implementation in the mid 1990s, that one Unix decided to tick TAI  
: >rather than UTC and move leap-seconds into userspace.  But it's all very 
: >dim...
: 
: The Olson timezone database has some support for this.  It has a listing
: of leap seconds, which can be included into tzfiles.  The zoneinfo-right
: directory has this version of the tzfiles, whereas the zoneinfo-posix
: directory has tzfiles that do not mention leap seconds.

The code that implements these tables just reads them in once at
startup, which means programs running longer than 6 months may have
have the wrong values...  Of course, this is also true if the code is
running over a time zone change too...

: A wrinkle is the divergence of TAI and UTC prior to 1972, which cannot
: be properly modelled using leap seconds.  I understand that, as a
: result, the time_t in these systems actually depicts TAI-10s, not TAI.
: These time_t values coincide with the UTC-based POSIX time_t values for
: the first half of 1972, and in 2010 the two time_t values differ by 24.
: I've never seen such a system in operation, though, so I can't confirm
: that it works this way.

The tricky bit is keeping the tables up to date, and convincing the
kernel to do the right thing over leap seconds (which in this case is
nothing).  Also, there are hacks needed for ntp...

Such a system can be made to work, but there's a number of hurdles to
making it go 100%.

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


Re: [LEAPSECS] h2g2

2010-09-03 Thread M. Warner Losh
In message: <20100903135619.6674.qm...@protonet.co.za>
p...@2038bug.com writes:
: 
: > on the SAME time.  Nobody cares here that solar time and civil time
: > are 43 minutes off. 
: 
: *I* care 
: 
: but I'm not important - I'm just one person 

So do you live on a meridian where the solar time is within a few
seconds of the time zone?  Do you not follow daylight savings time?
You are already living at some offset to solar time that does and will
continue to dwarf any effects that accumulation of leap seconds will
have.  In my lifetime, there's been an accumulation of only 30
seconds if I read the tables right.  This is far smaller than the tens
of minutes I'm away from the meridian, and the semi-annual hourly
jumps.

: many people might care and many people are not getting to make
: the decision because the decision is being made for them. 

That decision was made in the last half of the nineteenth century:
Standard time already decoupled local solar time from the time that
the clocks read.

: further, it's not a decision we can *ever* go back on once it is
: made because reversing back to solar to time would be politically
: far too difficult to get collaboration on. 

Yes, but why do you care?

: therefore it is a decision that must be made very very carefully. 
: 
: that some NASA/ITU/whoever people find leap seconds "inconvenient"
: for programmers is NOT sufficient reason to ever have started
: pursuing this agenda. 

And why can't we just keep track of the accumulation for the
relatively small number of applications that care?  Why can't we
adjust timezones as the drift becomes larger every few hundred years
or so?  What genuine benefit is served by keeping UTC in sync to
England?  If corrections can be made and published, how are the
different astronomical applications made significantly harder?

: > leap hour will ever happen, but I won't be around to see it one way or
: > another. 
: 
: so really, your argument is to try convince people to only consider
: eventualities that occur within the space of their lifetime? 
: 
: darwin takes care of this attitude - it's sort of guaranteed 

Listen to my argument: I'm saying that a leap hour just doesn't
matter.  We've found a better way to keep time than the earth.  We
bollixed up the definition of the second to be about 2.54x10^-8
wrong.  This tiny error is why we have leaps seconds.  Had we defined
it to be 9192632003 instead of 9192631770 periods of the state
transition of Cs-133, the rate of accumulation would much smaller and
we'd only have to worry about leap seconds every decade or two.  And
we'd have the very real possibility of having both kinds of leap
seconds as the earth wobbles back and forth.

But, of course, redefining the second now to make up for historical
mistakes is out of the question.  It also is useless.  In a few
hundred years, no matter what we do, we'll have so many leap seconds
that we'll potentially have a huge problem on our hands.  The rate
will increase quadratically as the moon slows the Earth's rotation.
The long term trend is quite clear...  So eventually, leap seconds
will need to be thrown under the bus: they won't make sense anymore.

None of this has to do with my not caring about posterity.  The
reasons we tied ourselves to the earth historically is that it was (a)
the only place we cared about time and (b) the best time-keeper we had
until the middle of the last century.  Now that we're moving out into
space, and keeping time better than the Earth, it is time to question
how absolute are our needs for this synchronization, and whether the
complexity is generates is worth the cost it imposes.

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


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Zefram
Ian Batten wrote:
>I have a dim memory, based on wrestling with one of the *BSD's NTP  
>implementation in the mid 1990s, that one Unix decided to tick TAI  
>rather than UTC and move leap-seconds into userspace.  But it's all very 
>dim...

The Olson timezone database has some support for this.  It has a listing
of leap seconds, which can be included into tzfiles.  The zoneinfo-right
directory has this version of the tzfiles, whereas the zoneinfo-posix
directory has tzfiles that do not mention leap seconds.

A wrinkle is the divergence of TAI and UTC prior to 1972, which cannot
be properly modelled using leap seconds.  I understand that, as a
result, the time_t in these systems actually depicts TAI-10s, not TAI.
These time_t values coincide with the UTC-based POSIX time_t values for
the first half of 1972, and in 2010 the two time_t values differ by 24.
I've never seen such a system in operation, though, so I can't confirm
that it works this way.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Ian Batten


On 3 Sep 2010, at 15:45, p...@2038bug.com wrote:




Don't disregard ITU totally here.  ITU-T has UTC written into the
standards for cross-TelCo billing interfaces/protocols.


...all the implementations of those standards just use unix time.


I have a dim memory, based on wrestling with one of the *BSD's NTP  
implementation in the mid 1990s, that one Unix decided to tick TAI  
rather than UTC and move leap-seconds into userspace.  But it's all  
very dim...


ian

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On Fri, 3 Sep 2010, Zefram wrote:
> Tony Finch wrote:
> >Thanks for the informative explanation, but GMT is not and was not UT1.
>
> Picky, picky.  OK, let's look at the strictest sense of "GMT", taking the
> Greenwich meridian to be defined by the Royal Observatory, Greenwich,
> rather than by the ITRF.  Specifically, the 1851 meridian defined by
> Airy's transit circle, adopted as the prime meridian by the International
> Meridian Conference in 1884.

Yet more interesting stuff, thanks again!

Another thing to consider is that the last practical astronomical
realisation of GMT was carried out at Herstmonceaux not Greenwich, and
some errors were introduced when time was transferred from one to the
other which is part of the reason for the discrepancy between WGS84 and
the Airy circle. Also I understand that GMT included some corrections
similar though not identical to UT2 - see also Steve's little history he
sent yesterday which said CCIR rec. 374 required time signals to be within
100ms of UT2 between 1963 and 1970.

But this is mostly beside the point, which is that there is no
organization maintaining and promulgating an official astronomical GMT.
You could create a close approximation to an astronomical GMT but it would
have no official force. As we have seen there are a lot of intricate
details whose necessity people can legitimately disagree about and no way
to determine an official consensus. Which is why I say that astronomical
GMT doesn't exist.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread p




Don't disregard ITU totally here.  ITU-T has UTC written into the
standards for cross-TelCo billing interfaces/protocols. 



...all the implementations of those standards just use unix time. 


-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread p




on the SAME time.  Nobody cares here that solar time and civil time
are 43 minutes off. 


*I* care 

but I'm not important - I'm just one person 


many people might care and many people are not getting to make
the decision because the decision is being made for them. 


further, it's not a decision we can *ever* go back on once it is
made because reversing back to solar to time would be politically
far too difficult to get collaboration on. 

therefore it is a decision that must be made very very carefully. 


that some NASA/ITU/whoever people find leap seconds "inconvenient"
for programmers is NOT sufficient reason to ever have started
pursuing this agenda. 





leap hour will ever happen, but I won't be around to see it one way or
another. 



so really, your argument is to try convince people to only consider
eventualities that occur within the space of their lifetime? 

darwin takes care of this attitude - it's sort of guaranteed 


-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Zefram
Tony Finch wrote:
>Thanks for the informative explanation, but GMT is not and was not UT1.

Picky, picky.  OK, let's look at the strictest sense of "GMT", taking the
Greenwich meridian to be defined by the Royal Observatory, Greenwich,
rather than by the ITRF.  Specifically, the 1851 meridian defined by
Airy's transit circle, adopted as the prime meridian by the International
Meridian Conference in 1884.

A strict-GMT clock can be constructed by applying a GMT-UT1 correction
on top of the UT1 clock that I have already discussed.  This correction
corresponds to the ITRF-based longitude of the Airy meridian.  Wikipedia
gives a current value for this of -5.31 arcseconds, corresponding to
-354 ms of solar time.  (The Airy meridian is west of the ITRF meridian;
GMT is behind UT1.)

The ITRF-relative location of the ROG is gradually changing,
northeastwards, due to tectonic motion.  This increases the GMT-UT1
correction (decreasing its magnitude, because it is negative) by tens
of microseconds per annum.  This motion is much more regular and more
predictable than the fluctuations in UT1.  Presumably regular measurements
of Europe's motion can be found somewhere online, but I don't know where,
which is why I've referred to Wikipedia.  Even if not, static model
parameters would be good for many years for millisecond precision.

The next wrinkle is polar motion.  So far I've assumed that the direction
of the meridian through ROG is constant.  If you really want mean solar
time as subjectively viewed at ROG, another correction is required,
corresponding to the difference between UT0-at-ROG and UT1.  This could
be determined from Bulletin A, which projects (x, y) in addition to DUT1.
The correction is in the low tens of milliseconds.

Observation: the difference between strict GMT and UT1 is bigger than I
was really expecting, having not looked at the numbers before.  Plenty
big enough to discern on a real-time clock display.  Anyone wanting to
implement mean solar time distinct from UTC does have to decide between
UT1 and ROG-based GMT.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 4

2010-09-03 Thread Nero Imhard
Tony Finch wrote:

> The proposed redefinition of UTC is perhaps more like the redefinition of
> the yard from an independent standard of length to a multiple of the
> metre, or...

Not at all. The redefinition of UTC is not simply switching to another,
presumably more stable, static reference and sticking in a conversion
factor, as was the case with the yard, metre and second.

Historically there have been various mechanisms (rubber seconds, leap
seconds...) to synchronize civil time with solar time. These mechanisms
clearly indicate that closely following solar time is an intentional and
defining property, fully incorporated in UTC.

What the ITU proposes is not refining the synchronisation mechanism, which
would make UTC "better" (in the same way we've come up with better
definitions for yard etc.), but instead abandoning the relationship
altogether, which is much more fundamental, and would "break" UTC.

N
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On Fri, 3 Sep 2010, Zefram wrote:
> Tony Finch wrote:
> >
> >Oh, do tell, where will you get your GMT reference from?
>
> If I were doing it, I would take the DUT1 projections from IERS Bulletin
> A , interpolate between them,
> and add the resulting DUT1 onto a UTC clock that is synchronised by NTP.
> At the millisecond level this should provide a satisfactorily smooth
> approximation of UT1.

Thanks for the informative explanation, but GMT is not and was not UT1.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Zefram
Tony Finch wrote:
>On 3 Sep 2010, at 01:41, msoko...@ivan.harhan.org (Michael Sokolov) wrote:
>> I very soon will, as soon as I get my rubber time generator working.
>
>Oh, do tell, where will you get your GMT reference from?

If I were doing it, I would take the DUT1 projections from IERS Bulletin
A , interpolate between them,
and add the resulting DUT1 onto a UTC clock that is synchronised by NTP.
At the millisecond level this should provide a satisfactorily smooth
approximation of UT1.  Of course, it will not reflect any diurnal
influences on DUT1, nor any unpredictable rapid changes such as those
resulting from earthquakes.  There would also necessarily be some
discontinuity when switching from one set of projections to the next
later-produced set of projections; optionally one could paper over that
by slewing gradually between sets of projections, though this would
degrade the accuracy of the simulated UT1 frequency.

I note that in this endeavour leap seconds in UTC are a slight
inconvenience, because they result in discontinuities in DUT1.  The clock
logic would have to treat these discontinuities specially.  It would be
slightly easier if Bulletin A supplied UT1-TAI instead of UT1-UTC, and the
underlying NTP-synchronised clock supplied TAI instead of UTC.  Actually,
probably the easiest way to handle the leap second discontinuities
is to transform Bulletin A and the NTP clock into this TAI-based form.
So it's not really much more inconvenience than the difficulty of getting
a clock to tick UTC through a leap second in the first place.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Tony Finch
On 3 Sep 2010, at 05:50, Rob Seaman  wrote:

> I was referring to GMT broadly as "the astronomical timescale" and "for all 
> practical purposes" "de facto the same as UTC".

My point is that if you are being precise this is nonsense. GMT in the historic 
sense of a solar timescale does not exist any more. Your systems cannot be 
synced to solar GMT in any precise sense. If you are syncing to a solar 
timescale it will have a different name. If you are syncing to what is now 
called "GMT" you are syncing to UTC because they are now in practice exact 
synonyms.

> I believe Tony is talking narrowly about the official "Greenwich Mean Time", 
> more like http://bit.ly/cWcznJ, although it is pretty clear that the public 
> remains very much "synced" to GMT, eg, http://bit.ly/aHWJYw

Yes well the discourse in the UK about Greenwich's place in the world is pretty 
delusional. Everyone basically ignores all developments since the mid 1950s: 
Airy's instrument still determines the prime meridian etc. It's a pity because 
the truth is a lot more interesting, and if we are to understand time and place 
properly it's instructive to know why the RGO was abolished and why WGS84 (and 
for that matter the ordnance survey grid) do not align with the Airy circle.

Tony.
--
f.anthony.n.finchhttp://dotat.at/
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Rob Seaman
On Sep 3, 2010, at 1:04 AM, Ian Batten wrote:

> I have a clock ticking SI seconds at arbitrarily high precision and 
> resolution.

Examine your premises.  At some point in the past five years or so there was a 
thread discussing the distinction between clocks and timers.  I won't attempt 
to recover the subtleties of that thread at this time of night.  (Though I 
suppose the ITU would assert that my biorhythms are immaterial :-)

> How do I find out how many SI seconds I should count in order to count ten 
> UT1 seconds?  Can I determine that value prospectively, or only 
> retrospectively?


Suppose a timer to be a standalone source of ticking SI seconds.  A "clock" 
implies subjugating that timer to an external discipline such as mediated by 
NTP, for example.  Supplying a discipline from an ensemble of officially 
blessed atomic clocks is no better than applying a discipline from the wobbling 
Earth.  (The clocks may be more stable, but they are guaranteed to be shorter 
lived if nothing else :-)  In particular, constructing an ensemble timescale is 
as retrospective a task as measuring the meridian transit of fiducial stars in 
support of calculating UT1.

Here's an interesting preprint (http://arxiv.org/abs/1008.4686) with pertinence 
to the feasibility of fitting a model to data of putatively "arbitrarily high 
precision and resolution".

Rob
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Warner Losh

Remember to practice safe time transfer.  Always use rubber seconds.

Stay safe.

Warner


On Sep 3, 2010, at 1:46 AM, Rob Seaman  wrote:


And I'd point you to Steve Allen :-)

On Sep 3, 2010, at 12:44 AM, Michael Sokolov wrote:


Tony Finch  wrote:


Oh, do tell, where will you get your GMT reference from?


If I have trouble figuring it out myself, I'll just E-mail Rob Seaman
and ask him what time it is.  Given that his views on the subject as
expressed on this list are much closer to mine than, say, PHK's, I  
would

trust his answer better than ITU's.

MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] h2g2

2010-09-03 Thread Tony Finch


On 3 Sep 2010, at 04:47, "Daniel R. Tobias"  wrote:
> 
> So you'd like to end up with an even more chaotically convoluted time 
> zone map than we already have?  Eventually, there'd have to be 
> offsets from UTC of 36 or 48 hours, way beyond the theoretical +12 
> and -12 (already exceeded by a few hours in some spots) of a saner 
> time zone map.

Before 1845 the Philippines were east of the International Date Line so their 
timezone (though it wasn't called that then) was something like -16h. This 
oddity was an artefact of the 1494 Treaty of Torsedillas in which it was agreed 
that Spain got to colonize the western hemisphere and Portugal the eastern.

Tony.
--
f.anthony.n.finchhttp://dotat.at/___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Ian Batten


On 3 Sep 2010, at 08:44, Michael Sokolov wrote:


Tony Finch  wrote:


Oh, do tell, where will you get your GMT reference from?


If I have trouble figuring it out myself, I'll just E-mail Rob Seaman
and ask him what time it is.


Suppose I wish to measure 10 solar seconds from now, forward.  I have  
a clock ticking SI seconds at arbitrarily high precision and  
resolution.  How do I find out how many SI seconds I should count in  
order to count ten UT1 seconds?  Can I determine that value  
prospectively, or only retrospectively?


The reason I ask is that in a mean timescale, it obviously matters  
which range of time is the basis for the average.   I'm not clear if  
it's the (some period) up to the beginning of the interval, (some  
period) up to the end of the interval, (some period) up to some other  
datum or what.  In several of these scenarios, it's not obvious how  
you would determine the conversion between UT1 seconds and SI seconds  
prospectively.


ian

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Rob Seaman
And I'd point you to Steve Allen :-)

On Sep 3, 2010, at 12:44 AM, Michael Sokolov wrote:

> Tony Finch  wrote:
> 
>> Oh, do tell, where will you get your GMT reference from?
> 
> If I have trouble figuring it out myself, I'll just E-mail Rob Seaman
> and ask him what time it is.  Given that his views on the subject as
> expressed on this list are much closer to mine than, say, PHK's, I would
> trust his answer better than ITU's.
> 
> MS
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1

2010-09-03 Thread Michael Sokolov
Tony Finch  wrote:

> Oh, do tell, where will you get your GMT reference from?

If I have trouble figuring it out myself, I'll just E-mail Rob Seaman
and ask him what time it is.  Given that his views on the subject as
expressed on this list are much closer to mine than, say, PHK's, I would
trust his answer better than ITU's.

MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs