Make touch logic in file_metadata.sh more portable

1. Set `TZ=UTC`. This is for accuracy even more than portability;
   it is worthwhile on its own. The effect is not implied by any of
   the environment variables we set when running fixtures, and it
   has not been included in the date strings, though that could be
   done. Doing it this way, rather than by adding something to the
   date strings, makes it slightly easier to verify portability by
   examination. Without `TZ=UTC` or specifying the time zone in the
   date string, an unspecified time zone may be used; this may be
   the local time zone, but even if so, that will be incorrect
   since Unix timestamps stored in filesystem metadata are
   implicitly assumed UTC, so the extreme values we hard-code must
   be interpreted that way to have their intended effects.

2. Stop attempting to specify fractions of a second, which often
   (always?) does not work better and which requires more complex
   logic to express because a fallback is needed for some systems.
   The test currently using this fixture does not appear to need or
   significantly benefit from the most extreme possible dates, even
   if fractional values facilitate that, and the output of `stat`
   implementations that show fractional values do not seem to ever
   show different values when they are used with `touch`.

3. Having made what was the fallback logic (introduced in #1496)
   the primary approach, add a fallback touch command for `future`
   to handle how some systems with 32-bit `time_t` remain in use
   and have `touch` commands that treat too-large values as hard
   errors. The test systems where this was produced are a 32-bit
   x86 Ubuntu 18.04 LTS (Extended Security Maintenance) and a
   64-bit x86 OmniOS system (where even the 64-bit GNU `touch`
   binary fails with an error if the fallback is not used).

See the rewritten comment for details.

Author: EliahKagan

gix-index/tests/fixtures/file_metadata.sh

@@ -1,9 +1,13 @@
 #!/usr/bin/env bash
 set -eu -o pipefail
 
-# Attempt to create files with the latest and earliest possible dates for ext4. Nanoseconds are
-# special there, but not usually on other filesystems. In some touch implementations, the format
-# may be rejected. So if a command fails, we try again with a more extreme date that is out of
-# range, because some implementations will clip it to the edge of the range (but they may fail).
-touch -d '2446-05-10 22:38:55.111111111' future || touch -d '2446-05-11 22:38:56' future
-touch -d '1901-12-13 20:45:52.222222222' past || touch -d '1901-12-13 20:45:52' past
+# Attempt to create files with the latest and earliest possible 64-bit dates/times for ext4.
+# Although nanoseconds are stored in ext4, specifying fractions of a second does not seem to make
+# this work better, and omitting them allows the commands that attempt to set these dates to
+# succeed on more systems. While we use a portable format, if the system rejects a future date as
+# out of range with an error (and touch does not automatically retry with an allowed date) then it
+# can fail. In this case, we try again with a much more moderate date: the greatest value that can
+# in practice always parse to fit within a 32-bit signed time_t. This is subject to change to
+# support changed or new tests. It will also become less useful in the near future (after 2038).
+TZ=UTC touch -d '2446-05-10 22:38:55' future || TZ=UTC touch -d '2038-01-19 03:14:07' future
+TZ=UTC touch -d '1901-12-13 20:45:52' past