On Jan 20, 2014, at 10:43 AM, Warner Losh 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,
While one c
On Jan 20, 2014, at 10:27 AM, Tony Finch wrote:
> Warner Losh 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 expr
Warner Losh 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, minutes an
Poul-Henning Kamp 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 breaks dow
Warner Losh wrote:
> Second, you are breaking one of the aspects of time
Wrong - I simply assert other people's right to define the word "time"
in a different way than you do. There exist perfectly valid definitions
of the word "time" which are distinct from "interval time", and which
are not b
On Jan 19, 2014, at 1:58 PM, Michael Spacefalcon wrote:
> John Hawkinson 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
John Hawkinson 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 Google Lea
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
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
ias
Sent: Sunday, January 19, 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
On 19 Jan 2014 at 11:07, Gerard Ashton wrote:
> Date/time manipulation software sometimes converts a date expressed as day,
> month, year, time to a number, as in Excel. If the number counts leap
> seconds, and an event is more than 6 months in the future, it will be
> necessary to search for the
On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:
> On 19 January 2014 15:34, 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
On 19 January 2014 15:34, 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
Daniel R. Tobias 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 under a seco
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 app
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 K
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 thro
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 ac
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" applica
"
Excel may silently 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: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 t
> 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
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
Warner Losh 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
clock_gettime(CLOCK_UTC
Stephen Scott said:
> 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, minutes and
> seconds;
> -is continuous other than the discontinui
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) an
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 cou
27 matches
Mail list logo
