[tz] make rearguard_tarballs fails on macOS

[Paul Eggert]

On 10/17/20 1:46 AM, Robert Elz wrote:

> 	touch -md 2020-10-12T22:53:00Z file
> 	touch: Could not parse `2020-10-12T22:53:00Z'
> 
> With the 'T' in there, it is no longer a "human" format, but a
> standard one, and isn't recognised - I guess I could look at fixing
> parsedate(3) to handle that, but I'm not sure it is really warranted,
> parsedate() is a horrible ugly chunk of barely fuinctional code, and
> your updated patch will work fine.

We went through *exactly* the same thought process in the Gnulib parse-datetime 
function, which is also a mess (perhaps even worse than NetBSD parsedate :-). 
However, in 2011 the POSIX requirement eventually got us to parse the form with 
the "T" in it, even though it's ugly and unreadable. I'm glad J.T. Conklin wrote 
the patch:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c2ecbc9a8262595b27f741e41375d06213a30fb6

so that I didn't have to.

By the way, the "human" format is specified in RFC 3339 section 5.6:

https://tools.ietf.org/html/rfc3339#section-5.6

which allows a space. This was at my insistence. That "T" is bad for human 
readability, and readability is important, and if I had been part of the POSIX 
deliberations I would have insisted that it also allow " " instead of "T".

GNU 'date' supports the "human" format as an extension to POSIX, and I assume 
NetBSD 'date' will continue to do so too.