Re: timestamp resolution

[Eli Zaretskii]

> Date: Thu, 3 May 2007 23:20:31 +0100
> From: "James Youngman" <address@hidden>
> Cc: address@hidden,
>       "address@hidden" <address@hidden>
> 
> [ CC += address@hidden ]
> 
> On 5/3/07, Ulrich Drepper <address@hidden> 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 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-DOS epoch and the Unix epoch is evenly divisible by 2 seconds (I
> think; though there were 9 leap seconds in the 1970s, hmm...).  But
> might there be an exception I can't immediately recall?  Quite
> probably.

Could you please explain why did you CC the bug-make list, and why you
mention MS-DOS?  The above addition to `pathconf', when introduced,
will be only supported on systems that use glibc, is that right?  So
MS-DOS is not relevant, even if GNU Make uses _PC_TIMESTAMP_RESOLUTION.

Btw, the Windows epoch (on NTFS volumes) is 1601.  But that probably
doesn't matter, either, as glibc is not used.