In message: [EMAIL PROTECTED]
Zefram [EMAIL PROTECTED] writes:
: Steve Allen wrote:
: http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf
:
: This is the really interesting one. They present the accuracy of
: simulated predictions of UT1, and that accuracy is much poorer than
:
Steve,
thank you for this enlightening report.
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: On Wed 2007-01-17T12:31:14 -0700, Warner Losh hath writ:
: It has been remarked that the current state of the art is that 100ms
: accuracy can be predicted about a
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: Unfortunately, the kernel has to have a notion of time stepping around
: a leap-second if it implements ntp.
:
: Surely ntpd could be altered to isolate the kernel from
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: Most filesystems store time as UTC anyway...
:
: POSIX time is not UTC :-)
True. It is designed to be UTC, but fails to properly implement UTC's
leap seconds
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: If by some limp attempt you mean returns the correct time then you
: are correct.
:
: It's not the correct time under the current standard if the
: timekeeping model doesn't implement leap seconds correctly. I
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: OSes usually deal with timestamps all the time for various things. To
: find out how much CPU to bill a process, to more mondane things.
: Having to do all
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh wrote:
:
: leap seconds break that rule if one does things in UTC such that
: the naive math just works
:
: All civil timekeeping, and most precision timekeeping, requires only
: pretty naive math.
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: On Jan 6, 2007, at 16:18, M. Warner Losh wrote:
:
: Unfortunately, the kernel has to have a notion of time stepping around
: a leap-second if it implements ntp. There's no way around that that
: isn't horribly
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh wrote:
: Anything that makes the math
: harder (more computationally expensive) can have huge effects on
: performance in these areas. That's because the math is done so often
: that any little change
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Warner Losh scripsit:
:
: There's no provision for emergency leapseconds. They just have to be
: at the end of the month, and annoucned 8 weeks in advance. IERS has
: actually exceeded this mandate by announcing
In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 2 Jan 2007 at 11:56, Ashley Yakeley wrote:
:
: GPS is TAI. I'm not proposing abandoning TAI for those applications
: that need it.
:
: It's a few seconds off from TAI, isn't it? It was synchronized to
:
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: Software should serve human needs, not the other
: way around. Anyone needing fixed seconds should use TAI.
I think this idea would be harder to implement than the current
leapseconds.
There are many systems
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Michael Sokolov) writes:
: The people who complain about leap seconds screwing up their interval
: time computations are usually told to use TAI. They retort that they
: need interval time *between civil timestamps*.
Actaully, interval
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Tony Finch scripsit:
: On Sun, 31 Dec 2006, John Cowan wrote:
:
: However, it's clear that UTC does not contain the sort of jumps
: that LCT does, where a single broken-down time may represent
: two different
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Poul-Henning Kamp wrote:
:
: Rob, If you feel uncomfortable with calling leapseconds
: discontinuities, then we can use the term arrhythmia instead.
:
: Which raises the question of why projects requiring an
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Just a reminder that UTC has no - none - nada - discontinuities.
At the very least, the TAI-UTC difference is discontinuous with jumps
at the leap seconds. One could easily suggest that 'UTC has
discontinuities'
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote:
:
: Calculating time intervals for times 6+ months in the future can be
: the least of one's worries when one tries to code up a library to deal
: gracefully
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: We can get that only by increasing the DUT tolerance.
Yes. Letting DUT be bounded by +- 10s rather than +- 0.9s is going to
affect a tiny number of users. Having leapseconds only known 6 months
in advance
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Rob Seaman scripsit:
:
: I don't care if you want to implement leap-milliseconds, as long
: as you tell me 10 years in advance when they happen.
:
: Again - with no intent to minimize the issues - what supports
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: Let's turn the question around. What would the harm be if |DUT1| were
: 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that
: the current 6 month scheduling window
In message: [EMAIL PROTECTED]
Zefram [EMAIL PROTECTED] writes:
: Keith Winstein wrote:
: what should a library do when a program asks to
: convert between UTC and TAI for some instant further than six months in
: the future?
:
: Refuse, of course. The correct
In message: [EMAIL PROTECTED]
Zefram [EMAIL PROTECTED] writes:
: Steve Allen wrote:
: and if I continue that practice
: I can later give you an estimate of how wrong I was when I told you.
:
: This is something that's missing from current
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: Hello, I just joined the leap seconds list. I wrote the time
: package for the Haskell programming language.
: http://semantic.org/TimeLib/
:
: I include code for making conversions between TAI and UTC, given a
:
I view the same data differently. I see it as a progression:
Local Solar time - mean local solar time -
timezone as mean local time at one point used for many - UTC - ???
Clearly, we're moving away from solar time and towards something else.
Our ability to tell time has exceeded the
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Steve Allen writes:
:
: In the middle of May some text about legal time in the US was
: introduced into a US Senate bill regarding funding for NSF and NIST.
: See section 508 of
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: M. Warner Losh scripsit:
:
: : The designers of Posix time thought it was more important to preserve
: : the property that dividing the difference between two time_t values
: : by 60, 3600, 86400 would give minutes
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Zefram scripsit:
:
: If this means that leap secounds and leap days are analogous, then I
: suppose so. If it means something else, I don't understand it.
:
: That's what I meant. Can you suggest a clearer
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Actually, this list is not a discussion per se. If we simplify the
: positions - just for the sake of argument here - to leap second yes
: and leap second no, the reality is that the folks pushing the leap
: second
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: M. Warner Losh scripsit:
:
: In message: [EMAIL PROTECTED]
: Rob Seaman [EMAIL PROTECTED] writes:
: : Actually, this list is not a discussion per se. If we simplify the
: : positions - just
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh objects:
:
: There are several doughty people here who happen to have that
: opinion, but they abide with us mortals outside the time lords'
: hushed inner sanctum.
:
: I have spent much time
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Simply allow the IERS to announce any number of leap seconds
: in advance extending over any time horizon - and yes - occurring
: at the end of any month. If predictability is the goal, relaxing
: unnecessary
In message: [EMAIL PROTECTED]
Neal McBurnett [EMAIL PROTECTED] writes:
: On Mon, Feb 06, 2006 at 10:37:37AM -0700, Rob Seaman wrote:
: 1) TAI can be recovered from UTC given a table of DTAI.
: 2) NTP can convey TAI as simply as UTC.
: 3) Deploy a small network of NTP
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: On Feb 14, 2006, at 12:50 PM, Markus Kuhn wrote:
:
: You can, of course, define, publish, implement, and promote a new
: version (4?) of NTP that can also diseminate TAI, EOPs, leap-second
: tables, and other good
In message: [EMAIL PROTECTED]
M. Warner Losh [EMAIL PROTECTED] writes:
: In message: [EMAIL PROTECTED]
: James Maynard [EMAIL PROTECTED] writes:
: : M. Warner Losh wrote:
: : In message: [EMAIL PROTECTED]
: : James Maynard [EMAIL PROTECTED] writes
In message: [EMAIL PROTECTED]
Tim Shepard [EMAIL PROTECTED] writes:
: But there's a difference between NTP timestamps, and the details of
: the implementation of a system which uses NTP for synchronization.
Ah, I was getting the two confused and didn't quite realize it until
your
In message: [EMAIL PROTECTED]
James Maynard [EMAIL PROTECTED] writes:
: Thanks, guys, for your feedback. Here's another iteration.
:
: The numbering of NTP seconds in the vicinity of a leap second seems to
: differ from one document to another. Here I follow the NTP (version 3)
:
In message: [EMAIL PROTECTED]
James Maynard [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
: In message: [EMAIL PROTECTED]
: James Maynard [EMAIL PROTECTED] writes:
: : Thanks, guys, for your feedback. Here's another iteration.
: :
: : The numbering of NTP seconds
In message: [EMAIL PROTECTED]
Neal McBurnett [EMAIL PROTECTED] writes:
: Rob Seaman wrote:
: I hope we can all continue this discussion in a more positive manner.
:
: It is the nature of email lists to be good at stimulating discussion,
: and bad at generating clear resolutions.
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: The legal time of the US is (in many more words) GMT.
: The officials who are charged by congress with the task of providing
: time provide UTC.
The legal time in the US is the mean solar time at a given meridian,
In message: [EMAIL PROTECTED]
Ed Davies [EMAIL PROTECTED] writes:
: Earlier, I wrote:
: We all know that it (and any other world-wide timescale) is
: postal at the level of the time it takes light to cross a
: moderately small room but for microsecond precision and looser
: this is
In message: [EMAIL PROTECTED]
Peter Bunclark [EMAIL PROTECTED] writes:
: On Sun, 22 Jan 2006, M. Warner Losh wrote:
: The short answer is that you cannot get a time feed of TAI, so the
:
: So isn't this one of the things we want to fix in the brave new world of
: joined-up
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Michael Sokolov) writes:
: Steve Allen [EMAIL PROTECTED] wrote:
:
: The CGPM recommendation on the timescale everyone should use says UTC.
:
: UTC(insert your national time service here) is available in real time.
:
: TAI is the
In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 21 Jan 2006 at 10:11, M. Warner Losh wrote:
:
: I maintain that for human activity, there's no need for leap seconds
: at all. In each person's lifetime, the accumulated error is on the
: order of a few
In message: [EMAIL PROTECTED]
James Maynard [EMAIL PROTECTED] writes:
: ones position using sight reduction tables. Today a mechanical watch or
: chronometer, or a battery-powered wristwatch, can be set to UTC using
: radio time signals. Then when power fails, the sailor still has a
:
In message: [EMAIL PROTECTED]
James Maynard [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: : If DUT1 is broadcast, then one can set the time keeping device to UT1
: : by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s
: : with a similar accuacy (or better
The biggest objection that I have to it is that NTP servers will be at
least .5s off, which is far outside the normal range that NTP likes to
operate. Unless the prceice interval is defined, you'll wind up with
the stratum 1 servers putting out different times, which ntpd doesn't
react well to.
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: On Thu 2006-01-19T18:30:02 +, Markus Kuhn hath writ:
: GPS sends out announcements within days after IERS does, which is
: excellent service.
IERS announced the leap second on July 4th, about 6 weeks before it
In message: [EMAIL PROTECTED]
Markus Kuhn [EMAIL PROTECTED] writes:
: M. Warner Losh wrote on 2006-01-19 19:20 UTC:
: : In other words, *no* incompatible changes are made to the NTP protocol.
: : In a correct UTC-SLS implementation, you should *not* be able to
: : distinguish
In message: [EMAIL PROTECTED]
Markus Kuhn [EMAIL PROTECTED] writes:
: M. Warner Losh wrote on 2006-01-19 19:20 UTC:
: Effectively, you'd have to have two time scales in the kernel. UTC
: and UTC-SLS. You make it sound simple, but the hair in doing this may
: be quite difficult
In message: [EMAIL PROTECTED]
Francois Meyer [EMAIL PROTECTED] writes:
: On Mon, 16 Jan 2006, Mark Calabretta wrote:
:
: On Fri 2006/01/13 11:17:52 -, Michael Deckers wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
: I must get TAI, up to an integration constant. This
In message: [EMAIL PROTECTED]
Mark Calabretta [EMAIL PROTECTED] writes:
: On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
: Maybe it should be, but this is far from being
: obvious from its current definition.
:
: I agree
In message: [EMAIL PROTECTED]
Mark Calabretta [EMAIL PROTECTED] writes:
: On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
:At some instant when TAI took a value in the positive leap second between
:2006-01-01 + 00 h + 00
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Ed Davies writes:
: Wow, things have got really stirred up around here. Lots of interesting
: points but I'll just concentrate on one...
:
: Poul-Henning Kamp wrote:
: Well, the
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: But how in practice is it envisaged that a scheme
: for migrating time zones versus TAI would work, precisely?
:
: Straightforwardly. Each locality decides when and how to adjust both
: its offset from TAI and its
In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote:
:
: Civil time is in the hands of individual governments, and they
: tend to expect their computers to use the same time as the
: rest of their country.
:
:
In message: [EMAIL PROTECTED]
Neal McBurnett [EMAIL PROTECTED] writes:
: I still haven't seen any good data on predictions for periods of
: longer than 9 years.
Neal,
thanks for the excellent summary of the current state of the art in
prediction.
I think this shows that a 20 year
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:
:
: As someone who has fought the battles, I can tell you that a simple
: table is 10x or 100x easier to implement than dealing with parsing
: the data from N streams.
In message: [EMAIL PROTECTED]
Joseph S. Myers [EMAIL PROTECTED] writes:
: The Linux kernel (with NTP synchronisation) duly syslogged
:
: Dec 31 23:59:59 digraph kernel: Clock: inserting leap second 23:59:60 UTC
:
: and Markus's program showed a transition from 1136073600.005623 to
:
In message: [EMAIL PROTECTED]
Neal McBurnett [EMAIL PROTECTED] writes:
: Here are some notes on facilities in some Unix systems to show
: evidence of leap seconds. Some recent distributions are out of date
: as noted below. Can folks check others (Solaris, *BSD, etc?).
I'll comment
In message: [EMAIL PROTECTED]
Francois Meyer [EMAIL PROTECTED] writes:
: On Tue, 20 Dec 2005, Rob Seaman wrote:
:
: On Dec 20, 2005, at 1:30 AM, Poul-Henning Kamp wrote:
:
: There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS
: support center:
:
:
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: After all, it's not like the world is going to come to an end.
If the end of the world is what it takes to abolish leap seconds, I'm
all for it :-)
Warner
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: The question is whether at least 20 minutes (presuming this to be
: accurate) is intrinsic to the system design or is rather a result of
: poor implementation by some receiver manufacturers.
A cold GPS receiver takes
In message: [EMAIL PROTECTED]
Tom Van Baak [EMAIL PROTECTED] writes:
: In addition, since GPS time is TAI - 19s, the GPS-UTC difference will
: eventually overflow any fixed-sized transmission packet (if transmitted
: as a delta or as a table, it makes no difference in the end).
:
:
In message: [EMAIL PROTECTED]
Tom Van Baak [EMAIL PROTECTED] writes:
: Too much is made of the overflow. Fields rollover all
: the time in real life and it's often a simple engineering
: matter to take this into account. Not sure I would call
: it cheating. We get by fine with just 7
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: In my understanding the GPS system
: itself handles leap seconds pretty well, almost optimally.
One could say that GPS handles them perfectly, in that they do not
exist at all in the GPS time scale. However, GPS'
In message: [EMAIL PROTECTED]
Steve Allen [EMAIL PROTECTED] writes:
: If POSIX were to fix the definitions of time_t and epoch, why would
: this not imply that handling leap seconds with Unix would become
: trivial?
Because leap seconds are not trivial. If you make time_t a TAI-like
In message: [EMAIL PROTECTED]
Ed Davies [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
: Also, many systems just aren't connected to a public
: network, or aren't connected to a network at all, but still have a
: need to have knowledge of leap seconds.
:
:
: Can you
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Peter Bunclark writes:
:
: I would have thought that part of the answer to the difficulty in
: implementation and testing would be to use an open-source library of tried
: and
68 matches
Mail list logo
