[tz] make rearguard_tarballs fails on macOS

[Paul Eggert]

On 10/17/20 2:28 PM, Robert Elz wrote:

> still pondering the
> real need (blind obedience to what POSIX mandates is not a goal of the
> project - there are several places where we simply refuse).

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

If POSIX requires a minor extension to NetBSD's current behavior, as is the case 
here, it should be an easy call anyway: just do it, might as well be compatible.

> Our "human format" is much more flexible than that, it allows stuff like
> "midnight tomorrow" or "three weeks ago" (or "3 weeks ago"), and further

Yes, that's like Gnulib. The formats parse_datetime accepts are documented here:

https://www.gnu.org/software/coreutils/manual/coreutils.html#Date-input-formats
>    | and if I had been part of the POSIX deliberations I would have
>    | insisted that it also allow " " instead of "T".
> 
> It does.   At least in touch:

Thanks, I missed that detail.

> We extend that by allowing less than 4 Y digits, so (as meaningless as
> it is) '513-04-23 16:20:23Z' means some April date in the Dark Ages.

parse_datetime supports this syntax as well, though many filesystems don't work 
with those dates so 'touch' doesn't work properly. The Linux kernel tradition 
here seems to be to turn out-of-range timestamps into representable extrema, 
which is not a good thing if you ask me (should fail with EOVERFLOW).

> We don't allow BC though...

parse_datetime doesn't go below year 0.

> We also ignore the fraction (in all formats
> where it is permitted)

parse_datetime parses fractions down to nanosecond precision.

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