Jim Meyering wrote: > Eric Blake wrote: > >> On 10/21/2010 08:09 AM, Andreas Schwab wrote: >>> Eric Blake<[email protected]> writes: >>> >>>> On 10/21/2010 03:22 AM, Andreas Schwab wrote: >>>>> >>>>> >>>>> Jim Meyering<[email protected]> writes: >>>>> >>>>>> And besides, with coreutils-8.6 already released, reverting the >>>>>> change is no longer an option. >>>>> >>>>> Why? I'm pretty sure more breakage will pop up over time. >>>> >>>> How would you propose 'fixing' it? >>> >>> Add a flag character, eg. %.X. >> >> %.X is no good, since we already support %.1X (that is, all printf() >> flags should keep their existing printf() meaning). But Jim's proposal >> of %:X for extended stat info, especially given how date already >> supports %:z for extended timezone formatting, makes sense to me. In >> fact, %.3:X might be a nice way to request that the result be >> displayed in milliseconds, although Jim's proof of concept patch >> didn't cover that aspect. > > An alternative would be to leave %X, %Y, etc. as the only > operators that print seconds-since-epoch, and let the new %:X > print the nanoseconds part of the associated time. > > Then, to get full seconds.nanoseconds, you'd use a format like %X.%:X > and if you want only milliseconds, you'd use %X.%3.3:X
Oops. I forgot to zero-pad. Otherwise, with < 100,000,000ns in the first case or < 100 in the 2nd, and the above would print invalid numbers. This is the right way: To get full seconds.nanoseconds, you'd use a format like %X.%0:X and if you want only milliseconds, you'd use %X.%03.3:X
