bug#35032: date ISO 8601 / RFC 3339 formats
Hi, On Thu, Mar 28, 2019 at 10:43:42AM -0700, Paul Eggert wrote: > On 3/28/19 10:20 AM, Nicolas Mailhot wrote: > > Would it be possible to make them both optional in --rfc-3339, and > > both mandatory in --iso-8601 ? > > Sorry, I don't understand what you're proposing, specifically. Can you > say exactly what you want, with specific calls to 'date' and what you > want the output to look like, and why? Sadly, you stripped too much of the original mail. I'll repeat the relevant parts of that mail: On Thu, Mar 28, 2019 at 06:20:14PM +0100, Nicolas Mailhot wrote: > A long, long time ago, [...] > Unfortunately, coreutils managed to make both of those incompatible > with the W3C iso-8601 profile lots of software languages use: > > 1. The W3C profile mandates T as time separator, and ":" as > hour/minutes separator > 2. RFC 3339 makes both optional > > Then, logically, date removed the ":" for its --iso-8601 option, > $ date --iso-8601=seconds > 2019-03-28T18:09:47+0100 ^^ there should be a ':' for W3C compatibility > and then removed T from its --rfc-3339 option > $ date --rfc-3339=seconds > 2019-03-28 18:10:11+01:00 ^ there should be a 'T' for W3C compatibility > [...] Nicolas asks for an ISO 8601 compatible format using both a 'T' as separator between date and time, and a ':' as separator between hours and minutes in the timezone designator, as well as the other contents that are identical in --iso-8601 and --rfc-3339. >From looking at https://www.w3.org/TR/NOTE-datetime, the important part is using both 'T' and a TZD with ':' in the middle, the other variability (e.g. minutes, seconds, fractional seconds as decimals) can be chosen as fits. Thanks, Erik -- I do like the 24 hour a day development process. I can describe a problem, go to sleep, and have the answer in my mailbox with my first cup of coffee. -- Dave Täht
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
tags 34488 fixed close 34488 stop Hello, The original request of "sort --limit" resulted in an improved "env" with options new options, which was included in the recent version 8.31. I'm therefor closing this item. -assaf
bug#34700: rm refuses to remove files owned by the user, even in force mode
tags 34700 notabug severity 34700 wishlist retitle: rm: add new --force option deal with read-only directories stop Hello, As explained by several people in this thread, This is not a bug in "rm -f", but the mandated behavior. Bob and others provided work-arounds ( https://bugs.gnu.org/34700#17 ). As for adding a new "--really-force" option (https://bugs.gnu.org/34700#11) - I'm marking this as a wish-list item. -assaf
bug#34825: New fails in tests/{misc,cp} in v8.31 on OpenIndiana
retitle 34825 OpenIndiana: tests/{misc,cp} fail in v8.31
stop
Hello,
On 2019-03-11 1:10 a.m., Michal Nowak wrote:
on OpenIndiana 2018.10 (illumos kernel) the test suite has three new
fails in v8.31 (amd64) compared to v8.30:
FAIL tests/misc/timeout-parameters.sh (exit status: 1)
FAIL tests/cp/no-deref-link1.sh (exit status: 1)
FAIL tests/cp/no-deref-link2.sh (exit status: 1)
The two 'ln' related bugs might be the same as
this item: https://bugs.gnu.org/34894
with the fix committed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=3e0dff3925b5e521cae468087950e85b60002d1c
Can you check whether it solved the issue on OpenIndiana as well?
-assaf
bug#34894: Another solaris 10 ln issue on 8.31
tags 34894 fixed close 34894 stop On 2019-03-17 3:17 p.m., John Marino wrote: On 3/17/2019 15:28, Paul Eggert wrote: John Marino wrote: After applying the recent patch to 8.31 ln to fix functionality on solaris 10, I saw some improvement but I think there's something else wrong. Thanks. Could you please try the attached patch, which I installed on master? Installed here: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=3e0dff3925b5e521cae468087950e85b60002d1c Okay, that seems to fix the regression on ln. Thanks for confirming, I'm closing this bug. -assaf
bug#34923: Message/race bug in 'dd'
tags 34923 notabug severity 34923 wishlist retitle 34923 dd: add messages about IO errors stop On 2019-03-19 9:44 p.m., Paul Eggert wrote: Daniel A. Gauthier wrote: NOTICE that the "+nn" value on the line is always one off. It says +0 after the first error, +1 after the second, etc. until the correct count of error/short blocks is given at the end. The count is supposed to just count short blocks, not errors. This is a POSIX requirement. I installed the attached documentation patch to try to make this clearer. The documentation improvement was added here: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=59e01d13e600be0d2c7f08f3aff8cf11936b3ea1 Perhaps dd should output a separate line to stderr that summaries I/O errors; it could do that without violating POSIX. Marking this as a wishlist item. -assaf
bug#34968: (no subject)
tags 34968 notabug close 34968 stop On 2019-03-24 9:12 a.m., Bernhard Voelker wrote: I don't know Dutch, but this looks to me like the regular output of "sha256sum --help" from an older version of coreutils (<8.25, because the --ignore-missing option is not yet there). What is wrong with it? With no further replies, I'm closing this bug. -assaf
bug#34988: mv: check before asking users useless questions
tags 34988 notabug severity 34988 wishlist retitle 34988 mv: omit useless 'overwrite?' question stop On 2019-03-25 4:47 p.m., Paul Eggert wrote: On 3/24/19 11:05 PM, 積丹尼 Dan Jacobson wrote: $ mv a b mv: overwrite 'b'? y mv: cannot overwrite non-directory 'b' with directory 'a' User thinks well why didn't you check before uselessly asking me? POSIX requires the useless question. That being said, the question could be omitted in the case you describe, if POSIXLY_CORRECT is not specified. Marking this as a wishlist item. -assaf
bug#34905: uname: -i/-p returns "unknown"
tags 34905 moreinfo retitle 34905 uname: -i/-p returns "unknown" stop On 2019-03-19 9:48 p.m., Paul Eggert wrote: Wellington Almeida wrote: When using the -p and -i functions in the uname command I noticed that it returned an unknown result, can this be a bug? It could be a bug in the uname command, but more likely it's a kernel bug. Try running "strace uname -pi".
bug#35032: date ISO 8601 / RFC 3339 formats
severity 35032 wishlist retitle 35032 date: adjust rfc8601/3339 formats to W3C standard stop On 2019-03-28 11:20 a.m., Nicolas Mailhot wrote: Would it be possible to make them both optional in --rfc-3339, and both mandatory in --iso-8601 ? Or add a --w3c option that conforms to the W3C profile? This is all so sad… Some languages like Go do no understand neither of date's output, because they follow the W3C profile. I'm marking this as a "wishlist" item. For reference, here are previously similar requests: https://bugs.gnu.org/6132 - date: --rfc-3339=TIMESPEC option doesn't print 'T' https://bugs.gnu.org/6453 - date -- Add new options for ISO 8601 date formats (-O) https://bugs.gnu.org/14097 - date: add parsing support for ISO 8601 basic format -assaf
bug#35032: date ISO 8601 / RFC 3339 formats
On 3/28/19 10:20 AM, Nicolas Mailhot wrote: > Would it be possible to make them both optional in --rfc-3339, and > both mandatory in --iso-8601 ? Sorry, I don't understand what you're proposing, specifically. Can you say exactly what you want, with specific calls to 'date' and what you want the output to look like, and why?
