On 05/11/2025 01:31, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
On 04/11/2025 14:17, Pádraig Brady wrote:
On 04/11/2025 04:01, Collin Funk wrote:
Many people are used to seeing ISO 8601 dates using a period separating
seconds and nanoseconds. This behavior seems to be worth documenting
given the bug reports:
https://bugs.gnu.org/63119
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118970
* doc/coreutils.texi (Options for date): Mention that
'date --iso-8601=ns' uses a comma as a separator, following the
preference of ISO 8601. Give an example of how to get an ISO 8601 date
with a period separator.
---
doc/coreutils.texi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 13f9f9a46..a4c9feffc 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -17181,6 +17181,15 @@ @node Options for date
@item ns
Also print nanoseconds.
This is like the format @code{%Y-%m-%dT%H:%M:%S,%N%:z}.
+
+ISO 8601 allows a comma or period to be used to separate seconds from
+subseconds, preferring the use of a comma. GNU @command{date} follows
+this preference. If you would prefer to use a period separator, you can
+transform the output of @samp{date --rfc-3339=ns}:
+
+@example
+date --rfc-3339=ns | sed s'/ /T/'
+@end example
@end table
@macro dateParseNote
I agree this is a bit surprising.
I suppose we could use the current locale's decimal_point,
falling back to , if the locale's wasn't one of [.,].
Though that would introduce varying output when you're asking
for a standard format.
That sounds like a good idea to me. But I rather wait until just after a
release. The output has used a comma since it was introduced over 20
years ago [1]. Best to give people time to complain if they dislike the
change, IMO. :)
Well I gave both sides of the argument above.
I think I'm 60:40 about making a logic change here
to avoid the varying output aspect.
So I suppose post processing is what we're left with:
Would the following example be preferable, as it doesn't mix standards,
and uses only coreutils commands.
date --iso-8691=ns | tr ' ' T
Yes, that works too. I assume no locale would add a space anywhere in
that date format.
Actually, maybe setting LC_ALL=C externally is fine,
in which case you could augment the existing text with:
"Note the preference for a @samp(,} decimal point which you can override
by expressing the full format with @samp{.} decimal point explicitly,
like @code{LC_ALL=C date +'%Y-%m-%dT%H:%M:%S.%N%:z'}"
I wanted to mention that the preference was also ISO 8601's. How about
the attached patch that modifies yours slightly?
That should also match the intent of my first patch, without the
confusing mention of another standard.
Cool.
I pushed that.
thanks,
Padraig
