[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils
Subject:    Re: [coreutils] Re: [PATCH 2/2] stat: print timestamps	to	full	resolution
From:       Pádraig_Brady <P () draigBrady ! com>
Date:       2010-10-21 15:23:11
Message-ID: 4CC05ADF.3000909 () draigBrady ! com
[Download RAW message or body]

On 21/10/10 15:49, Eric Blake wrote:
> On 10/21/2010 08:42 AM, Pádraig Brady wrote:
>>> Or use '.' rather than ':' which also has the
>>> advantage of being backward compat with older stats,
>>
>> To clarify, coreutils<= 8.5 output these timestamps
>> using an int format internally, and so ignored any specified precision.
> 
> Not quite:
> 
> $ stat -c%0.20X .
> 00000000001287615247

Fair enough, but inconsequential to the special case (%.X) we're talking about.

> 
>> coreutils 8.6 treats these timestamps as strings and
>> therefore %.X will not output anything which is a pity,
>> but if we're considering making 8.6 "special" in it's
>> handling of %[WXYZ], then perhaps this is OK.
> 
> I'm still wary of special-casing precision like this; should it behave
> more like printf()s %.d or %.f?

> What you are arguing for is that %X has
> no . or subsecond digits, %.X has nine subsecond digits

Right

> but what about %.*X?

Well that's a separate but related issue.
Currently we're treating like %.s which is a little confusing
as one might guess first that %.f was being used. Using %s
doesn't allow getting millisecond resolution for example.
Also this is another backwards compat issue as we previously used %.j

> At this point, I'm thinking that %:X is nicer than %.X, to avoid
> these types of confusion, and given that date(1) already supports %:z.

Yep, that avoids the issue, but means one can use "%.X" to mean:-
get the best resolution timestamp available, and have it work
on all versions of coreutils (except 8.6 which may be deemed "special").

Jim's suggestion of splitting the nanoseconds away from %[WXYZ]
altogether, elsewhere in this thread, is the most flexible and compatible,
albeit not as discoverable.

cheers,
Pádraig.


[prev in list] [next in list] [prev in thread] [next in thread]