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:
I've been lurking on this list for a few months now.
About 15 years ago I was playing with NTP on 4.3 BSD unix.
I remember thinking then that Posix was making a serious error in
specifiying that the time_t returned by time() or in the .tv_sec
field of the structure returned by gettimeofday()
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
On Wed 2005/08/31 07:30:17 +0200, Poul-Henning Kamp wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
The closest I'll get is Copenhagen Denmark :-(
If noone can present your arguments in person then we did also invite a
submission. Given the amount of energy expended on this list (far too
much
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
10 matches
Mail list logo
