[tz] make rearguard_tarballs fails on macOS

[Robert Elz]

    Date:        Sun, 18 Oct 2020 14:37:57 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <1437ae48-9d51-c956-9b77-11ae29cbe2a1 at cs.ucla.edu>


  | A better way to do it is to generate an internal format that
  | tells you how much precision is in the timestamp.

Yes, I'd considered that for other reasons in the past (primarily as a
defence mechanism against people who insist in generating as much precision
as they seem able to produce, in effect getting semi-random digits after
a while).   But creating yet another timestamp format isn't on my agenda
right now.

  | Since text timestamps almost invariably use base 10 for
  | subsecond information,

Yes, bintime was designed to deal with high res computer clocks,
which are binary, not decimal (which is why the "in kernel only"
remarks - by the time this info has escaped the kernel any high precision
accuracy it once held has been lost in the random nature of the
processing).

  | the output of the timestamp parser should do likewise,

Yes, there's something in that, and it may be that I might use timespec
instead of bintime for that reason.

  | and should say how many digits were in the input.

but I doubt I would be inventing a new format to allow that, and if
I were it would most probably be a bignum type format, so that it can
represent arbitrary precisions and not be limited to the number of bits
that were considered sufficient at the time the format was created.

I think we have drifted a bit far off topic, and well out of the realm
of civil timezones however.

kre