checkout --tar: mtime=0 is problematic for some software

Summary

Creating tar archives with bst artifact checkout --tar ... results in an archive where all the mtimes are set to zero.

There is more than one example where files with an mtime of zero are treated as non-existant by other software. e.g.

• This issue on ninja, "Files with zero mtime are treated as nonexistent"
• This code in Template Toolkit.

Steps to reproduce

    # Make our archive and get any file out of it:
    bst artifact checkout --integrate --deps build --tar sysroot.tar target.bst
    tar xf sysroot.tar ./any_file.txt

    stat ./any_file.txt | grep Modify
    # Modify: 1970-01-01 00:00:00.000000000 +0000

    stat --format '%n mtime: %Y' ./any_file.txt
    # ./some_file.txt mtime: 0

What is the current bug behavior?

All the mtimes are zero.

What is the expected correct behavior?

If all the mtimes are set to a specific value, it is non-zero.

Possible fixes

Change the default arguments of export_to_tar from mtime=0 to mtime=1.

Other relevant information

The OSTree project project seems to have an intention to move to an mtime of '1':

For this reason, OSTree acts as though all timestamps are set to time_t 0, so that comparisons will be considered up-to-date. Note that for a few releases, OSTree used 1 to fix warnings such as GNU Tar emitting "implausibly old time stamp" with 0; however, until we have a mechanism to transition cleanly to 1, for compatibilty OSTree is reverted to use zero again.

• BuildStream version affected: /milestone %BuildStream_v1.2