[tz] make rearguard_tarballs fails on macOS

[Robert Elz]

    Date:        Sat, 17 Oct 2020 18:32:39 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <9f551f2d-e4d6-97a8-f2f0-e3f83001542f at cs.ucla.edu>

  | The real need in this case is supporting tzdb 2020c (:-).

We supported 2020c already without even noticing this issue, until
I saw Deborah's message, and your reply, and I checked what our touch
allows ... we don't use/generate/... rearguard, and we had already
eliminated pacificnew in 2020b.

  | If POSIX requires a minor extension to NetBSD's current behavior,

It is an ugly hackish extension - ugly because 'T' is also one of the
Military type zone designators, and we support those as well (as part
of supporting e-mail date formats).  A date followed by 'T' might be either
the first part of an ISO8601 format (or the restricted subset of that that
posix expects support for) or a date in the UTC-0700 (or whichever 'T' is)
timezone.   All very ugly to deal with properly.  If ISO had just used a '+'
or '_' or something as the separator, it would have been both more language
neutral ("time" (aka T) should be "Zeit" (aka Z) in German for example,
right, and not an ascii character at all in Thai, Japanese, ...) and much
simpler to deal with issues like these (which is why we supported the format
with the space separator, but not with the 'T' and without writing any code
to explicitly handle it, it was just a date in one of the common forms, a
time in the most common form, and an optional 'Z' zone indicator - combine
those together and the right thing just happens).

  | it should be an easy call anyway: just do it, might as well be compatible.

So, not so easy, but it looks like the "just do it" will happen, especially
since I wrote some code already.   Mostly now just need to check to make
sure nothing else broke while doing that.

  | parse_datetime supports this syntax as well, though many filesystems
  | don't work with those dates so 'touch' doesn't work properly.

That's a different issue, and will go away once everyone is finally
forced into abandoning all uses of 32 bit timestamps, which should
finally happen by the end of this millennium.   Posix doesn't require
support for anything before 1970-01-01 (UTC) or after 2037-12-31 23:59:60
(if there happens to be a leap second then, 23:59:59 otherwise).   Or
maybe it is after 2038-01-01 00:00:00.

  | parse_datetime parses fractions down to nanosecond precision.

If I add this (new function - though parseadate() would then just call
it and ignore the fractional seconds in the result to generate a time_t)
it would most likely be to generate a bintime, which allows down to 1/2^64
of a second (whatever that is in babble-speak - zetaseconds or something).

  | It would be helpful if POSIX would standardize some of these extensions.

You can always submit a defect report, but you're not likely to get
very far unless at least some of the commercial systems support it.

What is really needed for POSIX is to have a better concept of optional
features, "You don't have to support this, but if you do, this is the
way it should be done" type stuff.   That would allow a much simpler
path to adding new facilities than presently exists.

kre