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-form...
| 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.