Le 20/01/2012 08:49, mike cook a écrit :
The questions do not define requirements in any scientific sense, so
let's start with that.
One advantage of that may be that there are no camps to defend, just
propositions to debate, so I expect it could be be usefully wiki'd.
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
This works only when mars is an isolated world. If there were commerce
between mars and earth, or other need to regularly communicate, then there
would be demand for a uniform time scale for both, just like there was
demand for a uniform time between cities that shared proximity 150 years
[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
I would like your comments on this API proposal, if we can agree
that it workable, I am willing to push it, hard, in the UNIX world.
Thanks in advance.
Lets get REAL about time
With the leap-seconds still unresolved, it is time that we get real about
time in the
http://geneva.usmission.gov/2012/01/20/statement-on-the-leap-second-and-future-of-the-universal-coordinated-time-utc/
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to
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
Le 20/01/2012 13:09, Poul-Henning Kamp a écrit :
http://geneva.usmission.gov/2012/01/20/statement-on-the-leap-second-and-future-of-the-universal-coordinated-time-utc/
Love it. The rocks are right up a head, but we are not changing course.
get someone to shift the rocks!
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
Poul-Henning Kamp wrote:
The only game changer I can spot, is if Daniel Gambis starts to announce
leapseconds 30 months in advance with stated intention to get it up to five
years, as soon as the science supports DUT11s.
'Daniel Gambis said that the IERS could confidently predict leap
On Fri, Jan 20, 2012 at 12:29, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
I would like your comments on this API proposal, if we can agree
that it workable, I am willing to push it, hard, in the UNIX world.
FWIW, I like it and I wish we will have something like this in a not
to distant
On 2012 Jan 20, at 07:29, mike cook wrote:
UNLESS, parallel time scales spring up.
which part of parallel time scales is not visible in the second
of the three pictures?
http://www.ucolick.org/~sla/leapsecs/amsci.html
(Apologies to users of the as-deployed right zoneinfo files,
for that deserves
For the smallest time resolution required, we might suppose that at some
point in the
future there might be a need to account for transmission delay from one part
of a computer to another. The smallest location that I can imagine being of
interest even in a future computer is the diameter of 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
In message CACzrW9Cv16zyYUU802fxq=c3-pxrcz6mevzpabgjhb_xeyc...@mail.gmail.com
, Stephen Colebourne writes:
Could Java treat the binary128 as an opaque type and provide
subtraction/addition primitives for it ?
The Java spec currently uses 64 bit seconds and 32 bits for
nanoseconds. Only one
In message 4f19885c.3090...@sfr.fr, mike cook writes:
Modern CPUs clock around 4GHz, multiplying by 1000 for resulution we
find that we need 42 bits after the binary point.
Solaris already has 64 bit quantities for time operations. From their doc:
time_t, and its derivative types struct
Warner Losh i...@bsdimp.com wrote:
The synodic day (or something very, very close) is used on Earth and
has naturally been used on Mars for rover operations. In fact, the
amplitude of the equation of time on Mars is much greater than it is
on Earth due to the greater eccentricity of the
Poul-Henning Kamp wrote:
The Epoch is not important, and for reasons of debugging programmer
mistakes, preferably clearly visibly different from other magic numbers.
I think he was suggesting that you use the 1958-01-01 epoch that NASA (and
I, in my desktop clock program) already use. That would
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
Zefram wrote:
I think he was suggesting that you use the 1958-01-01 epoch that NASA (and I,
in my desktop clock program) already use.
It's more than NASA, it's an international standard for the space community -
see page 3-2 at:
http://public.ccsds.org/publications/archive/301x0b4.pdf
The
On Fri 2012-01-20T16:34:12 +, Poul-Henning Kamp hath writ:
PTP already uses TAI
Caution. PTP specifies TAI seconds, but uses the LORAN-C epoch
that is offset by the 10 (elastic) seconds.
Note that this caution contains elements which bear resemblance to the
(more recent, not from 10 years
Steve Allen s...@ucolick.org wrote:
TAI can be derived from UTC, GPS and other broadcast timescales, so
availability is fine.
Indications have been that BIPM will disagree violently with that
statement.
And what's wrong with simply ignoring them after telling them to STFU?
MS
Gerard Ashton wrote:
For the smallest time resolution required, we might suppose that at some
point in the future there might be a need to account for transmission delay
from one part of a computer to another. The smallest location that I can
imagine being of interest even in a future
On 1/20/2012 2:23 PM, Rob Seaman wrote, in part:
There is plenty of prior art to consult here on both the CS side (early Crays
already minimized cable runs to mitigate light speed constraints, it is
commonplace today) and on the physics side (e.g., Planck units*). Workflow
logistics and
A more accurate statement is that a real time event can be labeled with
measured time, M, by local device that keeps
the TAI(h) time scale, and the TAI(h) time scale can be steered to
UTC(k), GPS, or another broadcast time scale.
The letter k designates a recognized time laboratory while h
Tony Finch wrote:
if the people in a country or region don't like the alignment between their
clocks and the sun, they can use their political processes to change their
timezone offset and/or DST rules.
But Jacob Rees-Mogg's suggestion that:
Somerset should have its own time zone, with
On 2012-01-20 15:46, Gerard Ashton wrote:
For the smallest time resolution required, we might suppose that at some
point in the
future there might be a need to account for transmission delay from one
part
of a computer to another. The smallest location that I can imagine being of
interest
The Long Now Foundation has reached a milestone in the 10,000-Year Clock
project, the completion of the 500 foot deep shaft that will contain the clock:
http://www.1yearclock.net/updates.html
I believe grinding spiral steps into the wall all the way down comes next.
Rob
To avoid thread-divergence, I have collected some responses here:
Zefram writes:
I think he was suggesting that you use the 1958-01-01 epoch that NASA (and
I, in my desktop clock program) already use.
I disagree, as a matter of software quality assurance, it is important
to choose an epoch
On 20 Jan 2012, at 20:51, Rob Seaman wrote:
Tony Finch wrote:
if the people in a country or region don't like the alignment between their
clocks and the sun, they can use their political processes to change their
timezone offset and/or DST rules.
But Jacob Rees-Mogg's suggestion
(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 20 Jan 2012, at 15:36, Rob Seaman wrote:
Poul-Henning Kamp wrote:
The only game changer I can spot, is if Daniel Gambis starts to announce
leapseconds 30 months in advance with stated intention to get it up to five
years, as soon as the science supports DUT11s.
'Daniel Gambis said
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
On Jan 20, 2012, at 9:29 AM, mike cook wrote:
Modern CPUs clock around 4GHz, multiplying by 1000 for resulution we
find that we need 42 bits after the binary point.
Solaris already has 64 bit quantities for time operations. From their doc:
time_t, and its derivative types struct timeval
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 11:29:18 -, Poul-Henning Kamp wrote
in a message to: Leap Second Discussion List leapsecs@leapsecond.com
I would like your comments on this API proposal, if we can agree
that it workable, I am willing to push it, hard, in the UNIX world.
This ticks all the right boxes for
Poul-Henning Kamp wrote:
To avoid thread-divergence, I have collected some responses here:
Am happy to see such an effort and agree generally with previous comments,
expecially Mark's and Steve's. Will keep my editorial comments to a minimum
(here) to squelch divergence, but I will point out
On Jan 20, 2012, at 10:54 PM, Rob Seaman wrote:
Poul-Henning Kamp wrote:
To avoid thread-divergence, I have collected some responses here:
Am happy to see such an effort and agree generally with previous comments,
expecially Mark's and Steve's. Will keep my editorial comments to a
42 matches
Mail list logo
