remove
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: Monday, December 20, 2010 12:01 PM
To: [email protected]
Subject: LEAPSECS Digest, Vol 48, Issue 23
Send LEAPSECS mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of LEAPSECS digest..."
Today's Topics:
1. Re: ISO Influence (Rob Seaman)
2. Re: ISO Influence (Tony Finch)
3. WWVB receivers, legal time, WWV (Gerard Ashton)
4. Re: ISO Influence (Daniel R. Tobias)
5. Re: POSIX and C (Was: Re: ISO Influence) (Ian Batten)
----------------------------------------------------------------------
Message: 1
Date: Sun, 19 Dec 2010 12:20:31 -0700
From: Rob Seaman <[email protected]>
Subject: Re: [LEAPSECS] ISO Influence
To: Leap Second Discussion List <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Dec 19, 2010, at 11:22 AM, Joe Gwinn wrote:
> At 10:47 AM -0700 12/19/10, Rob Seaman wrote:
>
>> Currently DUT1 is negligible for many purposes - this won't remain the case.
>
> In my career, I have encountered exactly one system that even knew what DUT1
> is, and even so DUT1 was handled in application code, in the one place that
> could even understand the question.
Thanks for emphasizing my point. The current absence of evidence is not
evidence for the lack of future problems. That UTC, as an implementation of
Universal Time, approximates Greenwich Mean Time is an assumption deeply built
into the fabric of systems and software and social procedures worldwide.
> The problem is that our various lists of advantages and disadvantages are not
> the same, so no single answer can work for all.
The problem is that the ITU has spent ten years unilaterally pursuing a
non-answer. We've actually achieved a lot of consensus-building here, but you
wouldn't know it because there is only this single Damoclean option hanging
over our heads.
It is unsurprising that no "single answer" is available. That's because
timekeeping comes in two flavors - interval timers and Earth orientation. True
solutions will recognize this fact - either explicitly along the lines
suggested by Steve Allen, or implicitly by minimizing the required maintenance
through better scheduling as outlined by PHK. Interestingly enough, both of
these options can be pursued without changing UTC at all.
Define a new timescale. Call it "TI", or "Coordinated Pan-Cosmic Time" if you
like. Declare victory. Turn to the underlying and more interesting issues of
building a bettor temporal mousetrap.
> The ITU, a creature of governments, will decide on the basis of what's
> best for the larger civil society,
Bwahahaha! ...mopping tears from my eyes... The ITU is not considering issues
of "civil society" at all. They are listening to the imagined self-interests
of one particular highly technical lobby suffering from tunnel vision.
> even at the expense of the sciences, astronomy being especially affected.
...well, that's certainly true :-)
Rob
------------------------------
Message: 2
Date: Sun, 19 Dec 2010 23:21:00 +0000
From: Tony Finch <[email protected]>
Subject: Re: [LEAPSECS] ISO Influence
To: Leap Second Discussion List <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On 19 Dec 2010, at 01:18, Magnus Danielson <[email protected]> wrote:
>
> This is true, if we by "computing" means POSIX.
There are many standards other than POSIX which use a POSIX timescale or one
equivalent to it. For example, NTFS, DNSSEC and NTP's basic timescale.
> POSIX as extended by NTP kernel interface may however provide sufficient
> information to represent UTC.
For the current time, yes, but all the higher level libraries cannot represent
UTC so code can't do calculations with time correctly.
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
------------------------------
Message: 3
Date: Sun, 19 Dec 2010 20:03:54 -0500
From: Gerard Ashton <[email protected]>
Subject: [LEAPSECS] WWVB receivers, legal time, WWV
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The idea that consumer grade WWVB receivers will become obsolete supposes that
legal time will be a fixed (except for daylight savings
time) offset from UTC, and UTC continues to include leap seconds. If WWVB were
to broadcast the proposed TI instead of UTC, the old receivers would display
TI-based time, which would gradually depart from the legal UTC.
The problem with this solution does not lie in the WWVB receivers; considering
the uses to which they are put, they will fail before the error becomes a
problem. The problems are
(1) No system will be able to determine legal time without outside updates
every 6 months or so.
(2) There is no reason to think systems will be revised to carefully handle
events for which the legal time must be determined to subsecond accuracy in the
vicinity of a leap second. Leap seconds will still happen in legal time and
continue to cause many of the problems they do today.
Also, what about the voice announcements on WWV? Since it gives voice
announcements and also machine readable time, should it broadcast TI or UTC?
Gerry Ashton
------------------------------
Message: 4
Date: Sun, 19 Dec 2010 20:41:13 -0500
From: "Daniel R. Tobias" <[email protected]>
Subject: Re: [LEAPSECS] ISO Influence
To: Leap Second Discussion List <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
On 19 Dec 2010 at 9:58, Poul-Henning Kamp wrote:
> I don't think using Y2K metrics to estimate reviews for leap-second
> trouble is valid, it would underestimate the effort needed, as both
> Warner and I have learned the hard way: The issues involved are much
> trickier than a mere numeric rollover.
On the other hand, the century rollover is a once-in-a-lifetime event that
hadn't happened before within the computer age (maybe a few Hollerith
punch-card systems got confused by the 1899-1900 rollover).
Leap seconds have happened dozens of times since the 1970s, were happening
regularly while the current computing standards were being devised, continued
to happen regularly while current systems were implemented, deployed, and used,
and will continue to happen regularly for at least the next few years even if a
plan is adopted to ultimately stop them. Thus, it's silly to treat leap
seconds as strictly a future event with unexpected consequences.
--
== 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/
------------------------------
Message: 5
Date: Mon, 20 Dec 2010 13:42:19 +0000
From: Ian Batten <[email protected]>
Subject: Re: [LEAPSECS] POSIX and C (Was: Re: ISO Influence)
To: Leap Second Discussion List <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On 19 Dec 10, at 1732, Poul-Henning Kamp wrote:
> In message <[email protected]>, Steve Allen
> writ
> es:
>> On 2010 Dec 19, at 08:58, Poul-Henning Kamp wrote:
>>> Are you seriously suggesting that DCF77 and WWVB should not
>>> transmit the time people expect to see on their clocks ?
>>
>> Yes.
>>
>> Those clocks already have timezone adjustments, [...]
>
> I will not claim to know what WWVB clocks can, but I have yet to
> see a DCF77 clock with a timezone feature.
I've got one. There's a picture of it here (first picture on the page):
http://www.heise.de/tp/r4/artikel/20/20671/1.html
It synchs to DCF77, but you can add an integer offset so that its usable as a
synchronised clock anywhere you can get DCF77 (most of the UK, for example) and
it can free-run anywhere else (as it doesn't do fractional timezones there are
some obvious exceptions).
ian
------------------------------
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
End of LEAPSECS Digest, Vol 48, Issue 23
****************************************
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
