Jim Meyering wrote: > 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
A possible disadvantage of using this approach is that the naive implementation would perform truncation. I.e., using a format of "%X.%3.3:X", a time of N.100999999 would be truncated to N.100 I'm inclined to say: If you care, don't truncate in the first place, or use another tool, e.g., printf, to format the floating point number.
