On Jan 20, 2014, at 10:43 AM, Warner Losh i...@bsdimp.com wrote:
[*] An interesting side note about days: The ancient Egyptians regarded light
and night as two separate realms rather than as being two halves of the same
day. The notion of the synodic day thus dates only from the new kingdom,
Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 52dc19ff.9499.11a39...@dan.tobias.name, Daniel R. Tobias
writes:
When I'm making an advance dinner reservation for 7 PM on October 1,
2014 in New York City, I expect that [...]
That used to be the sensible party position, but it
Warner Losh i...@bsdimp.com wrote:
On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:
The basis of my understanding is that UTC is a timescale that:
-progresses at a rate of the second (SI) and has done so since
1972-01-01.
-is expressed as a count in the form of date, hours,
On Jan 20, 2014, at 10:27 AM, Tony Finch wrote:
Warner Losh i...@bsdimp.com wrote:
On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:
The basis of my understanding is that UTC is a timescale that:
-progresses at a rate of the second (SI) and has done so since
1972-01-01.
-is
On 18 Jan 2014 at 19:51, Warner Losh wrote:
Of course, the 6 month window does make it impossible to compute a time_t for
a known
interval into the future that's longer than 6 months away...
What are the applications that actually need to schedule events more
than 6 months in the future
employ in searches.
Gerard Ashton
-Original Message-
From: leapsecs-boun...@leapsecond.com
[mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Daniel R. Tobias
Sent: Sunday, January 19, 2014 10:35 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Future time
On 18 Jan 2014 at 19
On Jan 18, 2014, at 10:16 PM, Tom Van Baak wrote:
The problem is that all applications should care about leap seconds.
It is a part of the time standard (UTC) that is papered over in POSIX time_t.
This is a false partitioning, and what causes the probelms.
Warner,
All applications
On Jan 19, 2014, at 8:34 AM, Daniel R. Tobias wrote:
On 18 Jan 2014 at 19:51, Warner Losh wrote:
Of course, the 6 month window does make it impossible to compute a time_t
for a known
interval into the future that's longer than 6 months away...
What are the applications that actually
On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
That's what I mean by all applications (computer applications)
should care. Otherwise we get the two-tier system we have now where
leap seconds are such second class citizens applications wanting to
get them right have to jump through
In message 20140119164807.ga19...@ucolick.org, Steve Allen writes:
If the leap seconds were placed into a similarly inconsequential part
of the interfaces then the applications could be similarly wrong about
leap seconds yet life would go on.
They are. It does. So far.
--
Poul-Henning Kamp
On Jan 19, 2014, at 9:48 AM, Steve Allen wrote:
On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
That's what I mean by all applications (computer applications)
should care. Otherwise we get the two-tier system we have now where
leap seconds are such second class citizens
Daniel R. Tobias d...@tobias.name wrote on Sun, 19 Jan 2014
at 10:34:41 -0500 in 52dbf091.26529.1101b...@dan.tobias.name:
What are the applications that actually need to schedule events more
than 6 months in the future that need to be precisely synchronized to
civil time at a resolution of
On 19 January 2014 15:34, Daniel R. Tobias d...@tobias.name wrote:
On 18 Jan 2014 at 19:51, Warner Losh wrote:
Of course, the 6 month window does make it impossible to compute a time_t
for a known
interval into the future that's longer than 6 months away...
What are the applications that
On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:
On 19 January 2014 15:34, Daniel R. Tobias d...@tobias.name wrote:
On 18 Jan 2014 at 19:51, Warner Losh wrote:
Of course, the 6 month window does make it impossible to compute a time_t
for a known
interval into the future that's
, 2014 10:35 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Future time
On 18 Jan 2014 at 19:51, Warner Losh wrote:
Of course, the 6 month window does make it impossible to compute a
time_t for a known interval into the future that's longer than 6 months
away...
What
On Sat, 18 Jan 2014 19:51:33 -0700, Warner Losh wrote:
On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
Those applications which do care about leap seconds can determine
how to handle them in whatever way those applications feel is
best.
The problem is that all
In message 52dc19ff.9499.11a39...@dan.tobias.name, Daniel R. Tobias writes:
When I'm making an advance dinner reservation for 7 PM on October 1,
2014 in New York City, I expect that [...]
That used to be the sensible party position, but it breaks down
in heaps once you start to schedule
John Hawkinson jh...@mit.edu wrote:
Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
August 1, 2014.
Then a leap second happens.
If my calendar software changes my event to start at 2:59:59pm
Scenarios like the above are precisely the reason why I, Markus Kuhn
and
On Jan 19, 2014, at 1:58 PM, Michael Spacefalcon wrote:
John Hawkinson jh...@mit.edu wrote:
Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
August 1, 2014.
Then a leap second happens.
If my calendar software changes my event to start at 2:59:59pm
Scenarios
Most recent posts have tried to disect the past. This is about the use
of time now and in the future.
_*UTC and Leap Seconds*_
The basis of my understanding is that UTC is a timescale that:
-progresses at a rate of the second (SI) and has done so since
1972-01-01.
-is expressed as a
On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:
Most recent posts have tried to disect the past. This is about the use of
time now and in the future.
UTC and Leap Seconds
The basis of my understanding is that UTC is a timescale that:
-progresses at a rate of the second (SI) and has
Warner Losh i...@bsdimp.com wrote:
|Leap seconds are evil and must die, leaving alignment to the \
You know, i shouldn't speak up here; but what i am missing as
a C++/C/ programmer is the possibility to actually know the true
context, and work with it. I.e., clock_gettime(CLOCK_TAI) and
On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
Those applications which do care about leap seconds can determine
how to handle them in whatever way those applications feel is
best.
The problem is that all applications should care about leap seconds. It is a
part of the
The problem is that all applications should care about leap seconds.
It is a part of the time standard (UTC) that is papered over in POSIX time_t.
This is a false partitioning, and what causes the probelms.
Warner,
All applications should care? It's that going a bit too far? What, are you
24 matches
Mail list logo
