On Mon, 14 Feb 2011, Mark Calabretta wrote:
On Fri 2011/02/11 15:42:41 -, Tony Finch wrote
See for example
http://six.pairlist.net/pipermail/leapsecs/2011-January/002124.html
where Rob Seaman wrote Civil timekeeping is cumulative. Tiny mistakes
posing the problem will result in large
Tony Finch wrote:
Rob frequently argues that we can't use a pure atomic timescale as the basis
of civil time because of the quadratically increasing offset betwee UT1 and
TAI.
Well no, I don't think I've ever made such an argument. It is a question of
rates, not offsets. And the two
Tony Finch wrote:
Furthermore using timezones to keep civil time in sync with
the sun leads to simpler software and it will work for over
ten thousand years.
No. Breaking timezones on top of breaking UTC with the
apparent motivation of allowing TAI to be suppressed is
bad on top of
On Tue 2011-02-15T02:07:59 +0200, Paul Sheer hath writ:
In any case, whatever solution ye'all come up with should not
merely be In Principle. It should come as a patch on some real code.
Which part of this is not already implemented by the code when
it uses the right zoneinfo files?
To be
On Mon 2011/02/14 18:00:02 -, Tony Finch wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
Rob frequently argues that we can't use a pure atomic timescale as the
basis of civil time because of the quadratically increasing offset between
UT1 and TAI. You yourself made
On Mon, 2011-02-14 at 16:23 -0800, Steve Allen wrote:
Which part of this is not already implemented by the code when
it uses the right zoneinfo files?
1. let say we want a future where timezones are adjusted by 30 minutes
whenever the sun starts rising too late. Write this into the Olson
What's the point?
Two links to refresh the discussion:
http://www.springerlink.com/content/g216411573882755/
http://maia.usno.navy.mil/eopcppp/eopcppp.html
Paul Sheer wrote:
I think what you will find is that there is no technical difference between
moving leap seconds into
