Re: Consensus rather than compromise

2005-09-01 Thread Rob Seaman
On Sep 1, 2005, at 7:46 AM, John.Cowan wrote: The table can be downloaded from http://www.ccil.org/~cowan/zone- changes.txt . Data - cool! Thanks. The first column is the zone name in the form continent/ city (city names are more stable than country or state/province names). Yeah, that's

Re: Consensus rather than compromise

2005-08-31 Thread M. Warner Losh
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

Re: Consensus rather than compromise

2005-08-31 Thread John.Cowan
Steve Allen scripsit: Yet the zoneinfo needs to be updated numerous times per year at unpredictable intervals as a result of arbitrary actions by legislatures all over the world. Indeed, but the user has a substantial incentive to update to the latest data if directly affected by the change:

Re: Consensus rather than compromise

2005-08-31 Thread trey valenta
On Wed, Aug 31, 2005 at 11:14:17AM -0400, John.Cowan wrote: Because there is far too much code that believes, for example, that if you add 86400 to a time_t representing 2005-12-31T00:00UTC, you get a time_t representing 2006-01-31T00:00UTC. Or that if you have a And then your whole office

Re: Consensus rather than compromise

2005-08-31 Thread Ed Davies
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 give any examples of systems which need to follow UTC to sub-second accuracy (running to

Re: Consensus rather than compromise

2005-08-31 Thread M. Warner Losh
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

Re: Consensus rather than compromise

2005-08-31 Thread Rob Seaman
On Aug 31, 2005, at 9:54 AM, M. Warner Losh wrote: : (running to their own little timezone not being good enough), Might I suggest that digs like this make rational discussions difficult? I agree with the general sentiment - after six years we're all a bit over sensitized and perhaps too

Re: Consensus rather than compromise

2005-08-31 Thread Mark Calabretta
On Wed 2005/08/31 07:29:22 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL If such a system were to be adopted, then in future, in order to determine a historical time, the full record of timezone changes would be needed. How is this different than today ? To

Re: Consensus rather than compromise

2005-08-31 Thread John.Cowan
Mark Calabretta scripsit: Currently the timezone offset is essentially fixed for a particular place, yes there are quirks but it's hardly relevant to the argument. If by currently you mean at this very moment, then that's trivially true. If by currently you mean in the last few decades, then

Re: Consensus rather than compromise

2005-08-31 Thread Steve Allen
On Wed 2005-08-31T22:57:42 -0400, John.Cowan hath writ: Fortunately, it's not that bad. All 365 current zones define their LCTs using a list of offsets from a common reference time. The current effort to abolish leap seconds completely violates the subject line of this thread. There is no

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], John.Cowan writes: Rob Seaman scripsit: [B]ut we already agree on a common position that civil time needs to mimic solar time for most purposes. Kashi, Kashi, Kashi. It's interesting that no matter how much we keep telling him otherwise, Rob still claims that we

Re: Consensus rather than compromise

2005-08-30 Thread Peter Bunclark
On Tue, 30 Aug 2005, M. Warner Losh wrote: Leap seconds cost actual companies lots of $$$. I know that I've personally put in about 50 hours to leap second issues since July 1, and others in my company have put in even more in testing, shipping equiptment to the simulator facility, writing

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes: The POSIX definition makes it impossible to correctly handle leap seconds with any complying implementation of the standard, and therefore applications which needs to be *truly* leapsecond compliant, cannot use the standard libraries. So

Re: Consensus rather than compromise

2005-08-30 Thread M. Warner Losh
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

Re: Consensus rather than compromise

2005-08-30 Thread Rob Seaman
[B]ut we already agree on a common position that civil time needs to mimic solar time for most purposes. Kashi, Kashi, Kashi. My apologies - I appear not to be making my point clear (again). Communication is hard - email communication between individuals who have never met face-to-face, all

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: Yes, I assert that we already agree on what I'm saying - or trying to say here. Let's put aside six years of squabbling about details and look at the larger picture. John Cowan and others on the leap seconds suck side of the discussion have often

Re: Consensus rather than compromise

2005-08-30 Thread Mark Calabretta
On Tue 2005/08/30 19:46:51 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL keep the clock as people see it on their wrist [1] in sufficient sync with the light of day through minor acts of timezone adjustments. If such a system were to be adopted, then in future, in

Re: Consensus rather than compromise

2005-08-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: Poul-Henning Kamp wrote: It is not unrelated to why some of us think that changing the definition of UTC is infinitely more possible than changing the rest of the worlds educational level with regards to timekeeping. Not unrelated, simply

Re: Consensus rather than compromise

2005-08-29 Thread Rob Seaman
On Aug 29, 2005, at 10:36 AM, Poul-Henning Kamp wrote: I thought you were busy with your analysis document ? Let's see...rummage, rummage...what did I say? Ah, yes: I'm going to refrain from commenting on the best choices from the decision tree until it nears completion. I don't see that

Re: Consensus rather than compromise

2005-08-29 Thread John.Cowan
Rob Seaman scripsit: I did find it striking, however, that the public confusion being discussed was completely unconnected to issues of precision timekeeping such as leap seconds. Rather, the very definition of civil time was misunderstood, whether by Microsoft or by somebody else. I think

Re: Consensus rather than compromise

2005-08-29 Thread Clive D.W. Feather
John.Cowan said: Rather, the very definition of civil time was misunderstood, whether by Microsoft or by somebody else. I think this greatly overstates the case. Exactly. There was a mere misapplication of labels involved, both in the case of the conference leader (who believes that the

Re: Consensus rather than compromise

2005-08-29 Thread Clive D.W. Feather
Rob Seaman said: The problem here is Microsoft, whose software appears to believe that the current LCT here is GMT Daylight Time. The case has been repeatedly made that since the world tolerates large excursions in civil time such as caused by the varying local Daylight Saving Time policies,

Re: Consensus rather than compromise

2005-08-29 Thread Rob Seaman
On Aug 29, 2005, at 2:12 PM, Clive D.W. Feather wrote: And, by the way, the GMT standard is *NOT* synonymous with UTC; it is (IIRC) UT1. The original UTC standard (i.e., CCIR 460-4) stated: GMT may be regarded as the general equivalent of UT. UT1 and UTC are both representations of