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.