bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-21 Thread Eric Blake
POSIX requires the '+' flag in %C to output padding with leading 0, and
additionally to add a +/- indicator if the minimum field width is larger
than 2 bytes.  Thus:

date -d 0001-01-01 +.%+4C.

should produce ".+000.", but currently it produces ".%+4C." because the
+ flag is unimplemented.

See also http://austingroupbugs.net/view.php?id=1184

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org





bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-21 Thread Paul Eggert

Eric Blake wrote:


date -d 0001-01-01 +.%+4C.

should produce ".+000.", but currently it produces ".%+4C." because the
+ flag is unimplemented.

See also http://austingroupbugs.net/view.php?id=1184


Surely this bug should be reported against strftime, not against 'date'. POSIX 
does require that strftime behave that way, but it does not place a similar 
requirement on 'date'.






bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-21 Thread Eric Blake
On 2/21/19 9:37 PM, Paul Eggert wrote:
> Eric Blake wrote:
> 
>> date -d 0001-01-01 +.%+4C.
>>
>> should produce ".+000.", but currently it produces ".%+4C." because the
>> + flag is unimplemented.
>>
>> See also http://austingroupbugs.net/view.php?id=1184
> 
> Surely this bug should be reported against strftime, not against 'date'.
> POSIX does require that strftime behave that way, but it does not place
> a similar requirement on 'date'.
> 

That used to be true, but now POSIX wants date to behave as if it uses
strftime:

http://austingroupbugs.net/view.php?id=466


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org





bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-21 Thread Paul Eggert

Eric Blake wrote:

That used to be true, but now POSIX wants date to behave as if it uses
strftime:

http://austingroupbugs.net/view.php?id=466


Ah, I didn't know that. Is there a list of recent changes to the POSIX spec for 
strftime somewhere? I can look to see which of them have made their way into 
Gnulib nstrftime.






bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-22 Thread Eric Blake
On 2/21/19 10:01 PM, Paul Eggert wrote:
> Eric Blake wrote:
>> That used to be true, but now POSIX wants date to behave as if it uses
>> strftime:
>>
>> http://austingroupbugs.net/view.php?id=466
> 
> Ah, I didn't know that. Is there a list of recent changes to the POSIX
> spec for strftime somewhere? I can look to see which of them have made
> their way into Gnulib nstrftime.

The best I can do is search austingroupbugs.net for all bugs containing
strftime, which pulls up a current total of 25 issues. Some are still
open or marked as rejected, some are editorial only, and some already
were applied in 2008, so the actual list of more recent changes is
smaller.  But reading through them, I think this is a fair summary:

1184: %C padding (for years below 1000, when minimum width is not
specified, it must be treated as width 2 with 0 padding)

1166: Need %OB (similar to %Ob) for nominative vs. genitive month names

954: %s for seconds since Epoch

739 (still not resolved): Whether %F implies plain %C or %+4C

772 (still open): Specifying %:::z and friends, but still at odds with
Finland wanting a way to express UTC+3 instead of UTC+03

472: details on %+C

466: date(1) should behave as if it uses strftime(3)

258: Need %Ob for nominative vs. genitive month names

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org





bug#34608: date +%+4C is unimplemented, contrary to POSIX

2019-02-25 Thread Paul Eggert

Eric Blake wrote:


The best I can do is search austingroupbugs.net for all bugs containing
strftime, which pulls up a current total of 25 issues.


Thanks for doing that. I read through those issues, and the only one that seems 
relevant (i.e., resolved by austingroup but not in Gnulib) is the business with 
the + conversion specification flag. I installed this Gnulib patch to implement 
the flag:


https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=188d87b05190690d6f8b0577ec65ef221a711d08

Then I installed the attached coreutils patches to propagate the Gnulib patch 
into coreutils, and I am marking this coreutils bug as done.


glibc strftime should also support the + conversion specification flag. I filed 
a bug report for that here:


https://sourceware.org/bugzilla/show_bug.cgi?id=24264
>From c50c4ab9e16df9368d52ed8cada3f3f2e32f093a Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 24 Feb 2019 23:35:23 -0800
Subject: [PATCH 1/3] build: update gnulib submodule to latest

---
 gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnulib b/gnulib
index e3970fb98..188d87b05 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit e3970fb9891668bd9dbc94daca18dc0d42b7e466
+Subproject commit 188d87b05190690d6f8b0577ec65ef221a711d08
-- 
2.17.1

>From b1e7af28ebc4b7218b2a76eee1dca738d3224a63 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 24 Feb 2019 23:59:22 -0800
Subject: [PATCH 2/3] =?UTF-8?q?date:=20=E2=80=98+=E2=80=99=20conversion=20?=
 =?UTF-8?q?specification=20flag?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The recent Gnulib update fixed Bug#34608; document and test this.
* NEWS: Mention the change.
* doc/coreutils.texi (Padding and other flags):
Update doc to cover new flag and other POSIX.1-2017 changes.
* tests/misc/date.pl (date-century-plus): New test.
---
 NEWS   |  3 +++
 doc/coreutils.texi | 15 ---
 tests/misc/date.pl |  3 +++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 5d9956854..e73cb52b8 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,9 @@ GNU coreutils NEWS-*- outline -*-
   after asking the user whether to proceed.
   [This bug was present in "the beginning".]
 
+  'date' now supports the '+' conversion specification flag,
+  introduced in POSIX.1-2017.
+
   df no longer corrupts displayed multibyte characters on macOS.
   [bug introduced with coreutils-8.18]
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 028371673..d1427323c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -15985,24 +15985,33 @@ example, numeric months are always output as two digits.
 Seconds since the epoch are not padded, though,
 since there is no natural width for them.
 
-As a GNU extension, @command{date} recognizes any of the
-following optional flags after the @samp{%}:
+The following optional flags can appear after the @samp{%}:
 
 @table @samp
 @item -
 (hyphen) Do not pad the field; useful if the output is intended for
 human consumption.
+This is a GNU extension.
 @item _
 (underscore) Pad with spaces; useful if you need a fixed
 number of characters in the output, but zeros are too distracting.
+This is a GNU extension.
 @item 0
 (zero) Pad with zeros even if the conversion specifier
 would normally pad with spaces.
+@item +
+Pad with zeros, like @samp{0}.  In addition, precede any year number
+with @samp{+} if it exceeds  or if its field width exceeds 4;
+similarly, precede any century number with @samp{+} if it exceeds 99
+or if its field width exceeds 2.  Preceding with @samp{+} is helpful
+for generationg some ISO 8601 formats.
 @item ^
 Use upper case characters if possible.
+This is a GNU extension.
 @item #
 Use opposite case characters if possible.
 A field that is normally upper case becomes lower case, and vice versa.
+This is a GNU extension.
 @end table
 
 @noindent
@@ -16017,7 +16026,7 @@ date +%_d/%_m -d "Feb 1"
 @result{}  1/ 2
 @end example
 
-As a GNU extension, you can specify the field width
+You can optionally specify the field width
 (after any flag, if present) as a decimal number.  If the natural size of the
 output of the field has less than the specified number of characters,
 the result is written right adjusted and padded to the given
diff --git a/tests/misc/date.pl b/tests/misc/date.pl
index 5e12158e9..9ba3d3983 100755
--- a/tests/misc/date.pl
+++ b/tests/misc/date.pl
@@ -297,6 +297,9 @@ my @Tests =
   {ENV => 'TZ=PST8'},
   {OUT => 'Wed Dec 31 21:00:00 PST 1969'},
  ],
+
+ # https://bugs.gnu.org/34608
+ ['date-century-plus', '-d @0 +.%+4C.', {OUT => '.+019.'}],
 );
 
 # Repeat the cross-dst test, using Jan 1, 2005 and every interval from 1..364.
-- 
2.17.1

>From 3e7fd6650e6040c6b09f97d6f189e0365727df90 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 25 Feb 2019 00:19:22 -0800
Subject: [PATCH 3/3] doc: fix typo in previous patch

---