bug#18328: can't say date -d '8pm -0500' though other combos work

I took a look at this bug, and believe I have a patch that will resolve it. $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500' date: parsed date part: (Y-M-D) 2024-01-01 date: parsed time part: 08:00:00pm UTC-05 date: input timezone: parsed date/time string (-05) date: using specified time as s

bug#47243: pr lacks -p

Paul Eggert writes: > On 2025-07-28 10:36, Collin Funk wrote: >> I don't really like the idea of changing '-f' depending on whether >> POSIXLY_CORRECT is defined. So I would prefer this as well. > > On second thought (sorry...) I now think I understand why GNU pr > behaves the way it does. The GN

bug#79113: du --time-styles inconsistencies between manual and behaviour

On Tue, 29 Jul 2025 at 06:12, Pádraig Brady wrote: > > On 28/07/2025 20:13, Pádraig Brady wrote: > > On 28/07/2025 18:49, Nicolas Boichat wrote: > >> I could have been clearer for this last one, I mean that the command > >> line error text for `du` could mention that +FORMAT is supported: > >> > >

bug#79118: CI test failures

Hi Collin, What if you replace setlocale (LC_TIME, "C"); with { xsetenv ("LC_TIME", "C", 1); setlocale (LC_TIME, ""); } ? I'm asking because in localename-unsafe.c, HAVE_LOCALE_NULL is not set on macOS. Does that make any difference? Bruno

bug#79118: CI test failures

Hi Bruno, Collin Funk writes: > The issue is that they return the non-C locale date. The code we use > when --iso-8601 or --rfc-3339 is in use is the following: > > if (use_c_locale) > setlocale (LC_TIME, "C"); > > bool ok = show_date (format, when, tz); > > I wonder if the issue i

bug#79118: CI test failures

Collin Funk writes: >> + case $(date --iso-8601=hours) in >> ++ date --iso-8601=hours >> + fail=1 >> + case $(date --rfc-3339=date) in >> ++ date --rfc-3339=date >> + fail=1 > > My guess is that `date ...` or a separate assignment will be needed > here. Will experiment later. Scratch that, I rea

bug#79113: du --time-styles inconsistencies between manual and behaviour

On 28/07/2025 20:13, Pádraig Brady wrote: On 28/07/2025 18:49, Nicolas Boichat wrote: I could have been clearer for this last one, I mean that the command line error text for `du` could mention that +FORMAT is supported: Comparing du and ls output with a bad timestyle: ``` $ du --time --time-st

bug#79118: CI test failures

Hi Bruno, Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI run reports that the new tests > tests/date/date-ethiopia > tests/date/date-iran > tests/date/date-thailand > fail on OpenBSD and macOS. Thanks for the report. I'll fix them later today. > On OpenBSD, that's expect

bug#79118: CI test failures

Hi Collin, Today's CI run reports that the new tests tests/date/date-ethiopia tests/date/date-iran tests/date/date-thailand fail on OpenBSD and macOS. On OpenBSD, that's expected, because gnulib/lib/strftime.c does not enable the non-Gregorian calendars on that system (because retrieving th

bug#79113: du --time-styles inconsistencies between manual and behaviour

On 28/07/2025 18:49, Nicolas Boichat wrote: I could have been clearer for this last one, I mean that the command line error text for `du` could mention that +FORMAT is supported: Comparing du and ls output with a bad timestyle: ``` $ du --time --time-style=xyz blob du: invalid argument ‘xyz’ for

bug#47243: pr lacks -p

On 2025-07-28 10:36, Collin Funk wrote: I don't really like the idea of changing '-f' depending on whether POSIXLY_CORRECT is defined. So I would prefer this as well. On second thought (sorry...) I now think I understand why GNU pr behaves the way it does. The GNU coding standards[1] say "...p

bug#79113: du --time-styles inconsistencies between manual and behaviour

On Tue, 29 Jul 2025 at 00:07, Pádraig Brady wrote: > > tag 79113 notabug > close 79113 > stop > > On 28/07/2025 15:44, Nicolas Boichat wrote: > > Hi, > > > > Version: env du --version => du (GNU coreutils) 9.7 > > OS: archlinux, x86-64 > > > > The GNU coreutils manual says > > (https://www.gnu.org

bug#47243: pr lacks -p

Pádraig Brady writes: > Reading POSIX more closely I see there is also pause logic for the first page > only: > -f[XSI] [Option Start] Use a for new pages, instead of the > default behavior that uses a sequence of characters. > Pause before beginning the first page if the standa

bug#47243: pr lacks -p

On 2025-07-28 09:06, Stan Marsh wrote: The point is that -f is already taken; it is a synonym for -F. That's a bug in GNU 'pr'. -f is supposed to mean "act like -F but also pause before the first page if standard output is a terminal". See

bug#47243: pr lacks -p

On 2025-07-28 09:23, Pádraig Brady wrote: Yes it's a fair point. We don't want existing scripts that use -f to start pausing unexpectedly. I suppose this is a case for only pausing with -f if POSIXLY_CORRECT env var is set. Although backward compatibility is an issue, the current behavior is c

bug#47243: pr lacks -p

On 28/07/2025 17:06, Stan Marsh wrote: Paul wrote: ThenPádraig Brady wrote: Reading POSIX more closely I see there is also pause logic for the first page only: -f[XSI] [Option Start] Use a for new pages, instead of the ---^^^

bug#79113: du --time-styles inconsistencies between manual and behaviour

tag 79113 notabug close 79113 stop On 28/07/2025 15:44, Nicolas Boichat wrote: Hi, Version: env du --version => du (GNU coreutils) 9.7 OS: archlinux, x86-64 The GNU coreutils manual says (https://www.gnu.org/software/coreutils/manual/coreutils.html#index-_002d_002dtime_002dstyle-1): - "You can

bug#47243: pr lacks -p

Paul wrote: >ThenPádraig Brady wrote: >>Reading POSIX more closely I see there is also pause logic for the first page >>only: >> -f[XSI] [Option Start] Use a for new pages, instead of the ---^^^ (!) >>default >>behavior that uses

bug#47243: pr lacks -p

On 2025-07-27 19:21, Collin Funk wrote: I think that v3 attached should cover everything. In addition to Pádraig's comments, I would add: + a newline character is read from /dev/tty, as required by POSIX Issue + 6. The corresponding long option is --pause. Don't say "Issue 6" as almost

bug#47243: pr lacks -p

On 2025-07-28 07:41, Stan Marsh wrote: Paul Eggert writes: Thanks for looking into that. Unfortunately POSIX says -p should be ignored only if standard output is a terminal, and that newline should -^ Shouldn't this be "ignored unless standard out

bug#79113: du --time-styles inconsistencies between manual and behaviour

Hi, Version: env du --version => du (GNU coreutils) 9.7 OS: archlinux, x86-64 The GNU coreutils manual says (https://www.gnu.org/software/coreutils/manual/coreutils.html#index-_002d_002dtime_002dstyle-1): - "You can specify the default value of the --time-style option with the environment variabl

bug#47243: pr lacks -p

>Paul Eggert writes: >Thanks for looking into that. Unfortunately POSIX says -p should be >ignored only if standard output is a terminal, and that newline should -^ Shouldn't this be "ignored unless standard output is a terminal" ? >be read from /de

bug#47243: pr lacks -p

On 28/07/2025 11:22, Pádraig Brady wrote: On 28/07/2025 03:21, Collin Funk wrote: Hi Paul, Paul Eggert writes: Thanks for looking into that. Unfortunately POSIX says -p should be ignored only if standard output is a terminal, and that newline should be read from /dev/tty, not from standard i

bug#47243: pr lacks -p

On 28/07/2025 03:21, Collin Funk wrote: Hi Paul, Paul Eggert writes: Thanks for looking into that. Unfortunately POSIX says -p should be ignored only if standard output is a terminal, and that newline should be read from /dev/tty, not from standard input. This is so that users can pipe into '