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
ison of timestamps.
> >
> > The granularity issue has always been with us. While it is known
> > that no finite-resolution timestamp scheme can ensure causal order,
the
> > alternative (a central guaranteed-sequence hardware utility) is
usually
> > impractical, s
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
d timestamps. (IBM sells such a
utility box for use in their transaction systems.) What one can most
easily do is to require much better timestamp resolution as technology
progresses, thus reducing the window of non-causality in such
things as
make.
Different system will require different gra
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
amp scheme can ensure causal order, the
alternative (a central guaranteed-sequence hardware utility) is usually
impractical, so people have always used timestamps. (IBM sells such a
utility box for use in their transaction systems.) What one can most
easily do is to require much better timest
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
files, and - I assume - needs to
have some awareness of the possibility that timestamp resolution
issues will give just-touched files a timestamp which is in the past,
and perhaps a timestamp which is _before_ the time which was current
immediately prior to the filesystem operation.
The above addit
TED]> 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 filesystem timestamp resoluti
returns the filesystem timestamp resolution for a given
file. ]
Is the assumption then that all filesystems record timestamps as
values of the form
(Epoch + N * pathconf(_PC_TIMESTAMP_RESOLUTION)), where Epoch is the
Unix epoch?
I can't think offhand of an exception. The difference between the
MS-D
14 matches
Mail list logo
