On 10 May 2007, at 20:42, Joseph M Gwinn wrote:
The POSIX.1 standard is very specific, and each and every word was
hard-fought. I would parse it (and the corresponding Rationale) very
slowly and carefully. Even the things not said are important.
There is no intent to put astronomical or attos
Hans,
Hans Aberg <[EMAIL PROTECTED]> wrote on 05/10/2007 09:09:59 AM:
> On 9 May 2007, at 16:30, Joseph M Gwinn wrote:
>
> > In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an
> > unspecified offset because POSIX counts ~SI seconds regardless of
> > astronomy and thus leap anyt
On 10 May 2007, at 15:29, Giacomo A. Catenazzi wrote:
I think the specs ignore the issue, so it is only accurate within
a couple of ten seconds. I figure typical system just ignore the
leap seconds from the epoch, and adjusts the internal clock on the
first lookup after the time server has
Hans Aberg wrote:
On 9 May 2007, at 16:30, Joseph M Gwinn wrote:
In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an
unspecified offset because POSIX counts ~SI seconds regardless of
astronomy and thus leap anything.
I think the specs ignore the issue, so it is only accurate
On 9 May 2007, at 16:30, Joseph M Gwinn wrote:
In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an
unspecified offset because POSIX counts ~SI seconds regardless of
astronomy and thus leap anything.
I think the specs ignore the issue, so it is only accurate within a
couple o
On 9 May 2007, at 16:45, Donn Terry wrote:
It is simply NOT possible to satisfy both the
timestamp-for-system-events needs of the real time people (who really
want attosecond resolution -- maybe only 10s or 100s, but really tiny)
and the huge range needed for astronomical needs. The system
ti
x" we'll have.
Donn
-Original Message-
From: Hans Aberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 4:51 AM
To: [EMAIL PROTECTED]
Cc: bug-make@gnu.org
Subject: Re: timestamp resolution
I made a post to the moderated Usenet newsgroup sci.astro.research,
"Ju
Hans,
Hans Aberg <[EMAIL PROTECTED]> wrote on 05/09/2007 07:51:16 AM:
> I made a post to the moderated Usenet newsgroup sci.astro.research,
> "Julian day numbers and leap seconds", and there are so many
> responses, I cannot summarize them here.
>
> The question of finding a good time suitable
I made a post to the moderated Usenet newsgroup sci.astro.research,
"Julian day numbers and leap seconds", and there are so many
responses, I cannot summarize them here.
The question of finding a good time suitable for distributed
computing as well as in astronomy and sciences, plus syncing
There is a document about JD, as well other time scales, at
http://www.ucolick.org/~sla/leapsecs/timescales.html
Apparently, JD does not take into account leap seconds (see quote
below), which makes it suitable for use in distributed computer
systems. If one does not like the high numbers o
On 4 May 2007, at 07:25, Larry Dwyer wrote:
At 07:21 PM 5/3/2007, [EMAIL PROTECTED] wrote:
> Having a clock number implies that the clock can be used with
> clock_gettime() or even timer_create(). There is no reason to
assume
> that there is such a clock available.
However, if there is such
(Dropping the austin-group list, since this email just explains
context doubtless already known to that list)
On 5/4/07, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
Could you please explain why did you CC the bug-make list, and why you
mention MS-DOS?
Make deals with the timestamps of files, and
> Date: Thu, 3 May 2007 23:20:31 +0100
> From: "James Youngman" <[EMAIL PROTECTED]>
> Cc: bug-make@gnu.org,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>
> [ CC += bug-make@gnu.org ]
>
> On 5/3/07, Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> > On today's call we agreed on the following propos
[ CC += bug-make@gnu.org ]
On 5/3/07, Ulrich Drepper <[EMAIL PROTECTED]> wrote:
On today's call we agreed on the following proposal (names are negotiable):
1. add _PC_TIMESTAMP_RESOLUTION
[ for those recently joining, this would be a pathconf() configuration
option which returns the filesyste
14 matches
Mail list logo
