RFC: Change mtree nsec handling?

[Maxim Sobolev]

Tim Kientzle wrote:
> In looking at interoperability between libarchive's
> mtree support and the mtree(8) program, I found
> that mtree formats timestamps rather strangely.
> 
> For example, a timestamp of 1233295862.000001
> (1233295682 seconds and 1000 nanoseconds)
> will be printed like this by mtree:
>    time=1233295862.1000
> Unsurprisingly, the mtree parsing works the same
> way in reverse.
> 
> Basically, mtree is printing (and reading) the time
> as whole seconds and nanoseconds separated by a period,
> which 90% of the time is the same as a decimal
> floating-point number of seconds, but not the other
> 10% of the time.  This is not documented in mtree.8.
> I was quite surprised by it.
> 
> The attached patch changes this to use a more conventional
> notation (although the patch could use a little more tweaking
> to handle >9 digits after the decimal point).
> 
> Any concerns about this?

Given the age of mtree(8) I guess there are lot of existing mtree specs 
out there who rely on this behavior. Therefore, IMHO the right thing to 
do would be either note this in the documentation and let it be, or mark 
"time" keyword as depreciated and add some new keyword for example 
"timestamp". The new keyword will be generated by default by mtree(8) 
instead of "time" and will do the right thing. Then, in few years from 
now "time" could be deorbited.

-Maxim