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=c2ecbc9a8262595b27f7... 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.