On 21 Jan 2012, at 23:42, Tony Finch wrote:
On 21 Jan 2012, at 18:53, Ian Batten i...@batten.eu.org wrote:
allow DUT1 to grow to 31 minutes, and then allow anyone who wants to reduce
DUT1 to 29 minutes to change their time zone
No that isn't how it works. DUT1 is the difference between
On 2012-01-21 01:36, Mark Calabretta mentioned
correct implementations of leap seconds:
Try Tom's leapsecond.com, you can watch the next one in real time.
Only 161d 23h 23m 42s to go - tick, tick, tick,...
Yes, this is very impressive! I wonder whether
Tom Van Baak uses any C or Java
Try Tom's leapsecond.com, you can watch the next one in real time.
Only 161d 23h 23m 42s to go - tick, tick, tick,...
Yes, this is very impressive! I wonder whether
Tom Van Baak uses any C or Java or perl or..
functions to get current UTC.
Thanks!
Michael Deckers.
It's just
On 20 January 2012 23:51, Ian Batten i...@batten.eu.org wrote:
(I would note that the implications of this approach appear to mean
that the +01:00 of Paris today, would eventually become +02:00, then
+03:00 and so on to +infinity. A fairly written document would note
that as being the
IMO it is the lack of a consistently written and fair set of options and
their implications that is holding the debate back in the ITU and elsewhere.
Perhaps so, but the claim that absorbing an increase in timezone changes (ie,
allow DUT1 to grow to 31 minutes, and then allow anyone who
On 21 Jan 2012, at 18:53, Ian Batten i...@batten.eu.org wrote:
allow DUT1 to grow to 31 minutes, and then allow anyone who wants to reduce
DUT1 to 29 minutes to change their time zone
No that isn't how it works. DUT1 is the difference between UT1 and UTC. It has
nothing to do with local
We've given this some thought. One problem is that many of the contributors
of the list have taken a side and have been re-defining words to enhance
their bargaining positions. This makes a writing a wiki difficult.
Would it work if we had 3 wikis? One for the good guys, one for the bad
[Leap years vs leap seconds]
If UTC is discontinuous in any sense then so must the Gregorian calendar be,
with a discontinuity 86400 times greater on Feb/29.
Noone seems at all concerned about that discontinuity.
There are two problems with leap seconds vs leap years.
One is that leap
On 2012-01-20 10:26, Hal Murray compared
leap seconds and leap days:
There are two problems with leap seconds vs leap years.
One is that leap seconds are harder to predict.
Yes. Nobody would use the Gregorian calendar
if the IERS determined the leap years only a
year in
On 20 Jan 2012 at 17:26, Mark Calabretta wrote:
If UTC is discontinuous in any sense then so must the Gregorian
calendar be, with a discontinuity 86400 times greater on Feb/29.
You don't even have to wait for a leap year for a non-uniform radix,
since you've already got that in 30 days hath
On 2012 Jan 20, at 06:49, Stephen Colebourne wrote:
Some have suggested that leap seconds could be absorbed as a
permanent offset change. One of the proposals that should be
written up is how that would work.
like this?
http://www.ucolick.org/~sla/leapsecs/right+gps.html
How much
Steve Allen wrote:
How much simplification is necessary before an ITU voting member
can grok that?
Awesome page. But I'm afraid that it won't go down well with some of these
people.
Therefore, any change of name of the broadcast time scale can only be
considered if there already exists a
Mark Calabretta mcala...@atnf.csiro.au wrote:
Leap seconds did for the clock what Julius Caesar did for the
calendar - 2000 years ago.
Actually the reverse. Julius Caesar replaced an unpredictable calendar
with a predictable one. When civil time was based on UT1 it had
predictable labels,
Stephen Colebourne scolebou...@joda.org wrote:
Some have suggested that leap seconds could be absorbed as a permanent
offset change. One of the proposals that should be written up is how that
would work.
What is not obvious about it?
At the moment, if the people in a country or region don't
On 20 January 2012 16:25, Tony Finch d...@dotat.at wrote:
Stephen Colebourne scolebou...@joda.org wrote:
Some have suggested that leap seconds could be absorbed as a permanent
offset change. One of the proposals that should be written up is how that
would work.
What is not obvious about it?
Stephen Colebourne wrote:
(I would note that the implications of this approach appear to mean
that the +01:00 of Paris today, would eventually become +02:00, then
+03:00 and so on to +infinity.
Other direction. Paris's UT+1h would become TI+1h, then TI+0h, TI-1h,
TI-2h, and so on. (TI meaning
(I would note that the implications of this approach appear to mean
that the +01:00 of Paris today, would eventually become +02:00, then
+03:00 and so on to +infinity. A fairly written document would note
that as being the case and indicate when in the future it would be a
problem.)
So
On Fri 2012/01/20 07:50:47 -, michael.deckers wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
existence. Is it any wonder that leap seconds may not have been
implemented properly?
Can you point us to an implementation that does it properly?
Try Tom's
Try Tom's leapsecond.com, you can watch the next one in real time.
Only 161d 23h 23m 42s to go - tick, tick, tick,...
For those of you with a smart phone here's the mobile version:
http://leapsecond.com/m/nixie.htm
Note it's just JavaScript, not an app, so it works on any phone.
/tvb
Daniel R. Tobias d...@tobias.name wrote:
On 17 Jan 2012 at 23:18, Warner Losh wrote:
But it just so happens that this draft changes UTC to match the
POSIX definition of time_t where leap seconds don't really exist...
It seems to be a rather blatant example of geek arrogance to say
that,
Tony Finch wrote:
Daniel R. Tobias wrote:
Warner Losh wrote:
But it just so happens that this draft changes UTC to match the
POSIX definition of time_t where leap seconds don't really exist...
It seems to be a rather blatant example of geek arrogance to say
that, when a tech standard
Rob Seaman sea...@noao.edu wrote:
Redefining UTC would debase the entire family of Universal Time
terminology, including GMT.
UTC itself wrecked time terminology with thousands of years of history.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
South Utsire: Westerly or
On Jan 18, 2012, at 6:49 PM, Daniel R. Tobias wrote:
On 17 Jan 2012 at 23:18, Warner Losh wrote:
But it just so happens that this draft changes UTC to match the
POSIX definition of time_t where leap seconds don't really exist...
It seems to be a rather blatant example of geek arrogance
And it isn't geeks redefining reality to match the implementation.
I'm just pointing out that the new definition matches the
implementation.
Only if you forget about the leap seconds that have already happened.
___
LEAPSECS mailing list
On Thu 2012/01/19 10:06:56 PDT, Warner Losh wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
I'll point out that leap seconds redefined the reality that time was a
uniform radix to be a non-uniform radix was also fairly arrogant,
taking thousands of years of use and
On Jan 19, 2012, at 4:21 PM, Mark Calabretta wrote:
Even now the many people who refer to UTC as a discontinuous
time scale, many of whom should be expected to know better, seem
not to be aware of it.
It is discontinuous for some definition of discontinuous. While strictly
speaking time is
Even now the many people who refer to UTC as a discontinuous
time scale, many of whom should be expected to know better, seem
not to be aware of it.
Mark Calabretta
Mark,
Welcome back to the list. It's been a while.
Here's a chance for some creative input. If as you say UTC
is not
On Thu 2012/01/19 18:37:25 PDT, Warner Losh wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
It is discontinuous for some definition of discontinuous.
If UTC is discontinuous in any sense then so must the Gregorian
calendar be, with a discontinuity 86400 times greater
On Thu 2012/01/19 20:54:52 -0800, Tom Van Baak wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
Welcome back to the list. It's been a while.
I have to admit to lurking, though usually take shelter during
the cyclone season, except this season was too hard to ignore
for
On 2012-01-19 23:21, Mark Calabretta wrote:
It seemed to take a long time to get TF460 right, now in its 6th
revision. And for most of the 40 years it was accessible only by
subscription - assuming that is, that you were even aware of its
existence. Is it any wonder that leap seconds may
Rob Seaman sea...@noao.edu wrote:
As has been said here many times they are two different kinds of
timekeeping, in theory as well as in real life. The ITU pretending
otherwise won't change that.
They aren't pretending otherwise, they are dealing with a proposal to
move civil time from one to
They aren't moving anything. They are removing access to the Earth
orientation timescale.
Having failed to reach consensus, they should similarly fail to vote.
Rob Seaman
NOAO
--
Tony Finch wrote:
Rob Seaman wrote:
As has been said here many times they are two different kinds of
They aren't moving anything. They are removing access to the Earth
orientation timescale.
Having failed to reach consensus, they should similarly fail to vote.
Rob Seaman
NOAO
Rob,
Get real. Do you really think access to the Earth orientation
timescale will be removed? Is this a hidden
I swear I typed SOPA. Something changed it before it went over the wire...
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
On 17 Jan 2012 at 23:18, Warner Losh wrote:
But it just so happens that this draft changes UTC to match the
POSIX definition of time_t where leap seconds don't really exist...
It seems to be a rather blatant example of geek arrogance to say
that, when a tech standard fails to conform to
Dennis Ferguson wrote:
I hence believe that time interval applications and applications which need
UTC have fundamentally incompatible requirements (in real life, if not in
theory)
As has been said here many times they are two different kinds of timekeeping,
in theory as well as in real
On Jan 17, 2012, at 9:53 PM, Rob Seaman wrote:
Dennis Ferguson wrote:
I think the fact is that if you want to run pure POSIX applications on your
system reliably you will dump the time synchronization software, set the
system clock to your wrist watch at boot time and then let the system
37 matches
Mail list logo
