> >
> > previously i proposed that any code that measures a fail-timeout make
> > that timeout 1000ms longer whenever t % 86400 is near zero
>
> I assume that you mean near 0 or near 86400 since % is unsigned.
>
yes
code example posted previously:
http://six.pairlist.net/pipermail/leapsecs
>
> It seems from this that there are always a few people advertising
> leap seconds when they shouldn't be...
>
previously i proposed that any code that measures a fail-timeout make
that timeout 1000ms longer whenever t % 86400 is near zero
this pattern would duck most bugs
these bogus a
On Mon, 2011-10-03 at 12:19 +0100, Tony Finch wrote:
> Tom Van Baak wrote:
> >
> > Try using clock() instead of gettimeofday_in_millisecs(). The former
> > nicely increments with CLOCKS_PER_SEC resolution and is immune
> > from UTC, timezones, and leap seconds. At least it does on windows.
> > Ca
On Sat, 2011-10-01 at 15:42 -0700, Tom Van Baak wrote:
> > clock() wraps every 36 minutes on 32-bit systems *sigh*
>
> t_elapsed = (t_now - t_then) works regardless of binary wrap.
> Or am I missing something?
you are correct
as much as i don't like it, I guess C is all about such subtleties :-
On Sat, 2011-10-01 at 13:35 -0700, Tom Van Baak wrote:
> Try using clock() instead of gettimeofday_in_millisecs(). The former
> nicely increments with CLOCKS_PER_SEC resolution and is immune
> from UTC, timezones, and leap seconds. At least it does on windows.
> Can someone comment on unix/linux?
On Sat, 2011-10-01 at 09:32 -0400, Gerard Ashton wrote:
> Perhaps one of the systems has, [...]
Smearing/UTC-SLS doesn't cause the heartbeats to stop being sent for a
full second. It will, at most cause the heartbeats to change by a few
milliseconds - which doesn't break anything for this case. I
I am busy implementing some heartbeat monitoring code between two
machines. The spec calls for a 1 second recovery.
Basically if I get no heartbeats for 1 full second then I should
consider the peer system to have failed.
To cope with the leap-second scenario, one solution is to use a
timeout of
For entertainment value, has anyone ever considered
the amount of power it would consume to keep the
earths day exactly constant?
It's certainly a simple calculation. Napkin and pencil anyone?
-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
Toward the bottom, see how this clock uses daylight to keep itself in
sync with the day:
http://www.kk.org/thetechnium/archives/2011/06/the_clock_in_th.php
A "heat second" if you will :-)
-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http
http://www.popsci.com/technology/article/2011-05/smallest-atomic-clock-ever-now-sale
-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
A good article.
Hopefully the-powers-that-be will internalize the Compromise part... and
also Warner's comment 09 Apr 2011 22:51:03 UTC.
-paul
On Thu, 2011-04-07 at 09:56 -0700, Steve Allen wrote:
> PHK's article seems to be here
>
> http://queue.acm.org/detail.cfm?id=1967009
>
> --
> Steve
If it helps, perhaps we can revisit some terminology
NTP Time
NTP time is a 32-bit logical second count since 1900 (with a 32-bit
subsecond part) with 86400 logical seconds per day. On the leap second,
NTP time subtracts by 1 full second - i.e. it has a step jump of 1 full
second *back* in
You don't need to buy anything.
You could hack regular NTP to do the same thing.
It just needs to remove the leap second bit and accumulate 1 second
every time it sees the bit coming from the upstream server.
In actual fact we need BOTH timescales for backward compatability
i.e. to have a
four days ago to be precise...
http://www.mail-archive.com/leapsecs@leapsecond.com/msg02716.html
-paul
On Tue, 2011-02-22 at 15:33 -0700, Rob Seaman wrote:
> On Feb 22, 2011, at 2:31 PM, Warner Losh wrote:
>
> > the 10-year horizon solves many problems with leap seconds.
>
> I just wanted to
I think that it is extremely important that this issue is
understood. So let's try another example
Ian Batten wherefore sayeth,
> Yes, I can see leap-second would cause a problem there, except (a) the
> engineering design is insane and (b) even if it isn't, TAI is ready
> and waiting to s
On Mon, 2011-02-21 at 11:17 +, Tony Finch wrote:
> On Mon, 21 Feb 2011, Ian Batten wrote:
>
> > > Ascii timestamps do not have a way to include leap second information.
> >
> > But they trivially could.
>
> Is there any standard way to do so? If there is I would love a citation!
>
No, it's
>
> I see that the UK is now cranking up for CET:
> http://www.bbc.co.uk/news/uk-12517762
>
> Given that most ASCII timestamps are in "local" time, presumably leap
> seconds are no more evil than changes in timezone: both will throw off
> the calculations of these hypothetical isolated machines
ery useful properly that Posix time currently has.
This property is FAR more useful than caesium clocks, GPS, or
any pico-second time syncronization technology anyone has ever
thought of.
-paul
On Mon, 2011-02-21 at 01:26 +, Ian Batten wrote:
> On 19 Feb 2011, at 23:57, Paul Sheer
On Sat, 2011-02-19 at 23:25 +, Ian Batten wrote:
> >
> > to do this correctly for ten years, it would need a ten year leap
> > second table.
>
> Or someone to supply a manual update every two or three years. If the
> machine is so isolated that it cannot receive those updates, why does
>
>
> Why would you need that? An API might accommodate leap seconds, if
> that is required and they exist. Isolated machines sit on the same
> API, but the leap seconds never come. Japan doesn't have daylight
> saving times, but they don't run a special version of Unix that lacks
> tm_i
> A stand alone machine is going to have its clock drift by more than a
> few seconds over 10 years.Leap seconds are in the noise compared
>
Yes, but the applications running on a standalone machine
will use the same API's as any other POSIX machine.
Therefore, unless you want two seperate A
On Sat, 2011-02-19 at 11:08 -0500, Joe Gwinn wrote:
> At 3:59 PM + 2/19/11, Ian Batten wrote:
> >On 19 Feb 2011, at 15:41, Gerard Ashton wrote:
> >
> >> On 2/19/2011 10:24 AM, Joe Gwinn wrote, in part:
> >>> I have not been following the proposal in detail, but a key issue
> >>>to the POSIX
On Fri, 2011-02-18 at 11:39 -0700, Warner Losh wrote:
>
> That's part of the compromise that I've put forward. Goal: publish them
> out 10-20 years. [...]
I agree with this proposal.
I think this proposal represents a significant milestone for this
mailing list and I hope it will be "flagge
Tony Finch :
> [...]
>
> There is already code to handle leap seconds like timezones, but it is
> incompatible with POSIX and large amounts of other code and with NTP and
> other time broadcast systems.
>
Of course you are exactly right.
Now, consider an application that wants to support BOT
On Mon, 2011-02-14 at 22:46 -0700, Rob Seaman wrote:
> What's the point?
>
your discussions circle around standards and law
yet presently here on earth no-one follows these standards or laws
there is merely "crowd convention"
the challenge is not to study 150 years of committee minutes and t
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 O
> 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 Thu, 2011-02-10 at 21:31 -0800, Tom Van Baak wrote:
> Magnus & Mark & Rob,
>
> I know we're getting a bit far from the OP or from leap seconds,
You don't say
-paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/l
>
> It's been a while... Can you remind me why we will need to continue
> to pretend that there are 86400 SI seconds in a day, past the time
> when there are actually 86401 (or more)?
>
Why is because there is a semi-infinite number of existing
lines of code, right now in use, that calculate t
Since the velocity of the atomic clock causes relativistic dilation,
surely it is not the altitude-above-sea-level, but the radial distance
from the earths axis that we are talking about???
I.e. surely both latitude and altitude affect the ceasium? I mean the
velocity of the atomic clock as it s
On Wed, 2011-02-09 at 09:49 -0700, Warner Losh wrote:
> It is a lot easier to adjust by an hour for local time than it is to
> have a leap second every month, or more often. Thus Tony is right: the
> zoneinfo files adjusting local time via timezone shifts mandated by
> local government would e
>
> @Warner, UTC-SLS is simply a clearly written way to reconcile UTC to
> practical computing/business. I wish it was a recognised standard, but
> it isn't. That places me in the position of making it a de facto
> standard unless I receive a suitable alternative proposal. 8 million+
> Java devel
The Olson time library has all historican timezone information.
You can choose a zone, a time (back to the 1800's) and deduce
the precise zone offset in minutes and seconds.
This is inclusive of wierd time zones that were based on the hour
since sunrise (or some similar wierd thing), as well as
Impressive, but I'll keep with "warrants further investigation".
-paul
On Sat, 2011-01-08 at 16:14 +, Poul-Henning Kamp wrote:
> In message <1294502700.7016.37.ca...@localhost>, Paul Sheer writes:
>
> >> > Are the trades always automati
Hmmm -
I am somewhat concerned about your objectivity when you insist
that it is a problem for my company I've been staring at
this GSM code for 2 years now and I have face-to-face access
to our support staff.
>
> Microsecond resolution of the timestamp, millisecondish fuzzing, yes.
> So
>
> Both sides of the transaction stamp the transaction with
> timestamps with microsecond resolution.
Is this a fact?
> When the trades are reconciled at the end of
> the day, these timestamps need to match with a fuzz factor
> that's in the sub-millisecond range
Is this too a fact in c
On Fri, 2011-01-07 at 13:08 +, Zefram wrote:
> being a second out of synch would cause reconciliation problems.
can you explain this closer to the tech please?
i know i got the same explanation from one of our support
people until I challenged him...
we then went into the code and analysed
South Africa is GMT+2. It has no daylight savings time.
Programmers in SA know that to convert to/from local time,
you just adjust by 7200 seconds.
Because of this, most programmers in SA (who work on
in-house code) don't understand much about time-zones.
They don't know how to use the convertio
To get agreement on this proposal: will it be MORE difficult or LESS
difficult than the current discussions on this list
:-)
-paul
On Sat, 2011-01-01 at 20:22 +, Tony Finch wrote:
>
> 3. Keep civil time in sync with the sun by occasionally
> adjusting time zone offsets relative to UT
Actually, it is possible that "we" do get it.
You see, it is all very well to say what you are not advocating, but
factor in what you *are* advocating, combined with a good understanding
of how most computer systems currently work
Then combine that with how difficult it is to migrate the wor
Steve,
Your plan to put leap seconds into the zoneinfo is the
one I intuitively like the most.
But what if a programmer uses gmtime() to convert in one
direction but my_custom_mktime() to convert back??
To explain -->
In terms of how most programs deal with zones, the
only function which clean
I don't know how many on this list program or not in C, so here is some
background that may assist
There are three POSIX functions which convert between broken down time
format (aka -MM-DD HH:MM:SS) to a seconds-since-1970 scalar value.
They are gmtime(), localtime(), and mktime()
gmtim
> No, I'm trying to point out that you are an ignoranmus in this context
> with your "within some minutes is plenty" blanket statements.
>
If we misinterpret statements as axoims we will always be in a circle of
discussing what the statement excluded.
I am speaking for the 100's of millions of
ently starts to defibrillate when
the leap second comes along in June or December.
-paul
On Sun, 2010-12-12 at 09:26 +, Poul-Henning Kamp wrote:
> In message <1292118117.24926.52.ca...@localhost>, Paul Sheer writes:
>
> >I choose the solution that makes my flight the cheepest.
On Sun, 2010-12-12 at 01:20 +, Ian Batten wrote:
> >
> > This is because by-and-large software is written for the "lowest
> > common denominator".
>
> NFS (the computing glue of the nineties) and Kerberos/AD
> (the computing glue of the noughties). [...]
please understand that I am only tr
>
> Which bit of "need" don't you understand ?
>
> Are you happy with the ATC servers used to land your plane being
> "within some minutes" of each other ?
There are two choices:
A. the software was written to be safe assuming precise time
syncronization AND the time was reliably and precisel
On Sat, 2010-12-11 at 22:35 +, Poul-Henning Kamp wrote:
> In message <1292102703.24926.29.ca...@localhost>, Paul Sheer writes:
>
> >Apply this principle as follows: ACCEPT that there are servers
> >and desktops all over the world are MISCONFIGURED and do NOT
>
> > This is orders of magnitude more error than any leap second.
>
> One problem with the "kinda works" attitude is that is a barrier to
> entry for people whose systems need to work correctly to a much higher
>
I agree: the "kinda works" attitude is indeed such a barrier.
However the "
> I'm surprised by your claim that Telcos don't do NTP, [...]
I'm sure many do.
My point is that, if one's starting premise is that most systems in the
world *require* second-accurate syncronization, this is simply untrue.
In fact most work perfectly well even when they drift by minutes,
and a
in future, please read my email before you reply.
The fact that you INSIST that our timestamps being seconds or minutes
off MUST be a problem for my company,
WHEREAS it is definitively NOT a problem, is perplexing to me.
>
> Ohh, so you have heard of NTP, but have zero clue about how to
> conf
> Pray tell what authority you have for this pronouncement ?
I am totally confused where you got this idea that most of the worlds
servers tick over in sync, like a "We Will Rock You" resitation at
Wembly stadium. In fact it is more like the applause at the end of a
football game.
On my desk are
f Y2K bugs that
> > were fixed before they became a problem. In my very limited
> > experience, I wasn't affected by any, nor aware of them.
> >
> > Peter
> >
> >
> > On 10 December 2010 01:55, Paul Sheer wrote:
> >> Everybody said y2k
> It's very concerning if Y2K has been recast as a myth
> among technical professionals, [...]
Concerning indeed:
KCBI a Christian radio chanel recently proclaimed:
The Y2K is an example of scientists predicting disaster
when there was none. This is just like global warming.
There have bee
> Everybody said y2k was going to break everything. In the end, it was a
> non-event :)
It was a non-event BECAUSE the industry spent enormous $$ to fix all the
zillions of Y2K bugs in time.
It was still a disaster from an expendature point of view.
(Does anyone need to even explain this???
> Are there any requirements for mean solar time other than astronomy and
> celectial navigation?
>
Even if you can't find any important requirements,
if decoupling UTC from UT1 turns out later to be a mistake,
then it's not like an oil spill that you can easily undo
with time and money.
-paul
On Sun, 2010-09-05 at 16:39 -0700, Rob Seaman wrote:
>
> And there is the unstated assumption again, that not only
> could nothing bad possibly happen if leap seconds are
> ceased and DUT1 (implicit or explicit) grows without
> bound - but that nothing in our vastly complex social
> and technolo
On Sat, 2010-09-04 at 22:43 +, Poul-Henning Kamp wrote:
> In message <1283634327.9574.120.ca...@localhost>, Paul Sheer writes:
>
> >but you know about these reports because... you are psychic?
>
> Because it happens to be something I have worked with for many years.
> And because your code is time-agnostic, you are 100% sure that no
> telco anywhere has any leap-second issues with any code they run
> in their system ?
>
No, just 99% sure.
But here is an anecdote: It's standard practice when writing
business software to use "SELECT time('now')" and not gett
> You should really read the archives, before you say something
> as stupid as that.
that's exactly the sort of brazen intensity you can
practice on this list - for when it actually counts.
> Ahh, the deception of woolly thinking and selection bias :-)
>
an example of selection bias is the qu
On Sat, 2010-09-04 at 07:59 -0600, M. Warner Losh wrote:
> In message: <060dd241-6c0d-4a8e-8e12-42c5fe198...@batten.eu.org>
> Ian Batten writes:
> : > Of course, by
> : > saying that, you still have the problem. NTP doesn't solve the leap
> : > second problem: you still have weird s
>
> Of course, it would be cheaper for the software folks to never have to
> worry about it again. That would also make them predictable.
>
The software industry doesn't know or care about leap seconds.
The whole time issue is universally dealt with using a single
line in all installation man
> 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
> :
> : *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 decis
>
> Right, and it ticks based on UTC right now. Many systems have [...]
Ok, I did read your email to the end.
I had various rebuttles and alternatives, but after all these
I'm not sure the end picture is better than the current system
with leap seconds.
However that other doc had "tracking UT
> Best? This isn't an 'upgrade' at all, but rather returns to the
> 1960's practice of having "rubber" seconds. The UT1 second doesn't
> tick at a constant rate, so you have to constantly update the notion
> of the second.
>
in the 1960's we didn't have the Internet - which is the most
widely
On Fri, 2010-08-13 at 08:06 -0400, ashtongj wrote:
> For more information about one of the radio time and frequency stations, see
>
> http://www.nist.gov/physlab/div847/grp40/wwv.cfm
>
I am aware of these
One of my previous companies was building an embedded device that used
this signal to clo
Please Sir,
In what time zone is 1:00pm?
-paul
On Wed, 2010-08-11 at 20:53 -0500, Whyte, Wayne A. (GRC-CG000) wrote:
> I will be holding a U.S. Study Group 7 telecon on Monday, August 16 at
> 1:00 pm as we prepare for the ITU-R SG-7 meetings in October.
__
Hello Mr Whyte, Mr Hanson, and good day to you.
I would like to participate in this meeting. Please can I have
connect details.
My comments as follows:
The proposal to drop leap seconds has generated considerable anxiety
for the reason that it appears as though a small number of people are
deci
> Interpreting that would be diplomacy. The constraints placed on the
> SG7 process by its chair have denied the validity of inputs which are
> not technical.
>
to me this means that a group of ten is going to decide for
the other 6 billion on the premise that people are there to
serve the need
On Wed, 2010-08-11 at 09:54 +, Poul-Henning Kamp wrote:
> In message <20100811094933.gd26...@davros.org>, "Clive D.W. Feather" writes:
> >Zefram said:
> >>Western scientists have challenged such assertions, noting that the
> >>Magnetic North Pole is on a line of longitude that passes th
Hello there,
Thank you very much for hosting this list.
Sorry if any of these questions have been asked before.
With reference to
http://www.mail-archive.com/leaps...@rom.usno.navy.mil/msg00163.html
I noticed this intriging text which I wanted to ask about:
[...] if we really introduc
71 matches
Mail list logo
