Re: UT1 confidence

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

Re: UT1 confidence

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 : > accurac

Re: UT1 confidence

> In message <[EMAIL PROTECTED]>, Zefram writes: > >IERS Bulletin A gives an expression for the uncertainty of its UT1-UTC > >data predictions: > > > >S t = 0.00025 (MJD-today)**0.75 > > > >where "today" is the MJD of the bulletin's publication. The Bulletin > >only predicts a year ahead.

Timekeeping data

In the last about time stamps and time representations, I took the position that kernel timestamps had to be as simple as possible and time efficient as possible to not impact overall system performance. I was asked for data about timekeeping overhad causing problems to backup my claims. I've spen

Re: Introduction of long term scheduling

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 a

Re: Introduction of long term scheduling

In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : What is correct is to have a 61 second minute occasionally, neither : to redo the first second of the next day, nor to repeat the last : second of the current day. Unfortunately, that's not POSIX time_t. And when

Re: Introduction of long term scheduling

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

Re: Introduction of long term scheduling

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&

Re: Introduction of long term scheduling

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

Re: Introduction of long term scheduling

In message: <[EMAIL PROTECTED]> Tony Finch <[EMAIL PROTECTED]> writes: : On Sat, 6 Jan 2007, Ashley Yakeley wrote: : > : > Presumably it only needs to know the next leap-second to do this, not : > the whole known table? : : Kernels sometimes need to deal with historical timestamps (prin

Re: Introduction of long term scheduling

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 aro

Re: Introduction of long term scheduling

In message: <[EMAIL PROTECTED]> Ashley Yakeley <[EMAIL PROTECTED]> writes: : On Jan 6, 2007, at 08:35, M. Warner Losh wrote: : : > So for the foreseeable future, : > timestamps in OSes will be a count of seconds and a fractional second : > part. That's not go

Re: Introduction of long term scheduling

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 :

Re: Introduction of long term scheduling

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.

Re: Introduction of long term scheduling

In message: <[EMAIL PROTECTED]> Ashley Yakeley <[EMAIL PROTECTED]> writes: : On Jan 5, 2007, at 20:14, Rob Seaman wrote: : : > An ISO string is really overkill, MJD can fit into : > an unsigned short for the next few decades : : This isn't really a good idea. Most data formats have been

Re: A lurker surfaces

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

Re: Introduction of long term scheduling

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 : > actuall

Re: A lurker surfaces

In message: <[EMAIL PROTECTED]> Ashley Yakeley <[EMAIL PROTECTED]> writes: : On Jan 2, 2007, at 11:40, Warner Losh wrote: : : > The second technical problem is that the length of a second is : > implicitly encoded in the carrier for many of the longwave time : >

Re: Introduction of long term scheduling

> Warner Losh scripsit: > > > There's an exception for IERS to > > step in two weeks in advance if the earth's rotation rate hickups. > > So if I understand this correctly, there could be as many as 14 > consecutive days during which |DUT1| > 0.9s b

Re: A lurker surfaces

> > Then let's improve the infrastructure for communicating the best > > estimation of earth orientation parameters. Then in a world of > > ubiquitous computing anyone who wants to estimate the current > > rubber-second-time is free to evaluate the splines or polynomials > > (or whatever is used)

Re: Introduction of long term scheduling

> Still, it's a strange assumption, given that TF.640 allows, I > understand, leaps at the end of any month. Unofficially, the > wording seems to be: > > > A positive or negative leap-second should be the last second > > of a UTC month, but first preference should be given to the end > > of Decemb

Re: A lurker surfaces

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, interva

Re: A lurker surfaces

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

Re: A lurker surfaces

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

Re: A lurker surfaces

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 : > > t

Re: A lurker surfaces

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'

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> John Cowan <[EMAIL PROTECTED]> writes: : In this case there are really two questions: how much it would : cost to loosen DUT1 but leave it bounded, and how much it would : cost if it were only statistically, not absolutely, bounded. We've accepted a sta

Re: Mechanism to provide tai-utc.dat locally

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

Re: Mechanism to provide tai-utc.dat locally

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 su

Re: Mechanism to provide tai-utc.dat locally

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 advan

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : John Cowan wrote: : : > I assume you mean 23-hour or 25-hour LCT days? True. It does work : > against UCT days, though, since they are uniformly 1440 minutes long. : : Not should leap hours replace leap seconds.

Re: Design - a Tufte decision

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 co

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> Ashley Yakeley <[EMAIL PROTECTED]> writes: : On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: : : > That's a pretty bad format. Computers are binary and having : > pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec : > and picoseconds

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> Tony Finch <[EMAIL PROTECTED]> writes: : > The nature of the uncertainty is very different. The uncertainty of : > future UTC can be managed, but for timezones the only sane path is to : > eschew their use entirely. : : That isn't possible for applicatio

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> John Cowan <[EMAIL PROTECTED]> writes: : M. Warner Losh scripsit: : : > If I was to compute the number of seconds between Jan 1, 2007 0:0:0 and : > Dec 31, 2008 23:59:50, the answer is 63071990 or 63071991 or 63071992. : > We have no

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> Zefram <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : >Actually, the real answer is domain specific. There are many things : >that don't really care (when do I need to make the next 20 house : >payments, off by one sec

Re: Mechanism to provide tai-utc.dat locally

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 c

Re: Mechanism to provide tai-utc.dat locally

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 corre

Re: Mechanism to provide tai-utc.dat locally

In message: <[EMAIL PROTECTED]> Keith Winstein <[EMAIL PROTECTED]> writes: : The GNU C library includes a leap-second table in its timezone/leapseconds : file in the source package. This gets compiled in to the "right" (that is, : non-POSIX) zoneinfo files in, e.g., /usr/share/zoneinfo/

Re: Mechanism to provide tai-utc.dat locally

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. : : : I include code for making conversions between TAI and UTC, giv

Re: Equitable estoppel

In message: <[EMAIL PROTECTED]> John E Hein <[EMAIL PROTECTED]> writes: : Peter Vince wrote at 20:15 + on Dec 18, 2006: : > >For the moment, if leap seconds is to be abbandoned, I would favour the leap : > >minute instead. : > : > Is that not sitting on the fence, and ending up

Re: Equitable estoppel

In message: <[EMAIL PROTECTED]> Steve Allen <[EMAIL PROTECTED]> writes: : ITU rules which say their documents must be sold, not given away. All A simple web search shows that at least the UTC/leap second recommendations are readily available in electronic form... Warner

Re: what time is it, legally?

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 ea

Re: independence day

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

Re: building consensus

In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : This does not express a complete algorithm, of course, since it is : not tied to the days of the week. One presume the zero point of 1875 : was selected as a practical compromise with historical realities. : One q

Re: building consensus

> Warner Losh wrote: > >A rule implies that it is long term, I guess. Maybe there's a better > >word for that implication. > > In the realm of calendars the terminology is "arithmetic" versus > "observational". That's one of the things I inc

Re: building consensus

From: Rob Seaman <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] building consensus Date: Mon, 5 Jun 2006 08:35:39 -0700 > On Jun 4, 2006, at 9:57 PM, M. Warner Losh wrote: > > > leap days have a rule, while leap seconds are scheduled. > > A schedule and a rule are the same t

Re: building consensus

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, 3

Re: building consensus

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 clea

Re: building consensus

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

Re: building consensus

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"

Re: building consensus

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

Re: ideas for new UTC rules

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 cons

Re: Ambiguous NTP timestamps near leap second

From: Rob Seaman <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] Ambiguous NTP timestamps near leap second Date: Thu, 16 Feb 2006 16:30:37 -0700 > On Feb 16, 2006, at 2:06 PM, Markus Kuhn wrote: > > > While there is a 24:00:00, there is certainly *no* > > 24:00:00.0001. > > That would be 00:00

Re: 24:00 versus 00:00

From: Markus Kuhn <[EMAIL PROTECTED]> Subject: Re: 24:00 versus 00:00 Date: Thu, 16 Feb 2006 19:53:22 + > Steve Allen wrote on 2006-02-16 19:25 UTC: > > > No reply from an NTP server shall ever represent any point in time > > > between 23:59:60 and 24:00:00 of a UTC day. > > > > Minor poin

Re: Ambiguous NTP timestamps near leap second

> "M. Warner Losh" wrote on 2006-02-14 21:18 UTC: > > ntp time stampes are ambiguous at leap seconds (the leap indicator > > bits aren't part of the time stamp, exactly), which is a good reason > > to change them. However, the cost to change them could be quite

Re: An immodest proposal

In message: <[EMAIL PROTECTED]> Neal McBurnett <[EMAIL PROTECTED]> writes: : > UTC time stamps in NTP are ambiguous. TAI ones are not. UTC time : > stamps do not convey enough information to properly implement things : > like intervals, while TAI ones do. The NTPNG stuff that I've se

Re: An immodest proposal

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

Re: An immodest proposal

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 N

Re: Comparing Time Scales

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 c

Re: Comparing Time Scales

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]> : : >

Re: Comparing Time Scales

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 i

Re: Comparing Time Scales

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) : s

Re: Comparing Time Scales

From: "Daniel R. Tobias" <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] Comparing Time Scales Date: Fri, 03 Feb 2006 21:27:54 -0500 > On 3 Feb 2006 at 15:37, James Maynard wrote: > > > Thanks, guys, for your feedback. Here's another iteration. > > It would seem that PTP is actually counting from 1970

Re: Comparing Time Scales

From: James Maynard <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] Comparing Time Scales Date: Fri, 03 Feb 2006 17:31:46 -0800 > Warner Losh wrote: > > From: James Maynard <[EMAIL PROTECTED]> > > Subject: Re: [LEAPSECS]Comparing Time Scales > > Date

Re: Comparing Time Scales

From: James Maynard <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS]Comparing Time Scales Date: Fri, 03 Feb 2006 15:37:40 -0800 > 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.

Re: The nature of risk

> First risk - do all airlines and shipping lines automatically hew to > NT for all purposes? Or will UT time signals persist for some some > subsystems of some planes and ships from some countries under some > circumstances? A lack of imagination of how this might occur is no > protection - only

Re: Accommodating both camps

From: Michael Deckers <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] Accommodating both camps Date: Wed, 25 Jan 2006 16:50:59 + >Poul-Henning Kamp wrote on 2006-01-25: > > > If we abandon leapseconds today to avoid getting computer problems, > > we still have several hundred years of time t

Re: Accommodating both camps

> It seems clear that we have two camps, or schools of thought, on this > mailing list: > > 1) Those who favour retaining the status quo ante, in which civil time > is based on UTC and the standard time and frequency stations broadcast > UTC; and > > 2) Those who find it difficult to cope with UTC'

Re: the tail wags the dog

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

Re: wikipedia "Leap Seconds" collaboration

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 resolution

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> Mark Calabretta <[EMAIL PROTECTED]> writes: : On Sat 2006/01/21 10:11:04 PDT, "M. Warner Losh" wrote : in a message to: LEAPSECS@ROM.USNO.NAVY.MIL : : >You really should read the archives of this list. We've been over :

Re: the tail wags the dog

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

Re: NOT A cruel fraud!

In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : Mr. Losh and I have apologized to each other, off list. I think we : should now retire the "cruel fraud" subject line. Yes. I was too hard on Mr. Maynard and I appologize for my rough treatment of him here.

Re: NOT A cruel fraud!

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 n

Re: NOT A cruel fraud!

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 :

Re: NOT A cruel fraud!

In message: <[EMAIL PROTECTED]> Ed Davies <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > : > TAI is specifically contraindicated as a time : > : > scale. : > : : > : > TAI is not currently recommended by its creator

Re: NOT A cruel fraud!

In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : If "we've been over this in great detail," I would like a more specific : reference to the postings that did so. Also, "we've been over this in : great detail" seems not to have settled the issue. We have been

Re: Risks of change to UTC

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

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > UTC works for navigation, but leap seconds pose problems for other : > users of time. Stating absolutely that UTC is not broken ignores : > these other users.

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> "Brian Garrett" <[EMAIL PROTECTED]> writes: : > But the protocol for broadcasting DUT1 in, e.g., WWV, does not provide : > for DUT1 values of more than plus or minus 0.9 s. The value of DUT1 : > could be announced by voice message -- but that would not b

Re: Risks of change to UTC

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 : >

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > James Maynard <[EMAIL PROTECTED]> writes: : > : ones position using sight reduction tab

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > James Maynard <[EMAIL PROTECTED]> writes: : > : ones position using sight reduction tab

Re: Risks of change to UTC

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

Re: Risks of change to UTC

In message: <[EMAIL PROTECTED]> Neal McBurnett <[EMAIL PROTECTED]> writes: : These astronomical and navigation systems currently get inputs of time : from all sorts of other systems and people: other instruments, other : computers, sub-contractors, etc. Changing the meaning of UTC woul

Re: Internet-Draft on UTC-SLS

In message: <[EMAIL PROTECTED]> Tim Shepard <[EMAIL PROTECTED]> writes: : > The serious timekeeping people gave up on rubberseconds in 1972 and : > I will object with all that I can muster against reinventing them : > to paste over a problem that has a multitude of correct solutions. :

Re: Internet-Draft on UTC-SLS

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 ha

Re: Internet-Draft on UTC-SLS

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,

Re: Fixing POSIX time

In message: <[EMAIL PROTECTED]> Markus Kuhn <[EMAIL PROTECTED]> writes: : Poul-Henning Kamp wrote on 2006-01-19 17:56 UTC: : > >For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. : > : > I chose the time when TAI became constant rate so that : > all the rubber sec

Re: the GPS impending leap second bit

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 befo

Re: Internet-Draft on UTC-SLS

In message: <[EMAIL PROTECTED]> Markus Kuhn <[EMAIL PROTECTED]> writes: : "M. Warner Losh" wrote on 2006-01-19 16:58 UTC: : > > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt : > The biggest objection that I have to it is that NTP serve

Re: Fixing POSIX time

I like this idea as well... Poul, maybe we should implement this on FreeBSD. I'd suggest "working_time_t" or "correct_time_t" as the name of the type to replace "time_t" which would be deprecated. :-) Warner

Re: Internet-Draft on UTC-SLS

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. n

Re: The real problem with leap seconds

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 agre

Re: The real problem with leap seconds

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 constan

Re: The real problem with leap seconds

From: Mark Calabretta <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] The real problem with leap seconds Date: Tue, 17 Jan 2006 11:15:09 +1100 > On Fri 2006/01/13 12:32:27 +1100, Mark Calabretta wrote > in a message to: Leap Seconds Issues > > >So if asked for a definition I would say that "UTC (post

Re: Report of Leap Second Problem with GPS Data

In message: <[EMAIL PROTECTED]> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: : In message <[EMAIL PROTECTED]>, Rob Seaman writes: : >On Jan 13, 2006, at 6:26 AM, Richard Langley wrote: : : >I won't claim to know the intrinsic importance attached to this. : >Critical systems may depen

Re: The real problem with leap seconds

From: Ed Davies <[EMAIL PROTECTED]> > Markus Kuhn wrote: > > Ed Davies wrote on 2006-01-13 11:45 UTC: > > > >>The use of the 23:59:60 notation is described in ISO 8601. > >>Is it also specified in TF.460? > > > > > > It originally comes from ITU-R TF.460, which is a standard for radio > > time sign

Re: The real problem with leap seconds

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 +

  1   2   >