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 JavaScr
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
On 21 Jan 2012, at 23:42, Tony Finch wrote:
> On 21 Jan 2012, at 18:53, Ian Batten 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 UT
On 21 Jan 2012, at 18:53, Ian Batten 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 time, so it cannot
>
> 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 20 January 2012 23:51, Ian Batten 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 case and i
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
_
On Fri 2012/01/20 07:50:47 -, "michael.deckers" wrote
in a message to: Leap Second Discussion List
>> 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 leapsecond.com, you ca
>
> (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.)
S
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" meani
Tony Finch wrote:
>Actually the reverse. Julius Caesar replaced an unpredictable calendar
>with a predictable one.
Where it really *is* similar is that it took about 40 years before people
learned how to implement it correctly.
-zefram
___
LEAPSECS mail
On 20 January 2012 16:25, Tony Finch wrote:
> 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.
>
> What is not obvious about it?
>
> At the moment, i
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.
What is not obvious about it?
At the moment, if the people in a country or region don't like the
alignm
Mark Calabretta 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, whereas UTC has an unpre
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 me
On 20 January 2012 15:08, Steve Allen wrote:
> 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.uco
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 simplific
On 20 January 2012 14:31, Daniel R. Tobias wrote:
> 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 no
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 ha
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 advance
[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 le
> 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
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 no
On Thu 2012/01/19 20:54:52 -0800, "Tom Van Baak" wrote
in a message to: "Leap Second Discussion List"
>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 obvious reasons.
On Thu 2012/01/19 18:37:25 PDT, Warner Losh wrote
in a message to: Leap Second Discussion List
>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 Feb/29.
Noone
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 "disconti
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
On Thu 2012/01/19 10:06:56 PDT, Warner Losh wrote
in a message to: Leap Second Discussion List
>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 turning it on its head.
> 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
LEAPSEC
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 ar
Rob Seaman 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.finchhttp://dotat.at/
South Utsire: Westerly or northwesterly, becoming cyclonic f
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
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" to say
> that, when a
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 r
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
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 pa
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
>>
Rob Seaman 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 the other.
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 sys
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
40 matches
Mail list logo
