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
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
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:
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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,
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
22 matches
Mail list logo
