[tz] make rearguard_tarballs fails on macOS
Paul Eggert
eggert at cs.ucla.edu
Sun Oct 18 01:32:39 UTC 2020
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.
More information about the tz
mailing list