bug#68064: Date addition error with “day Monthname” versus “Monthname day”
tag 68064 notabug
close 68064
stop
On 27/12/2023 17:29, Larry Ploetz wrote:
It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
locale-specific.
:bin larry$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
:bin larry$ ./date -d "$(./date -d today +%d\ %b) + 1 day"
Fri Dec 28 00:00:00 LMT 0001
:bin larry$ ./date -d "$(./date -d today +%b\ %d) + 1 day"
Thu Dec 28 00:00:00 CST 2023
:bin larry$ ./date --version
date (GNU coreutils) 9.4.97-98d463
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
later<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
This is due to ambiguity in date input formats.
Your case is:
$ date --debug -d "27 Dec + 1 day"
date: parsed date part: (Y-M-D) -001-12-27
date: parsed relative part: +1 day(s)
A slightly adjusted case highlighting the ambiguity:
$ date --debug -d "27 Dec + 1 week"
date: parsed date part: (Y-M-D) -001-12-27
date: parsed relative part: +7 day(s)
So really the solution here is to avoid the ambiguity
by explicitly specifying the year, or more abstractly
specifying "today" rather than a partial date.
Another gotcha highlighted by the --debug option above is:
date: warning: using midnight as starting time: 00:00:00
date: starting date/time: '(Y-M-D) 0001-12-27 00:00:00'
date: warning: when adding relative days, it is recommended to specify noon
Another gotcha is that only English month abbreviations
are supported on input, so your command will fail in other locales.
For a summary of date input issues see:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#index-date-input-formats
cheers,
Pádraig
bug#68064: Date addition error with “day Monthname” versus “Monthname day”
It seems like there might be a problem with date addition when the base date is specified as “day Monthname” instead of “Monthname day”, where the offset is being interpreted as an absolute year value. This may be locale-specific. :bin larry$ locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= :bin larry$ ./date -d "$(./date -d today +%d\ %b) + 1 day" Fri Dec 28 00:00:00 LMT 0001 :bin larry$ ./date -d "$(./date -d today +%b\ %d) + 1 day" Thu Dec 28 00:00:00 CST 2023 :bin larry$ ./date --version date (GNU coreutils) 9.4.97-98d463 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later<https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. Thanks, ·Larry
bug#63784: date --date "1 month ago" +%Y-%m does not work as expected on day 31
On 29/05/2023 12:55, Jelle de Jong wrote: Hello everybody, I been hitting an issue for a while now that date commands return the wrong month on day 31 of a month and my automations stops working on correctly on these days. root@sydney:~# date Wed Aug 31 22:09:04 CEST 2022 root@sydney:~# date --date "1 month ago" +%Y-%m 2022-07 root@sydney:~# date --date "2 month ago" +%Y-%m 2022-07 root@sydney:~# date --date "3 month ago" +%Y-%m 2022-05 root@sydney:~# date --date "4 month ago" +%Y-%m 2022-05 root@sydney:~# date Sat Dec 31 19:20:13 CET 2022 root@sydney:~# date --date '1 month ago' +%Y-%m 2022-12 $ date --version date (GNU coreutils) 8.30 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later I would love to have this fixed if possible. If I am using the wrong command I would love to be educated as well. Should I use date --date "$(date +%Y-%m-01) -1 month" +%Y-%m instead... Yes that is confusing. The current workaround is to operate relative to the middle of the month as described at: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
bug#63784: date --date "1 month ago" +%Y-%m does not work as expected on day 31
Hello everybody, I been hitting an issue for a while now that date commands return the wrong month on day 31 of a month and my automations stops working on correctly on these days. root@sydney:~# date Wed Aug 31 22:09:04 CEST 2022 root@sydney:~# date --date "1 month ago" +%Y-%m 2022-07 root@sydney:~# date --date "2 month ago" +%Y-%m 2022-07 root@sydney:~# date --date "3 month ago" +%Y-%m 2022-05 root@sydney:~# date --date "4 month ago" +%Y-%m 2022-05 root@sydney:~# date Sat Dec 31 19:20:13 CET 2022 root@sydney:~# date --date '1 month ago' +%Y-%m 2022-12 $ date --version date (GNU coreutils) 8.30 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later I would love to have this fixed if possible. If I am using the wrong command I would love to be educated as well. Should I use date --date "$(date +%Y-%m-01) -1 month" +%Y-%m instead... Kind regards, Jelle de Jong
bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable
On 7.5.2023 14:52, Andreas Schwab wrote: On Mai 07 2023, Eiríkur Hjartarson via GNU coreutils Bug Reports wrote: Now the "bug": It's not a bug. Thanks for the explanation, in my defense, I did read the date info page and the FAQ at https://www.gnu.org/software/coreutils/faq/coreutils-faq.html . Obviously I missed the reference to opengroup. Regards, -- Eiríkur
bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable
On 5/7/23 07:52, Andreas Schwab wrote:
Thus TZ=UTC+2 means two hours before UTC.
Yes, and this mistake seems to be common enough that I installed the
attached patch into Gnulib, so that it'll propagate into the Coreutils
manual, which should help people who read the 'date' documentation
(admittedly only a subset of 'date' users).
From 9f205ff9624b8e10b4331432c59bc732b8c1a7fe Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 7 May 2023 09:28:57 -0700
Subject: [PATCH] Warn against bogus TZ settings
* doc/parse-datetime.texi (Specifying time zone rules):
Warn against TZ="UTC=5".
---
ChangeLog | 6 ++
doc/parse-datetime.texi | 3 +++
2 files changed, 9 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 06ff163e0e..823d32b66f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2023-05-07 Paul Eggert
+
+ Warn against bogus TZ settings
+ * doc/parse-datetime.texi (Specifying time zone rules):
+ Warn against TZ="UTC=5".
+
2023-05-05 Bruno Haible
dirfd: Add tests.
diff --git a/doc/parse-datetime.texi b/doc/parse-datetime.texi
index d54d7660c8..ec0160da8e 100644
--- a/doc/parse-datetime.texi
+++ b/doc/parse-datetime.texi
@@ -574,6 +574,9 @@ This example uses the somewhat-confusing POSIX convention for rules.
and the time zone is 7 hours west of Greenwich, and
@samp{TZ="<+0530>-5:30"} says that the time zone abbreviation is @samp{+0530}
and the time zone is 5 hours 30 minutes east of Greenwich.
+(One should never use a setting like @samp{TZ="UTC-5"}, since
+this would incorrectly imply that local time is five hours east of
+Greenwich and the time zone is called ``UTC''.)
Although trickier POSIX @env{TZ} settings like
@samp{TZ="<-05>+5<-04>,M3.2.0/2,M11.1.0/2"} can specify some daylight
saving regimes, location-based settings like
--
2.40.1
bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable
On Mai 07 2023, Eiríkur Hjartarson via GNU coreutils Bug Reports wrote: > Now the "bug": It's not a bug. > $ TZ=Europe/Riga date --iso-8601=minutes -d "2024-01-01T00:00-05:00" > 2024-01-01T07:00+02:00 > > $ TZ=UTC+2 date --iso-8601=minutes -d "2024-01-01T00:00-05:00" > 2023-01-01T03:00-02:00 > > That is: the first command gives me the time and date in Riga when it's > midnight at new year's eve in New York. > > The second command should do the same but instead gives the time in > Godthab Greenland. That's not how TZ works. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html says about the offset: Indicates the value added to the local time to arrive at Coordinated Universal Time. ... If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' ). Thus TZ=UTC+2 means two hours before UTC. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable
Hi, I'm on Fedora-38 GNU/Linux and the version string of 'date' is "date (GNU coreutils) 9.1". $ ls -l /etc/localtime lrwxrwxrwx. 1 root root 40 jan 11 2022 /etc/localtime -> ../usr/share/zoneinfo/Atlantic/Reykjavik Now the "bug": $ TZ=Europe/Riga date --iso-8601=minutes -d "2024-01-01T00:00-05:00" 2024-01-01T07:00+02:00 $ TZ=UTC+2 date --iso-8601=minutes -d "2024-01-01T00:00-05:00" 2023-01-01T03:00-02:00 That is: the first command gives me the time and date in Riga when it's midnight at new year's eve in New York. The second command should do the same but instead gives the time in Godthab Greenland. $ TZ=America/Godthab date -d "2024-01-01T00:00-05:00" --iso-8601=minutes 2024-01-01T03:00-02:00 It seems to me that the sign in the timezone variable could be simply reversed. Regards, -- Eiríkur
bug#63119: date -Ins has a comma!!
On 4/27/23 07:53, aaa jjj wrote: What does ISO 8601 say about this? I believe ISO 8601-1:2019/Amd 1:2022 prefers a comma, though a period is allowed. Unfortunately I can't easily check this because the standards are not published online and you need to pay to read them. Isn't ISO wonderful?
bug#63119: date -Ins has a comma!!
Hi, is it not a bug, that if I do LC_ALL=C date -u -Ins gives me this: 2023-04-27T13:30:15,976772648+00:00 I'm talking about the comma. What is it doing there??? Should this not be a dot instead? Here's the code: https://github.com/coreutils/coreutils/blob/35adc746a000ac1f8d1d817a6a3a60d5b80daef5/src/date.c#L465 What does ISO 8601 say about this? Look at other languages: node -e 'console.log(new Date().toISOString())' -> 2023-04-27T13:40:58.846Z python3 -c 'from datetime import datetime; print(datetime.now().isoformat())' -> 2023-04-27T16:23:40.217313 python3 -c 'from datetime import datetime, timezone; print(datetime.now(timezone.utc).isoformat())' -> 2023-04-27T14:23:40.228151+00:00 python3 -c 'from datetime import datetime, timezone; print(datetime.now(timezone.utc).astimezone().isoformat())' -> 2023-04-27T16:23:40.238908+02:00 PS: Hell, you cannot simply change it now (backwards-compatibility), but what about another option flag or whatever... Thanks. A
bug#62497: maybe date -f should generate an error
On 28/03/2023 13:42, Pádraig Brady wrote:
On 28/03/2023 09:54, Paul Eggert wrote:
Thanks for reporting that. I installed the attached to fix it.
Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.
I'm also applying the attached for fix the same issue in dircolors.
cheers,
Pádraig
From a9bd274616a8d2e99736b498e657cda4e6954f3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Tue, 28 Mar 2023 14:24:29 +0100
Subject: [PATCH] dircolors: diagnose read errors
* NEWS: Mention the fix.
* src/dircolors.c: Fail upon read error from getline().
* tests/misc/dircolors.sh: Add a new test.
* tests/local.mk: Reference the new test.
---
NEWS| 4 ++--
src/dircolors.c | 5 +
tests/local.mk | 1 +
tests/misc/dircolors.sh | 28
4 files changed, 36 insertions(+), 2 deletions(-)
create mode 100755 tests/misc/dircolors.sh
diff --git a/NEWS b/NEWS
index 8f602325c..bade99043 100644
--- a/NEWS
+++ b/NEWS
@@ -10,8 +10,8 @@ GNU coreutils NEWS-*- outline -*-
more restricted systems like android or containers etc.
[bug introduced in coreutils-9.2]
- date --file will now diagnose a failure to read the file.
- Previously it would have silently ignored the failure.
+ date --file and dircolors will now diagnose a failure to read a file.
+ Previously they would have silently ignored the failure.
[This bug was present in "the beginning".]
md5sum --check again correctly prints the status of each file checked.
diff --git a/src/dircolors.c b/src/dircolors.c
index f95524b67..f43a57db5 100644
--- a/src/dircolors.c
+++ b/src/dircolors.c
@@ -298,6 +298,11 @@ dc_parse_stream (FILE *fp, char const *filename)
{
if (getline (_line, _line_size, fp) <= 0)
{
+ if (ferror (fp))
+{
+ error (0, errno, _("%s: read error"), quotef (filename));
+ ok = false;
+}
free (input_line);
break;
}
diff --git a/tests/local.mk b/tests/local.mk
index c958c138c..a0c024905 100644
--- a/tests/local.mk
+++ b/tests/local.mk
@@ -306,6 +306,7 @@ all_tests = \
tests/misc/date-sec.sh \
tests/misc/date-tz.sh\
tests/misc/dircolors.pl \
+ tests/misc/dircolors.sh \
tests/misc/dirname.pl\
tests/misc/env-null.sh \
tests/misc/env-S.pl\
diff --git a/tests/misc/dircolors.sh b/tests/misc/dircolors.sh
new file mode 100755
index 0..9e2ae2890
--- /dev/null
+++ b/tests/misc/dircolors.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Copyright (C) 2023 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+. "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
+print_ver_ dircolors
+
+# Make sure dircolors fails when it can't read input
+# (the current directory in this case)
+if ! cat . >/dev/null; then
+ # can't read() directories
+ returns_ 1 dircolors . || fail=1
+fi
+
+Exit $fail
--
2.26.2
bug#62497: maybe date -f should generate an error
On 28/03/2023 09:54, Paul Eggert wrote:
Thanks for reporting that. I installed the attached to fix it.
Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.
cheers,
PádraigFrom a4525de1ef593cb3873eb88caa7279eb32669bda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Tue, 28 Mar 2023 13:38:52 +0100
Subject: [PATCH] tests: add a test case for the previous date fix
* NEWS: Also mention this bug fix.
* tests/misc/date-f.sh: Add a new test.
* tests/local.mk: Reference the new test.
---
NEWS | 4
tests/local.mk | 1 +
tests/misc/date-f.sh | 29 +
3 files changed, 34 insertions(+)
create mode 100755 tests/misc/date-f.sh
diff --git a/NEWS b/NEWS
index 3b0524c22..8f602325c 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ GNU coreutils NEWS-*- outline -*-
more restricted systems like android or containers etc.
[bug introduced in coreutils-9.2]
+ date --file will now diagnose a failure to read the file.
+ Previously it would have silently ignored the failure.
+ [This bug was present in "the beginning".]
+
md5sum --check again correctly prints the status of each file checked.
Previously the status for files was printed as 'OK' once any file had passed.
This also applies to cksum, sha*sum, and b2sum.
diff --git a/tests/local.mk b/tests/local.mk
index 1e93290d0..c958c138c 100644
--- a/tests/local.mk
+++ b/tests/local.mk
@@ -302,6 +302,7 @@ all_tests = \
tests/misc/csplit-io-err.sh \
tests/misc/csplit-suppress-matched.pl \
tests/misc/date-debug.sh \
+ tests/misc/date-f.sh\
tests/misc/date-sec.sh \
tests/misc/date-tz.sh\
tests/misc/dircolors.pl \
diff --git a/tests/misc/date-f.sh b/tests/misc/date-f.sh
new file mode 100755
index 0..ebbb95652
--- /dev/null
+++ b/tests/misc/date-f.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+# Verify -f processing
+
+# Copyright (C) 2023 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+. "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
+print_ver_ date
+
+# Make sure date fails when it can't read input
+# (the current directory in this case)
+if ! cat . >/dev/null; then
+ # can't read() directories
+ returns_ 1 date -f . || fail=1
+fi
+
+Exit $fail
--
2.26.2
bug#62497: maybe date -f should generate an error
Thanks for reporting that. I installed the attached to fix it.From 9c5e542fd190a14431092e3b6cb45d18fe95f26f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 28 Mar 2023 01:52:43 -0700
Subject: [PATCH] date: diagnose -f read errors
* src/date.c (batch_convert): Diagnose read errors, fixing Bug#62497.
---
src/date.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/date.c b/src/date.c
index 0f2012761..bc4cc0ce9 100644
--- a/src/date.c
+++ b/src/date.c
@@ -368,7 +368,9 @@ batch_convert (char const *input_filename, char const *format,
ssize_t line_length = getline (, , in_stream);
if (line_length < 0)
{
- /* FIXME: detect/handle error here. */
+ if (ferror (in_stream))
+die (EXIT_FAILURE, errno, _("%s: read error"),
+ quotef (input_filename));
break;
}
--
2.37.2
bug#62497: maybe date -f should generate an error
Hello The usual case is: $ echo "2023-03-27 08:30:00" > dates.txt $ echo "2023-04-01 12:00:00" >> dates.txt $ /usr/bin/date -f dates.txt Mon Mar 27 08:30:00 CEST 2023 Sat Apr 1 12:00:00 CEST 2023 If done on a non existing file, we get: $ date -f non-existing /usr/bin/date: non-existing: No such file or directory Maybe it should do the same on a directory: $ /usr/bin/date -f / doesn't show anything and return 0 Cheers, Sylvestre
bug#62405: date update
On 3/23/23 06:18, Edgar Aquino Rodriguez wrote: if i run date (system time) Thu Mar 23 07:15:39 MST 2023 i dont now but if i run date --custom Thu Mar 23 13:34:15 MST 2023 or how can get multiple timezones in the same system Although it's not clear what you're asking for, but perhaps these example shell commands will help: $ ls -l /etc/localtime lrwxrwxrwx. 1 root root 41 Oct 29 2019 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles $ date; TZ=America/Los_Angeles date; TZ=Europe/Rome date Thu Mar 23 16:00:05 PDT 2023 Thu Mar 23 16:00:05 PDT 2023 Fri Mar 24 00:00:05 CET 2023 At any rate this is not a bug so I'm closing the bug report.
bug#62405: date update
i had a question about date time on linux terminal, if is possible had multiple times i mean something like this if i run date (system time) Thu Mar 23 07:15:39 MST 2023 i dont now but if i run date --custom Thu Mar 23 13:34:15 MST 2023 or how can get multiple timezones in the same system
bug#61537: [Bug-coreutils] 'cp -au' re-copies (removes and relinks) hard links that are up to date
Hello. I have been forced recently to update my coreutils 8.11 (because 'touch' in 8.11 didn't understand the dates with a 'T' separator passed to it by the configure of another GNU package I was installing) and have found that 'cp -au' now re-copies (removes and relinks) hard links that are up to date and it didn't recopy with 8.11. I have tried coreutils 8.23 and 9.1, but I think all versions after 8.11 have this problem. To illustrate the problem, I first create a directory 'src' containing two linked files and then make a copy of 'src' in 'dest': $ md src $ echo "foo" > src/a $ ln src/a src/b $ cp -auv src dest 'src' -> 'dest' 'src/a' -> 'dest/a' 'src/b' -> 'dest/b' Now, every time I update 'dest' using 'cp -au', it removes and relinks 'dest/b' in spite of it already being a link to 'dest/a': $ cp -auv src/* dest removed 'dest/b' But with 'cp' from coreutils 8.11, 'dest/b' was not recopied: $ /tmp/coreutils-8.11/src/cp -auv src/* dest $ Can current 'cp' be fixed so that it notices that the destination is already updated, and thus avoids removing and relinking it, just as it did in coreutils 8.11? Thanks, Antonio.
bug#61528: date doesn't parse negative years
Hello, I noticed that date doesn't accept negative years, such as in the date: -0001-01-02 (i.e. 2nd Jan 2 BC). It's also somewhat puzzling that even through date will convert a timestamp in that year to an output string, it won't parse that string as valid (i.e. the last 2 lines below). date +%Y-%m-%d -d '0001-01-02' -> 0001-01-02 date +%Y-%m-%d -d '-01-02' -> -01-02 date +%Y-%m-%d -d '-0001-01-02' -> date: invalid date ‘-0001-01-02’ date +%Y-%m-%d -d @-62135510325 -> 0001-01-02 date +%Y-%m-%d -d @-62167132725 -> -01-02 date +%Y-%m-%d -d @-62198668725 -> -001-01-02 date +%Y-%m-%d -d '-001-01-02' -> date: invalid date ‘-001-01-02’ My reading of ISO_8601 is that these are allowed in formats -MM-DD where is a 4-6 digit number which may be positive, zero or negative. https://en.wikipedia.org/wiki/ISO_8601 Note that we should treat year 0 is also 1 BC, while -1 AD is 2 BC. https://en.wikipedia.org/wiki/Year_zero Thanks very much. P.S. cal doesn't work with years 0 and below either.
bug#60030: Small error in date command
tag 60030 notabug close 60030 stop On 13/12/2022 02:50, Malin Freeborn wrote: Hi bug-team, There's a small error in the date man page. If you search for `%F` you'll notice the date is summarized as so: %F full date; like %+4Y-%m-%d The example shows the `%` sign before the `+`. This was intentional. '+' is a flag in this context as per: https://github.com/coreutils/coreutils/commit/2ab2f7a42 cheers, Pádraig
bug#60030: Small error in date command
Hi bug-team, There's a small error in the date man page. If you search for `%F` you'll notice the date is summarized as so: %F full date; like %+4Y-%m-%d The example shows the `%` sign before the `+`. Best, - Malin
bug#59827: [PATCH] info date to be explicit about the date formats
Thanks for the suggestion. I installed the attached which isn't exactly
what you sent but which implements the basic idea.From 5399f2aac4dc8dd4392a1194dc9bdbb2bcc6272c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 5 Dec 2022 18:42:19 -0800
Subject: [PATCH] doc: improve date -I doc
Suggested by Marc Chantreux (bug#59827).
* doc/coreutils.texi (Options for date):
Give formats for -I, like we already do for --rfc-3339.
---
doc/coreutils.texi | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c801097ee..a98f7438d 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16559,22 +16559,25 @@ terms of the time to include. It can be one of the following:
@table @samp
@item auto
Print just the date. This is the default if @var{timespec} is omitted.
+This is like the format @code{%Y-%m-%d}.
@item hours
-Append the hour of the day to the date.
+Also print hours and timezone.
+This is like the format @code{%Y-%m-%dT%H%:z}.
@item minutes
-Append the hours and minutes.
+Also print minutes.
+This is like the format @code{%Y-%m-%dT%H:%M%:z}.
@item seconds
-Append the hours, minutes and seconds.
+Also print seconds.
+This is like the format @code{%Y-%m-%dT%H:%M:%S%:z}.
@item ns
-Append the hours, minutes, seconds and nanoseconds.
+Also print nanoseconds.
+This is like the format @code{%Y-%m-%dT%H:%M:%S,%N%:z}.
@end table
-If showing any time terms, then include the time zone using the format
-@samp{%:z}.
@macro dateParseNote
This format is always suitable as input
for the @option{--date} (@option{-d}) and @option{--file}
@@ -16640,19 +16643,19 @@ It can be one of the following:
@table @samp
@item date
Print just the full-date, e.g., @samp{2020-07-21}.
-This is equivalent to the format @samp{%Y-%m-%d}.
+This is like the format @samp{%Y-%m-%d}.
@item seconds
Print the full-date and full-time separated by a space, e.g.,
@samp{2020-07-21 04:30:37+05:30}. The output ends with a numeric
time-offset; here the @samp{+05:30} means that local time is five
-hours and thirty minutes east of UTC@. This is equivalent to
+hours and thirty minutes east of UTC@. This is like
the format @samp{%Y-%m-%d %H:%M:%S%:z}.
@item ns
Like @samp{seconds}, but also print nanoseconds, e.g.,
@samp{2020-07-21 04:30:37.998458565+05:30}.
-This is equivalent to the format @samp{%Y-%m-%d %H:%M:%S.%N%:z}.
+This is like the format @samp{%Y-%m-%d %H:%M:%S.%N%:z}.
@end table
--
2.38.1
bug#59827: [PATCH] info date to be explicit about the date formats
hello coreutils maintainers,
I would like info page of the date to be explicit about
the ready to use date formats so users can pick them as
example for their own ones (as example: just remove the
timezone information).
regards,
marc
---
doc/coreutils.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c801097..8c24b52 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16559,18 +16559,23 @@ terms of the time to include. It can be one of the
following:
@table @samp
@item auto
Print just the date. This is the default if @var{timespec} is omitted.
+("%Y-%m-%d")
@item hours
Append the hour of the day to the date.
+("%Y-%m-%dT%H%:z")
@item minutes
Append the hours and minutes.
+("%Y-%m-%dT%H:%M%:z")
@item seconds
Append the hours, minutes and seconds.
+("%Y-%m-%dT%H:%M:%S%:z")
@item ns
Append the hours, minutes, seconds and nanoseconds.
+("%Y-%m-%dT%H:%M:%S,%N%:z")
@end table
If showing any time terms, then include the time zone using the format
--
2.34.1
bug#58599: `date -d $(date)` error for non en_* locale
On 10/17/22 07:44, Ruslan Kovtun wrote: According to "do one thing and do it well" and to the fact of '-d/--date' option existence, `date` should be able to parse its default output in any locale. Patches would be welcome. Good luck getting it to work, though. Many date formats are ambiguous, and I don't see how you'd address that. In the meantime, I suggest sticking to ISO format dates and times with UTC, e.g.: date -d "$(date -u +'%Y-%m-%d %H:%M:%S.%NZ')"
bug#58599: `date -d $(date)` error for non en_* locale
$ date -d "$( date )" date: invalid date ‘Пн 17 окт 2022 17:34:00 EEST’ $ date -d "Mon 17 oct 2022 17:34:00 EEST" Пн 17 окт 2022 17:34:00 EEST According to "do one thing and do it well" and to the fact of '-d/--date' option existence, `date` should be able to parse its default output in any locale. -- Yours faithfully, Ruslan Kovtun.
bug#58494: touch resists date 2022-09-11T00:00:00
> > In Santiago, Chile, that timestamp does not exist. Is your timezone set > > to Santiago time? That would explain your symptoms. > > I am, but I don't understand why the timezone would make a time not to > exist... What am I missing? Uh, oh, it's daylight saving time change... never thought of that. Good catch! Felix Freeman
bug#58494: touch resists date 2022-09-11T00:00:00
On Thu Oct 13, 2022 at 2:42 PM -03, Paul Eggert wrote: > On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote: > > $ touch -t 20220911 algo > > touch: invalid date format ‘20220911’ > > $ touch -d 2022-09-11T00:00:00 algo > > touch: invalid date format ‘2022-09-11T00:00:00’ > > In Santiago, Chile, that timestamp does not exist. Is your timezone set > to Santiago time? That would explain your symptoms. I am, but I don't understand why the timezone would make a time not to exist... What am I missing? CC = 20 YY = 22 MM = 09 DD = 11 hh = 00 mm = 00 Felix Freeman
bug#58494: touch resists date 2022-09-11T00:00:00
On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote: $ touch -t 20220911 algo touch: invalid date format ‘20220911’ $ touch -d 2022-09-11T00:00:00 algo touch: invalid date format ‘2022-09-11T00:00:00’ In Santiago, Chile, that timestamp does not exist. Is your timezone set to Santiago time? That would explain your symptoms.
bug#58494: touch resists date 2022-09-11T00:00:00
I think I found a bug. In any format that I try to touch a file with the date 2022-09-11 at 00:00, touch says I'm entering an invalid date format. $ touch -t 20220911 algo touch: invalid date format ‘20220911’ $ touch -d 2022-09-11T00:00:00 algo touch: invalid date format ‘2022-09-11T00:00:00’ If I change date or hour it works flawlessly $ touch -d 2022-09-11T01:00:00 algo $ echo $? 0 Felix Freeman
bug#57834: Date Command Anomaly
On 23/09/2022 14:03, Bert Wesarg via GNU coreutils Bug Reports wrote: Dear, $ TZ=Europe/London date --debug --date="2022/03/27 01:00:00" date: warning: value 2022 has 4 digits. Assuming YYYY/MM/DD date: parsed date part: (Y-M-D) 2022-03-27 date: parsed time part: 01:00:00 date: input timezone: TZ="Europe/London" environment value date: using specified time as starting value: '01:00:00' date: error: invalid date/time value: date: user provided time: '(Y-M-D) 2022-03-27 01:00:00' date:normalized time: '(Y-M-D) 2022-03-27 02:00:00' date: -- date: possible reasons: date:non-existing due to daylight-saving time; date:numeric values overflow; date: missing timezone date: invalid date ‘2022/03/27 01:00:00’ Best Bert On Thu, Sep 15, 2022 at 5:21 PM Martin Hughes via GNU coreutils Bug Reports wrote: Dear Sir, I have stumbled across this anomaly whilst processing a series of dates. I have not found any other legal date combination that generates this error. Perl time facilities seem to be affected by this too. mjh@carnaby:~> date --date="2022/03/27 00:00:00" Sun 27 Mar 00:00:00 GMT 2022 mjh@carnaby:~> date --date="2022/03/27 01:00:00" date: invalid date ‘2022/03/27 01:00:00’ mjh@carnaby:~> date --date="2022/03/27 02:00:00" Sun 27 Mar 02:00:00 BST 2022 The version of date is: mjh@carnaby:~> date --version date (GNU coreutils) 8.29 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. The operating system is opensuse leap 15.2: Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe) Martin Hughes A bit late to the party weren't you? Martin acknowledged it was GMT/BST transition, on 15th September. -- Chris Elvidge
bug#57834: Date Command Anomaly
Dear, $ TZ=Europe/London date --debug --date="2022/03/27 01:00:00" date: warning: value 2022 has 4 digits. Assuming YYYY/MM/DD date: parsed date part: (Y-M-D) 2022-03-27 date: parsed time part: 01:00:00 date: input timezone: TZ="Europe/London" environment value date: using specified time as starting value: '01:00:00' date: error: invalid date/time value: date: user provided time: '(Y-M-D) 2022-03-27 01:00:00' date:normalized time: '(Y-M-D) 2022-03-27 02:00:00' date: -- date: possible reasons: date:non-existing due to daylight-saving time; date:numeric values overflow; date: missing timezone date: invalid date ‘2022/03/27 01:00:00’ Best Bert On Thu, Sep 15, 2022 at 5:21 PM Martin Hughes via GNU coreutils Bug Reports wrote: > > > Dear Sir, > I have stumbled across this anomaly whilst processing a series of dates. > I have not found any other legal date combination that generates this > error. Perl time facilities seem to be affected by this too. > > mjh@carnaby:~> date --date="2022/03/27 00:00:00" > Sun 27 Mar 00:00:00 GMT 2022 > > mjh@carnaby:~> date --date="2022/03/27 01:00:00" > date: invalid date ‘2022/03/27 01:00:00’ > > mjh@carnaby:~> date --date="2022/03/27 02:00:00" > Sun 27 Mar 02:00:00 BST 2022 > > The version of date is: > mjh@carnaby:~> date --version > date (GNU coreutils) 8.29 > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <https://gnu.org/licenses/gpl.html>. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Written by David MacKenzie. > > The operating system is opensuse leap 15.2: > Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version > 7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe) > > Martin Hughes
bug#57834: Date Command Anomaly - Forget it. My Oversite
Sorry, my oversite, It was the transition from Greenwich Mean Time to British Summer time 27th March. Martin Hughes
bug#57834: Date Command Anomaly
Dear Sir, I have stumbled across this anomaly whilst processing a series of dates. I have not found any other legal date combination that generates this error. Perl time facilities seem to be affected by this too. mjh@carnaby:~> date --date="2022/03/27 00:00:00" Sun 27 Mar 00:00:00 GMT 2022 mjh@carnaby:~> date --date="2022/03/27 01:00:00" date: invalid date ‘2022/03/27 01:00:00’ mjh@carnaby:~> date --date="2022/03/27 02:00:00" Sun 27 Mar 02:00:00 BST 2022 The version of date is: mjh@carnaby:~> date --version date (GNU coreutils) 8.29 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. The operating system is opensuse leap 15.2: Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe) Martin Hughes
bug#55401: date man page
On 14/05/2022 01:42, Pádraig Brady wrote:
On 13/05/2022 20:10, t0th wrote:
Man page of date command should make explicit that -d and -r options are
mutually exclusive.
Right. More accurately, we might have a sentence to say that:
"All options to specify the date to display are mutually exclusive.
I.e.: --date, --file, --reference, --resolution".
I've pushed the attached 2 patches
to document the current situation at least.
cheers,
Padraig
From b09a23ec3f20003729b652ff1141f76de5e29e7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 24 Jul 2022 20:49:29 +0100
Subject: [PATCH] doc: date: clarify which options are mutually exclusive
* src/date.c (usage): Specify that --date, --file, --reference,
and --resolution are mutually exclusive.
* doc/coreutils.texi (Options for date): Likewise.
Addresses https://bugs.gnu.org/55401
---
doc/coreutils.texi | 4
src/date.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index e0c87d1ad..53257f7d9 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16426,6 +16426,10 @@ relative to Universal Time rather than to the local time zone.
The program accepts the following options. Also see @ref{Common options}.
Except for @option{-u}, these options are all GNU extensions to POSIX.
+All options that specify the date to display are mutually exclusive.
+I.e.: @option{--date}, @option{--file}, @option{--reference},
+@option{--resolution}.
+
@table @samp
@item -d @var{datestr}
diff --git a/src/date.c b/src/date.c
index 7f2ac801d..ff5c548c0 100644
--- a/src/date.c
+++ b/src/date.c
@@ -183,6 +183,11 @@ With -s, or with [MMDDhhmm[[CC]YY][.ss]], set the date and time.\n\
fputs (VERSION_OPTION_DESCRIPTION, stdout);
fputs (_("\
\n\
+All options that specify the date to display are mutually exclusive.\n\
+I.e.: --date, --file, --reference, --resolution.\n\
+"), stdout);
+ fputs (_("\
+\n\
FORMAT controls the output. Interpreted sequences are:\n\
\n\
%% a literal %\n\
--
2.26.2
From 854e0351216869b8e79391e08b156127d1508beb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 24 Jul 2022 19:24:18 +0100
Subject: [PATCH] date: --debug: diagnose discarded -d or -s options
* src/date.c: (main): Track and diagnose whether any
-d or -s options are dropped, as users may think
multiple options are supported, given they can be relative.
* tests/misc/date-debug.sh: Add a test case.
* NEWS: Mention the improvement.
---
NEWS | 5 +
src/date.c | 12
tests/misc/date-debug.sh | 10 ++
3 files changed, 27 insertions(+)
diff --git a/NEWS b/NEWS
index b5b8990f8..3113d4236 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,11 @@ GNU coreutils NEWS-*- outline -*-
factor now accepts the --exponents (-h) option to print factors
in the form p^e, rather than repeating the prime p, e times.
+** Improvements
+
+ date --debug now diagnoses if multiple --date or --set options are
+ specified, as only the last specified is significant in that case.
+
* Noteworthy changes in release 9.1 (2022-04-15) [stable]
diff --git a/src/date.c b/src/date.c
index 9a282e2f5..7f2ac801d 100644
--- a/src/date.c
+++ b/src/date.c
@@ -403,6 +403,8 @@ main (int argc, char **argv)
char *reference = NULL;
struct stat refstats;
bool ok;
+ bool discarded_datestr = false;
+ bool discarded_set_datestr = false;
initialize_main (, );
set_program_name (argv[0]);
@@ -420,6 +422,8 @@ main (int argc, char **argv)
switch (optc)
{
case 'd':
+ if (datestr)
+discarded_datestr = true;
datestr = optarg;
break;
case DEBUG_DATE_PARSING_OPTION:
@@ -469,6 +473,8 @@ main (int argc, char **argv)
new_format = rfc_email_format;
break;
case 's':
+ if (set_datestr)
+discarded_set_datestr = true;
set_datestr = optarg;
set_date = true;
break;
@@ -511,6 +517,12 @@ main (int argc, char **argv)
usage (EXIT_FAILURE);
}
+ if (discarded_datestr && (parse_datetime_flags & PARSE_DATETIME_DEBUG))
+error (0, 0, _("only using last of multiple -d options"));
+
+ if (discarded_set_datestr && (parse_datetime_flags & PARSE_DATETIME_DEBUG))
+error (0, 0, _("only using last of multiple -s options"));
+
if (optind < argc)
{
if (optind + 1 < argc)
diff --git a/tests/misc/date-debug.sh b/tests/misc/date-debug.sh
index 0b5217611..5c38dee41 100755
--- a/tests/misc/date-debug.sh
+++ b/tests/misc/date-debug.sh
@@ -298,4 +298,14 @@ sed '1s/(Y-M-D) [0-9][0-9][0-9][0-9]-/(Y-M-D) -/' out9_t > out9 \
compare exp9 out9 || fail=1
+# Diagnose discarded -d arguments
+echo 'date: only using last of multiple -d options' > exp
bug#55401: date man page
On 13/05/2022 20:10, t0th wrote:
Man page of date command should make explicit that -d and -r options are
mutually exclusive.
Right. More accurately, we might have a sentence to say that:
"All options to specify the date to display are mutually exclusive.
I.e.: --date, --file, --reference, --resolution".
However...
date -d -3 minutes -r tmp.txt "+%Y%m%d_%H%M"
date: the options to specify dates for printing are mutually exclusive
As you've seen, one might expect to be able to combine, as -d can be relative.
So theoretically we could support this (with the attached),
to honor the relative adjustment, but give precedence to a non relative date.
$ src/date -r src/ls.c -d '-3 minutes'
Fri 15 Apr 2022 16:30:53 IST
$ src/date -r src/ls.c -d '1/1/2022'
Sat 01 Jan 2022 00:00:00 GMT
In fact touch(1) behaves like this, which suggests date(1) should also.
From the info docs for the touch --reference option:
"--reference
Use the times of the reference FILE instead of the current time.
If this option is combined with the --date=TIME
(-d TIME) option, the reference FILES's time is
the origin for any relative TIMEs given, but is otherwise ignored."
BTW, one might also expect that multiple -d options might combine like this,
however currently we silently ignore multiple -d (or -s) options.
The attached also at least warns about this with --debug:
$ date --debug -d '15/4/2022' -d '-3 minutes'
date: discarding previous -d: ‘15/4/2022’
date: parsed relative part: -3 minutes
...
cheers,
Pádraigdiff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 7bca37b71..ae6ec4def 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -16058,7 +16058,8 @@ is not set. @xref{TZ Variable,, Specifying the Time Zone with
@cindex formatting times
If given an argument that starts with a @samp{+}, @command{date} prints the
current date and time (or the date and time specified by the
-@option{--date} option, see below) in the format defined by that argument,
+@option{--date}, @option{--file}, or @option{--reference} options, see below)
+in the format defined by that argument,
which is similar to that of the @code{strftime} function. Except for
conversion specifiers, which start with @samp{%}, characters in the
format string are printed unchanged. The conversion specifiers are
@@ -16502,6 +16503,9 @@ for the @option{--date} (@option{-d}) and @option{--file}
@opindex --reference
Display the date and time of the last modification of @var{file},
instead of the current date and time.
+If this option is combined with the @option{--date} or @option{--file}
+options, the reference @var{file}'s time is
+the origin for any relative @var{time}s given, but is otherwise ignored.
@item --resolution
@opindex --resolution
diff --git a/src/date.c b/src/date.c
index 9a282e2f5..de94136fe 100644
--- a/src/date.c
+++ b/src/date.c
@@ -420,6 +420,8 @@ main (int argc, char **argv)
switch (optc)
{
case 'd':
+ if (datestr && (parse_datetime_flags & PARSE_DATETIME_DEBUG))
+error (0, 0, _("discarding previous -d: %s"), quote (datestr));
datestr = optarg;
break;
case DEBUG_DATE_PARSING_OPTION:
@@ -469,6 +471,8 @@ main (int argc, char **argv)
new_format = rfc_email_format;
break;
case 's':
+ if (set_datestr && (parse_datetime_flags & PARSE_DATETIME_DEBUG))
+error (0, 0, _("discarding previous -s: %s"), quote (set_datestr));
set_datestr = optarg;
set_date = true;
break;
@@ -494,8 +498,7 @@ main (int argc, char **argv)
}
}
- int option_specified_date = (!!datestr + !!batch_file + !!reference
- + get_resolution);
+ int option_specified_date = (!!datestr + !!batch_file + get_resolution);
if (option_specified_date > 1)
{
@@ -511,6 +514,9 @@ main (int argc, char **argv)
usage (EXIT_FAILURE);
}
+ /* Use as base for other "relative" specified dates. */
+ option_specified_date += !!reference;
+
if (optind < argc)
{
if (optind + 1 < argc)
@@ -597,7 +603,8 @@ main (int argc, char **argv)
die (EXIT_FAILURE, errno, "%s", quotef (reference));
when = get_stat_mtime ();
}
- else if (get_resolution)
+
+ if (get_resolution)
{
long int res = gettime_res ();
when.tv_sec = res / TIMESPEC_HZ;
@@ -605,9 +612,10 @@ main (int argc, char **argv)
}
else
{
+ struct timespec *now = reference ? : NULL;
if (set_datestr)
datestr = set_datestr;
- valid_date = parse_datetime2 (, datestr, NULL,
+ valid_date = parse_datetime2 (, datestr, now,
parse_datetime_flags,
tz, tzstring);
}
bug#55401: date man page
Man page of date command should make explicit that -d and -r options are mutually exclusive. date -d -3 minutes -r tmp.txt "+%Y%m%d_%H%M" date: the options to specify dates for printing are mutually exclusive
bug#55183: date
tag 55183 notabug close 55183 stop On 29/04/2022 13:59, danilopereira82--- via GNU coreutils Bug Reports wrote: %r has a space at the end that makes me insanely angry fix it What's happening is there is no "am_pm" item defined for your locale. Running this with a locale that does define it, you can see: $ LC_TIME=C date +%r 05:00:50 PM $ LC_TIME=zh_CN.utf8 date +%r 下午 05时00分50秒 You can look up these values with: $ LC_TIME=C locale t_fmt_ampm t_fmt am_pm %I:%M:%S %p %H:%M:%S AM;PM Note "t_fmt_ampm" if defined, takes precedence over "t_fmt ampm". You could argue that an empty ampm should not output the space, but that would have to be addressed in the libc strftime() implementation. Another option is to use the more abstract %X format to get the time in the most appropriate for one's locale, which should be setup appropriately for locales that don't use AM/PM. $ LC_ALL=C date +%X 17:00:50 $ LC_ALL=en_US.utf8 date +%X 05:00:50 PM $ LC_ALL=pt_PT.utf8 date +%X 17:00:50 cheers, Pádraig
bug#55183: date
%r has a space at the end that makes me insanely angry fix it
bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.
Am 15.04.2022 00:10, schrieb Paul Eggert: On 4/1hour...4/22 09:48, joerg.boeh...@snafu.de wrote: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leading zeros are being removed. Similar wording is used elsewhere: %M minute (00..59) %m month (01..12) %H hour (00..23) %W week number of year, with Monday as first day of week (00..53) It's true that nanoseconds are more complicated than the others. However, it's not clear whether all the little details need to be in the man page, or how to summarize those details concisely. The problem is imo the naming: second, minute, hour ... are all integral values counting from 0 to some max. value. Thus everybody expects that zeros are padded to the left side. But %N is now considered the fractional part of the second in nanoseconds granularity or the positions after decimal point. Thus everybody can assume that the padding is applied to the right. I think it's very important that the user quickly grasps the meaning of the formats from the man page to avoid frustration.
bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.
On 4/14/22 09:48, joerg.boeh...@snafu.de wrote: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leading zeros are being removed. Similar wording is used elsewhere: %M minute (00..59) %m month (01..12) %H hour (00..23) %W week number of year, with Monday as first day of week (00..53) It's true that nanoseconds are more complicated than the others. However, it's not clear whether all the little details need to be in the man page, or how to summarize those details concisely.
bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.
%-N is intended to be used after a decimal point... Please note this intention in the man-page. The current man-page: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leading zeros are being removed.
bug#54916: 4 invalid dates reported by "date"
On 4/13/22 06:30, Martins Ozolins via GNU coreutils Bug Reports wrote: ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1981-04-01" date: invalid date ‘1981-04-01’ This is because your invocation is equivalent to: date +%s --date="1981-04-01 00:00:00" and there was no midnight at that date in Latvia.
bug#54916: 4 invalid dates reported by "date"
Hello software maintainers. While using a script that relies upon the "date" utility to reconstruct historical calendar dates, I came across errors when submitting only the first day of the month April for the years 1981, 1982, 1982 and 1984. I assume no April fools is intended here for public domain software! Here is a transcript of test dates that supposedly are not a radical departure from mostly free human readable date strings I use in the bash shell: On a Lenovo x250: ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1980-04-01" 323384400 ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1981-04-01" date: invalid date ‘1981-04-01’ ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1982-04-01" date: invalid date ‘1982-04-01’ ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1983-04-01" date: invalid date ‘1983-04-01’ ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1984-04-01" date: invalid date ‘1984-04-01’ ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1984-04-02" 449697600 ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1985-04-01" 481147200 rc linux-image-unsigned-4.4.0-194-generic 4.4.0-194.226+8.0trisquel3 amd64Linux-libre kernel image for version 4.4.0 --- I also observed the same results as described above on all other systems and other laptops in my possession: acer: 4.15.0-166.174+9.0trisquel9 asus: 4.4.0-197.229_8.0trisquel3 asus: 5.4.0-91.102+10.0trisquel9 -- Hopefully my usage of the date utility is not in some way abnormal. Regards. Martins
bug#48085: date -d greater than 23 years ago gives error invalid date
On 4/28/21 16:23, Mark Krenz wrote: So I'm not sure if this is a problem with coreutils or a change in the zoneinfo database. Any ideas? This appears to be a problem in the GNU C library, when its mktime deciphers the relatively unusual time zone history of Indiana. I installed the attached patch into Gnulib and propagated it into Coreutils, so the issue should be fixed in the next release of GNU Coreutils. Eventually this patch should migrate from Gnulib to glibc so that other apps get the fix. Thanks for reporting the issue.From 06b2e943be39284783ff81ac6c9503200f41dba3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 19 Feb 2022 15:04:43 -0800 Subject: [PATCH] mktime: improve heuristic for ca-1986 Indiana DST Problem reported by Mark Krenz <https://bugs.gnu.org/48085>. * lib/mktime.c (__mktime_internal): Be more generous about accepting arguments with the wrong value of tm_isdst, by falling back to a one-hour DST difference if we find no nearby DST that is unusual. This fixes a problem where "1986-04-28 00:00 EDT" was rejected when TZ="America/Indianapolis" because the nearest DST timestamp occurred in 1970, a temporal distance too great for the old heuristic. This also also narrows the search a bit, which is a minor performance win. * m4/mktime.m4 (gl_FUNC_MKTIME_WORKS): Check for putenv failures and for Bug#48085. * tests/test-parse-datetime.c (main): Test for setenv failures and for Bug#48085. --- ChangeLog | 17 + lib/mktime.c| 28 m4/mktime.m4| 29 + tests/test-parse-datetime.c | 21 +++-- 4 files changed, 81 insertions(+), 14 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4bf0cec7f0..4d56be83d4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,20 @@ +2022-02-19 Paul Eggert + + mktime: improve heuristic for ca-1986 Indiana DST + Problem reported by Mark Krenz <https://bugs.gnu.org/48085>. + * lib/mktime.c (__mktime_internal): Be more generous about + accepting arguments with the wrong value of tm_isdst, by falling + back to a one-hour DST difference if we find no nearby DST that is + unusual. This fixes a problem where "1986-04-28 00:00 EDT" was + rejected when TZ="America/Indianapolis" because the nearest DST + timestamp occurred in 1970, a temporal distance too great for the + old heuristic. This also also narrows the search a bit, which + is a minor performance win. + * m4/mktime.m4 (gl_FUNC_MKTIME_WORKS): + Check for putenv failures and for Bug#48085. + * tests/test-parse-datetime.c (main): + Test for setenv failures and for Bug#48085. + 2022-02-12 Paul Eggert filevercmp: fix several unexpected results diff --git a/lib/mktime.c b/lib/mktime.c index aa12e28e16..7dc9d67ef9 100644 --- a/lib/mktime.c +++ b/lib/mktime.c @@ -429,8 +429,13 @@ __mktime_internal (struct tm *tp, time with the right value, and use its UTC offset. Heuristic: probe the adjacent timestamps in both directions, - looking for the desired isdst. This should work for all real - time zone histories in the tz database. */ + looking for the desired isdst. If none is found within a + reasonable duration bound, assume a one-hour DST difference. + This should work for all real time zone histories in the tz + database. */ + + /* +1 if we wanted standard time but got DST, -1 if the reverse. */ + int dst_difference = (isdst == 0) - (tm.tm_isdst == 0); /* Distance between probes when looking for a DST boundary. In tzdata2003a, the shortest period of DST is 601200 seconds @@ -441,12 +446,14 @@ __mktime_internal (struct tm *tp, periods when probing. */ int stride = 601200; - /* The longest period of DST in tzdata2003a is 536454000 seconds - (e.g., America/Jujuy starting 1946-10-01 01:00). The longest - period of non-DST is much longer, but it makes no real sense - to search for more than a year of non-DST, so use the DST - max. */ - int duration_max = 536454000; + /* In TZDB 2021e, the longest period of DST (or of non-DST), in + which the DST (or adjacent DST) difference is not one hour, + is 457243209 seconds: e.g., America/Cambridge_Bay with leap + seconds, starting 1965-10-31 00:00 in a switch from + double-daylight time (-05) to standard time (-07), and + continuing to 1980-04-27 02:00 in a switch from standard time + (-07) to daylight time (-06). */ + int duration_max = 457243209; /* Search in both directions, so the maximum distance is half the duration; add the stride to avoid off-by-1 problems. */ @@ -483,6 +490,11 @@ __mktime_internal (struct tm *tp, } } + /* No unusual DST offset was found nearby. Assume one-hour DST. */ + t += 60 * 60 * dst_difference; + if (mktime_min <= t && t <= mktime_max && convert_time (convert, t, )) + goto offset_found;
bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"
On 2/14/22 01:41, Stéphane Archer wrote: is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want To format an arbitrary timestamp you want "+%Y-%m-%dT%H:%M:%S.%1NZ", unless you always want a zero after the period. Closing the bug report as there's no bug here.
bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"
Hi Andreas, thank you for your help, I didn't realize I was using the wrong format for what I wanted. I don't have much experience with the project. The format I wanted was: -MM-DDThh:mm:ss.sZ is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want or are there still some mistakes there? Thank you again and sorry for the bug report, it was late and I was sure to have found a bug ^^" Best regards Stéphane Archer On Mon, Feb 14, 2022 at 9:17 AM Andreas Schwab wrote: > On Feb 13 2022, Stéphane Archer wrote: > > > $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > > 2022-12-25T17:00:00.0Z > > $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > > 2022-01-01T17:00:00.0Z > > $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > > 2023-01-08T17:00:00.0Z > > ``` > > as you can see the input "17 april 2022 + 37 week 5pm" makes date return > > the wrong output for some unknown reason. > > It doesn't make sense to use %G without %V, or to use it in place of %Y. > > $ date -d "17 april 2022 + 37 week 5pm" +'%G/%V %Y-%m-%dT%H:%M:%S.0Z' > 2022/52 2023-01-01T17:00:00.0Z > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." > -- Best Regards, Stephane Archer
bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"
On Feb 13 2022, Stéphane Archer wrote: > $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > 2022-12-25T17:00:00.0Z > $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > 2022-01-01T17:00:00.0Z > $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > 2023-01-08T17:00:00.0Z > ``` > as you can see the input "17 april 2022 + 37 week 5pm" makes date return > the wrong output for some unknown reason. It doesn't make sense to use %G without %V, or to use it in place of %Y. $ date -d "17 april 2022 + 37 week 5pm" +'%G/%V %Y-%m-%dT%H:%M:%S.0Z' 2022/52 2023-01-01T17:00:00.0Z -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"
Hi, I hope this is the right place to do my bug report. please see the following shell input-output: ``` $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' 2022-12-25T17:00:00.0Z $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' 2022-01-01T17:00:00.0Z $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' 2023-01-08T17:00:00.0Z ``` as you can see the input "17 april 2022 + 37 week 5pm" makes date return the wrong output for some unknown reason. Do I do something wrong? I use the following version: date (GNU coreutils) 8.30 -- Best Regards, Stephane Archer
bug#50115: date command arithmetic involving the epoch produces "invalid date"
Thanks for the bug report. I installed the attached patches to Gnulib
and to Coreutils, and the fix should be in the next Coreutils release.From aa0d1e7800903f2d75432d78aa64a0e9770e83f2 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 5 Feb 2022 11:05:44 -0800
Subject: [PATCH] parse-datetime: allow calculations to yield -1
Problem reported by Jeremy Cantrell <https://bugs.gnu.org/50115>.
* lib/parse-datetime.y (parse_datetime_body): When calling mktime,
use an unmodifed and negative tm_wday or tm_yday to detect an error,
as a (time_t) -1 return value is valid on most hosts.
* tests/test-parse-datetime.c (main): Add a test for the bug.
---
ChangeLog | 9 +
lib/parse-datetime.y| 22 +++---
tests/test-parse-datetime.c | 8
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 5445802ea2..18dcb3fe3f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2022-02-05 Paul Eggert
+
+ parse-datetime: allow calculations to yield -1
+ Problem reported by Jeremy Cantrell <https://bugs.gnu.org/50115>.
+ * lib/parse-datetime.y (parse_datetime_body): When calling mktime,
+ use an unmodifed and negative tm_wday or tm_yday to detect an error,
+ as a (time_t) -1 return value is valid on most hosts.
+ * tests/test-parse-datetime.c (main): Add a test for the bug.
+
2022-02-04 Paul Eggert
userspec: help fix GNU ‘id’ incompatibility
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index c40fdcef7f..9fc14c9d46 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -2076,21 +2076,20 @@ parse_datetime_body (struct timespec *result, char const *p,
if (pc.days_seen && ! pc.dates_seen)
{
intmax_t dayincr;
- if (INT_MULTIPLY_WRAPV ((pc.day_ordinal
- - (0 < pc.day_ordinal
- && tm.tm_wday != pc.day_number)),
- 7, )
- || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
-dayincr, )
- || INT_ADD_WRAPV (dayincr, tm.tm_mday, _mday))
-Start = -1;
- else
+ tm.tm_yday = -1;
+ if (! (INT_MULTIPLY_WRAPV ((pc.day_ordinal
+ - (0 < pc.day_ordinal
+ && tm.tm_wday != pc.day_number)),
+ 7, )
+ || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
+ dayincr, )
+ || INT_ADD_WRAPV (dayincr, tm.tm_mday, _mday)))
{
tm.tm_isdst = -1;
Start = mktime_z (tz, );
}
- if (Start == (time_t) -1)
+ if (tm.tm_yday < 0)
{
if (debugging ())
dbg_printf (_("error: day '%s' "
@@ -2156,8 +2155,9 @@ parse_datetime_body (struct timespec *result, char const *p,
tm.tm_min = tm0.tm_min;
tm.tm_sec = tm0.tm_sec;
tm.tm_isdst = tm0.tm_isdst;
+ tm.tm_wday = -1;
Start = mktime_z (tz, );
- if (Start == (time_t) -1)
+ if (tm.tm_wday < 0)
{
if (debugging ())
dbg_printf (_("error: adding relative date resulted "
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
index 059c810cd1..1e7955bc96 100644
--- a/tests/test-parse-datetime.c
+++ b/tests/test-parse-datetime.c
@@ -398,6 +398,14 @@ main (_GL_UNUSED int argc, char **argv)
ASSERT (result.tv_sec == thur2 + ((i + 3) % 7 - 7) * 24 * 3600);
}
+ p = "1970-12-31T23:59:59+00:00 - 1 year"; /* Bug#50115 */
+ now.tv_sec = -1;
+ now.tv_nsec = 0;
+ ASSERT (parse_datetime (, p, ));
+ LOG (p, now, result);
+ ASSERT (result.tv_sec == now.tv_sec
+ && result.tv_nsec == now.tv_nsec);
+
p = "THURSDAY UTC+00"; /* The epoch was on Thursday. */
now.tv_sec = 0;
now.tv_nsec = 0;
--
2.32.0
From cf6c84989968c5081c683bbef77825fc35e03c9d Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 5 Feb 2022 11:08:45 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
index ff208d546..aa0d1e780 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit ff208d546a26fee39a0191297c11560da74b5dee
+Subproject commit aa0d1e7800903f2d75432d78aa64a0e9770e83f2
--
2.32.0
From 8a3dedfef9479c53cd9016139ce00d58a6006ba2 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 5 Feb 2022 13:46:44 -0800
Subject: [PATCH 2/2] date: test against bug#50115
* tests/misc/date.pl: Add test.
---
tests/misc/date.pl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/misc/date.pl b/tests/misc/date.pl
index e9de8e453..
bug#51288: Break date SYNOPSIS into two sections
Thanks for reporting the problem. It'd be a bit of a pain to implement
your suggestion exactly since the synopsis is generated automatically.
However, I installed the attached to try to attack the problem of
confusion that you reported.
It's been years since I set the date by hand but we might as well be
clear about it, if only for nostalgia's sake.From 45f8f2dd2b54c7f4745c277e3f52f3c99cea5b57 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 4 Feb 2022 18:21:06 -0800
Subject: [PATCH] date: improve doc
Problem reported by Dan Jacobson (Bug#51288).
* doc/coreutils.texi (date invocation, Setting the time)
(Options for date):
* src/date.c (usage): Improve doc.
---
doc/coreutils.texi | 23 +++
src/date.c | 3 ++-
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 088d1764c..d3bbf5768 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -15976,9 +15976,14 @@ Synopses:
@example
date [@var{option}]@dots{} [+@var{format}]
date [-u|--utc|--universal] @c this avoids a newline in the output
-[ MMDDhhmm[[CC]YY][.ss] ]
+[@var{MMDDhhmm}[[@var{CC}]@var{YY}][.@var{ss}]]
@end example
+The @command{date} command displays the date and time.
+With the @option{--set} (@option{-s}) option, or with
+@samp{[@var{MMDDhhmm}[[@var{CC}]@var{YY}][.@var{ss}]]},
+it sets the date and time.
+
@vindex LC_TIME
Invoking @command{date} with no @var{format} argument is equivalent to invoking
it with a default format that depends on the @env{LC_TIME} locale category.
@@ -16312,17 +16317,18 @@ modifiers are GNU extensions.
@cindex time setting
@cindex appropriate privileges
-If given an argument that does not start with @samp{+}, @command{date} sets
-the system clock to the date and time specified by that argument (as
-described below). You must have appropriate privileges to set the
-system clock. Note for changes to persist across a reboot, the
+You must have appropriate privileges to set the
+system clock. For changes to persist across a reboot, the
hardware clock may need to be updated from the system clock, which
might not happen automatically on your system.
-The argument must consist entirely of digits, which have the following
-meaning:
+To set the clock, you can use the @option{--set} (@option{-s}) option
+(@pxref{Options for date}). To set the clock without using GNU
+extensions, you can give @command{date} an argument of the form
+@samp{@var{MMDDhhmm}[[@var{CC}]@var{YY}][.@var{ss}]} where each two-letter
+component stands for two digits with the following meanings:
-@table @samp
+@table @var
@item MM
month
@item DD
@@ -16352,6 +16358,7 @@ relative to Universal Time rather than to the local time zone.
@cindex options for @command{date}
The program accepts the following options. Also see @ref{Common options}.
+Except for @option{-u}, these options are all GNU extensions to POSIX.
@table @samp
diff --git a/src/date.c b/src/date.c
index 0915d7c64..163141adc 100644
--- a/src/date.c
+++ b/src/date.c
@@ -135,7 +135,8 @@ Usage: %s [OPTION]... [+FORMAT]\n\
"),
program_name, program_name);
fputs (_("\
-Display the current time in the given FORMAT, or set the system date.\n\
+Display date and time in the given FORMAT.\n\
+With -s, or with [MMDDhhmm[[CC]YY][.ss]], set the date and time.\n\
"), stdout);
emit_mandatory_arg_note ();
--
2.34.1
bug#53033: date has multiple "first saturday"s?
Just a quick comment as a lurker on the list: This was a very interesting discussion, and it's discussions like these that I like following the list for. Learned a few little things here. Side note: Where I live in Canada, if someone refers to "next Saturday" in conversation, one never knows if they mean (to use the `date` syntax) "first saturday" or "second saturday". I avoid the phrase whenever possible. Paul On Mon, Jan 10, 2022 at 5:34 PM Darryl Okahata via GNU coreutils Bug Reports wrote: > Hmmm, it might be that I'm misunderstanding the syntax. I'm used to > specifying dates for repeating calendar events, and, to me, "first > Saturday" means the "first Saturday of the month", and not the next > Saturday from now. > > -- Darryl > > -Original Message- > From: Bob Proulx > Sent: Monday, January 10, 2022 2:11 PM > To: Darryl Okahata > Cc: 53...@debbugs.gnu.org > Subject: Re: bug#53033: date has multiple "first saturday"s? > > Darryl Okahata wrote: > > Bob Proulx wrote: > > Inconsistencies like this are why I wish it had never been > implemented. Best to avoid the syntax completely. > > > > Thanks. I'll avoid date and use either python or ruby to get this info. > > To be clear what I meant was that I would avoid the ordinal word descripts > such as first, second, and third because as documented the use of second is > already used for the time unit. I meant that instead it would be better to > use the actual numbers 1, 2, and 3, to avoid that problem. > > However reading your report again I now question whether I understand what > you were trying to report specifically. Initially you wrote: > > $ date -d "first saturday" > Sat Jan 8 00:00:00 PST 2022 > > Running it again today I get. > > $ date -d "first saturday" > Sat Jan 15 12:00:00 AM MST 2022 > > $ date -d "next saturday" > Sat Jan 15 12:00:00 AM MST 2022 > > That's the first Saturday after now. The debug is valuable information. > > $ date --debug -d 'first saturday' > date: parsed day part: next/first Sat (day ordinal=1 number=6) > date: input timezone: system default > date: warning: using midnight as starting time: 00:00:00 > date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-15 00:00:00' > date: starting date/time: '(Y-M-D) 2022-01-15 00:00:00' > date: '(Y-M-D) 2022-01-15 00:00:00' = 164223 epoch-seconds > date: timezone: system default > date: final: 164223.0 (epoch-seconds) > date: final: (Y-M-D) 2022-01-15 07:00:00 (UTC) > date: final: (Y-M-D) 2022-01-15 00:00:00 (UTC-07) > Sat Jan 15 12:00:00 AM MST 2022 > > Is it useful to know the date, say..., three Saturdays from now? I am > sure there is a good case for it. But it always leaves me scratching my > head wondering. Because it is basically working with the date of today, at > midnight, then the next Saturday. > > $ date --debug -d 'third saturday' > date: parsed day part: third Sat (day ordinal=3 number=6) > date: input timezone: system default > date: warning: using midnight as starting time: 00:00:00 > date: new start date: 'third Sat' is '(Y-M-D) 2022-01-29 00:00:00' > date: starting date/time: '(Y-M-D) 2022-01-29 00:00:00' > date: '(Y-M-D) 2022-01-29 00:00:00' = 1643439600 epoch-seconds > date: timezone: system default > date: final: 1643439600.0 (epoch-seconds) > date: final: (Y-M-D) 2022-01-29 07:00:00 (UTC) > date: final: (Y-M-D) 2022-01-29 00:00:00 (UTC-07) > Sat Jan 29 12:00:00 AM MST 2022 > > It seems to me that it would be just as clear to use numbers in that > position so as to avoid ambiguity. > > $ date --debug -d '2 saturday' > date: parsed day part: (SECOND) Sat (day ordinal=2 number=6) > date: input timezone: system default > date: warning: using midnight as starting time: 00:00:00 > date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00' > date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00' > date: '(Y-M-D) 2022-01-22 00:00:00' = 1642834800 epoch-seconds > date: timezone: system default > date: final: 1642834800.0 (epoch-seconds) > date: final: (Y-M-D) 2022-01-22 07:00:00 (UTC) > date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-07) > Sat Jan 22 12:00:00 AM MST 2022 > > There is no need for "second" in the "second saturday" when using the > relative time "2 saturday" produces the desired answer. > > My wondering now is if "2 saturday" was actually what was desired at all. > Perhaps it was really wanted to k
bug#53033: date has multiple "first saturday"s?
Hmmm, it might be that I'm misunderstanding the syntax. I'm used to specifying
dates for repeating calendar events, and, to me, "first Saturday" means the
"first Saturday of the month", and not the next Saturday from now.
-- Darryl
-Original Message-
From: Bob Proulx
Sent: Monday, January 10, 2022 2:11 PM
To: Darryl Okahata
Cc: 53...@debbugs.gnu.org
Subject: Re: bug#53033: date has multiple "first saturday"s?
Darryl Okahata wrote:
> Bob Proulx wrote:
> Inconsistencies like this are why I wish it had never been implemented.
> Best to avoid the syntax completely.
>
> Thanks. I'll avoid date and use either python or ruby to get this info.
To be clear what I meant was that I would avoid the ordinal word descripts such
as first, second, and third because as documented the use of second is already
used for the time unit. I meant that instead it would be better to use the
actual numbers 1, 2, and 3, to avoid that problem.
However reading your report again I now question whether I understand what you
were trying to report specifically. Initially you wrote:
$ date -d "first saturday"
Sat Jan 8 00:00:00 PST 2022
Running it again today I get.
$ date -d "first saturday"
Sat Jan 15 12:00:00 AM MST 2022
$ date -d "next saturday"
Sat Jan 15 12:00:00 AM MST 2022
That's the first Saturday after now. The debug is valuable information.
$ date --debug -d 'first saturday'
date: parsed day part: next/first Sat (day ordinal=1 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-15 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-15 00:00:00'
date: '(Y-M-D) 2022-01-15 00:00:00' = 164223 epoch-seconds
date: timezone: system default
date: final: 164223.00000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-15 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-15 00:00:00 (UTC-07)
Sat Jan 15 12:00:00 AM MST 2022
Is it useful to know the date, say..., three Saturdays from now? I am sure
there is a good case for it. But it always leaves me scratching my head
wondering. Because it is basically working with the date of today, at
midnight, then the next Saturday.
$ date --debug -d 'third saturday'
date: parsed day part: third Sat (day ordinal=3 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'third Sat' is '(Y-M-D) 2022-01-29 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-29 00:00:00'
date: '(Y-M-D) 2022-01-29 00:00:00' = 1643439600 epoch-seconds
date: timezone: system default
date: final: 1643439600.00000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-29 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-29 00:00:00 (UTC-07)
Sat Jan 29 12:00:00 AM MST 2022
It seems to me that it would be just as clear to use numbers in that position
so as to avoid ambiguity.
$ date --debug -d '2 saturday'
date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
date: '(Y-M-D) 2022-01-22 00:00:00' = 1642834800 epoch-seconds
date: timezone: system default
date: final: 1642834800.00000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-07)
Sat Jan 22 12:00:00 AM MST 2022
There is no need for "second" in the "second saturday" when using the relative
time "2 saturday" produces the desired answer.
My wondering now is if "2 saturday" was actually what was desired at all.
Perhaps it was really wanted to know the date of the first Saturday of the
month? That's entirely a different problem.
Also, when working with dates I strongly encourage working with UTC.
I went along with the original example. But I feel I should have been
producing examples like this instead with -uR.
$ date -uR --debug -d '2 saturday'
date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
date: input timezone: TZ="UTC0" environment value or -u
date: warning: using midnight as starting time: 00:00:00
date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
date: '(Y-M-D) 2022-01-22 00:00:00' = 1642809600 epoch-seconds
date: timezone: Universal Time
date: final: 1642809600.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC+00)
Sat, 22 Jan 2022 00:00:00 +
Bob
bug#53033: date has multiple "first saturday"s?
Darryl Okahata wrote:
> Bob Proulx wrote:
> Inconsistencies like this are why I wish it had never been implemented.
> Best to avoid the syntax completely.
>
> Thanks. I'll avoid date and use either python or ruby to get this info.
To be clear what I meant was that I would avoid the ordinal word
descripts such as first, second, and third because as documented the
use of second is already used for the time unit. I meant that instead
it would be better to use the actual numbers 1, 2, and 3, to avoid
that problem.
However reading your report again I now question whether I understand
what you were trying to report specifically. Initially you wrote:
$ date -d "first saturday"
Sat Jan 8 00:00:00 PST 2022
Running it again today I get.
$ date -d "first saturday"
Sat Jan 15 12:00:00 AM MST 2022
$ date -d "next saturday"
Sat Jan 15 12:00:00 AM MST 2022
That's the first Saturday after now. The debug is valuable
information.
$ date --debug -d 'first saturday'
date: parsed day part: next/first Sat (day ordinal=1 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-15 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-15 00:00:00'
date: '(Y-M-D) 2022-01-15 00:00:00' = 164223 epoch-seconds
date: timezone: system default
date: final: 164223.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-15 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-15 00:00:00 (UTC-07)
Sat Jan 15 12:00:00 AM MST 2022
Is it useful to know the date, say..., three Saturdays from now? I am
sure there is a good case for it. But it always leaves me scratching
my head wondering. Because it is basically working with the date of
today, at midnight, then the next Saturday.
$ date --debug -d 'third saturday'
date: parsed day part: third Sat (day ordinal=3 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'third Sat' is '(Y-M-D) 2022-01-29 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-29 00:00:00'
date: '(Y-M-D) 2022-01-29 00:00:00' = 1643439600 epoch-seconds
date: timezone: system default
date: final: 1643439600.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-29 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-29 00:00:00 (UTC-07)
Sat Jan 29 12:00:00 AM MST 2022
It seems to me that it would be just as clear to use numbers in that
position so as to avoid ambiguity.
$ date --debug -d '2 saturday'
date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
date: '(Y-M-D) 2022-01-22 00:00:00' = 1642834800 epoch-seconds
date: timezone: system default
date: final: 1642834800.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 07:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-07)
Sat Jan 22 12:00:00 AM MST 2022
There is no need for "second" in the "second saturday" when using the
relative time "2 saturday" produces the desired answer.
My wondering now is if "2 saturday" was actually what was desired at
all. Perhaps it was really wanted to know the date of the first
Saturday of the month? That's entirely a different problem.
Also, when working with dates I strongly encourage working with UTC.
I went along with the original example. But I feel I should have been
producing examples like this instead with -uR.
$ date -uR --debug -d '2 saturday'
date: parsed day part: (SECOND) Sat (day ordinal=2 number=6)
date: input timezone: TZ="UTC0" environment value or -u
date: warning: using midnight as starting time: 00:00:00
date: new start date: '(SECOND) Sat' is '(Y-M-D) 2022-01-22 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
date: '(Y-M-D) 2022-01-22 00:00:00' = 1642809600 epoch-seconds
date: timezone: Universal Time
date: final: 1642809600.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC+00)
Sat, 22 Jan 2022 00:00:00 +
Bob
bug#53033: date has multiple "first saturday"s?
Bob Proulx wrote: Inconsistencies like this are why I wish it had never been implemented. Best to avoid the syntax completely. Thanks. I'll avoid date and use either python or ruby to get this info. -- Darryl
bug#53033: date has multiple "first saturday"s?
Darryl Okahata via GNU coreutils Bug Reports wrote: > From coreutils 9.0 (note the difference between the "second" and "third" > saturdays): ... > $ src/date --debug -d "second saturday" > date: parsed relative part: +1 seconds Caution! The date utility can't parse second due to second being a unit of time. The documentation says: A few ordinal numbers may be written out in words in some contexts. This is most useful for specifying day of the week items or relative items (see below). Among the most commonly used ordinal numbers, the word ‘last’ stands for -1, ‘this’ stands for 0, and ‘first’ and ‘next’ both stand for 1. Because the word ‘second’ stands for the unit of time there is no way to write the ordinal number 2, but for convenience ‘third’ stands for 3, ‘fourth’ for 4, ‘fifth’ for 5, ‘sixth’ for 6, ‘seventh’ for 7, ‘eighth’ for 8, ‘ninth’ for 9, ‘tenth’ for 10, ‘eleventh’ for 11 and ‘twelfth’ for 12. Inconsistencies like this are why I wish it had never been implemented. Best to avoid the syntax completely. Bob
bug#53033: date has multiple "first saturday"s?
$ src/date --debug -d "second saturday"
date: parsed relative part: +1 seconds
date: parsed day part: Sat (day ordinal=0 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns),
date: new time = 1641628801 epoch-seconds
date: timezone: system default
date: final: 1641628801.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 8 00:00:01 PST 2022
I just noticed that "second Saturday" is being parsed as "Saturday + 1 second".
-- Darryl
-Original Message-
From: Bug-coreutils
On Behalf Of Darryl Okahata via GNU coreutils Bug Reports
Sent: Wednesday, January 5, 2022 3:15 PM
To: sch...@linux-m68k.org; 53...@debbugs.gnu.org
Subject: bug#53033: date has multiple "first saturday"s?
From coreutils 9.0 (note the difference between the "second" and "third"
saturdays):
$ src/date --debug -d "first saturday"
date: parsed day part: next/first Sat (day ordinal=1 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: timezone: system default
date: final: 1641628800.00000 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 8 00:00:00 PST 2022
$ src/date --debug -d "second saturday"
date: parsed relative part: +1 seconds
date: parsed day part: Sat (day ordinal=0 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00'
date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds
date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns),
date: new time = 1641628801 epoch-seconds
date: timezone: system default
date: final: 1641628801.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC)
date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 8 00:00:01 PST 2022
$ src/date --debug -d "third saturday"
date: parsed day part: third Sat (day ordinal=3 number=6)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'third Sat' is '(Y-M-D) 2022-01-22 00:00:00'
date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00'
date: '(Y-M-D) 2022-01-22 00:00:00' = 1642838400 epoch-seconds
date: timezone: system default
date: final: 1642838400.0 (epoch-seconds)
date: final: (Y-M-D) 2022-01-22 08:00:00 (UTC)
date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-08)
src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’
Sat Jan 22 00:00:00 PST 2022
-- Darryl
-Original Message-
From: Andreas Schwab
Sent: Wednesday, January 5, 2022 2:10 PM
To: Darryl Okahata via GNU coreutils Bug Reports
Cc: 53...@debbugs.gnu.org; Darryl Okahata
Subject: Re: bug#53033: date has multiple "first saturday"s?
On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote:
> $ date -d "first saturday"
> Sat Jan 8 00:00:00 PST 2022
>
> Unless there is some weird definition of "first Saturday", shouldn't
> this be the 1st (New Year's Day)?
Try date --debug.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And
now for something completely different."
bug#53033: date has multiple "first saturday"s?
From coreutils 9.0 (note the difference between the "second" and "third" saturdays): $ src/date --debug -d "first saturday" date: parsed day part: next/first Sat (day ordinal=1 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'next/first Sat' is '(Y-M-D) 2022-01-08 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00' date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds date: timezone: system default date: final: 1641628800.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-08 08:00:00 (UTC) date: final: (Y-M-D) 2022-01-08 00:00:00 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 8 00:00:00 PST 2022 $ src/date --debug -d "second saturday" date: parsed relative part: +1 seconds date: parsed day part: Sat (day ordinal=0 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'Sat' is '(Y-M-D) 2022-01-08 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-08 00:00:00' date: '(Y-M-D) 2022-01-08 00:00:00' = 1641628800 epoch-seconds date: after time adjustment (+0 hours, +0 minutes, +1 seconds, +0 ns), date: new time = 1641628801 epoch-seconds date: timezone: system default date: final: 1641628801.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-08 08:00:01 (UTC) date: final: (Y-M-D) 2022-01-08 00:00:01 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 8 00:00:01 PST 2022 $ src/date --debug -d "third saturday" date: parsed day part: third Sat (day ordinal=3 number=6) date: input timezone: system default date: warning: using midnight as starting time: 00:00:00 date: new start date: 'third Sat' is '(Y-M-D) 2022-01-22 00:00:00' date: starting date/time: '(Y-M-D) 2022-01-22 00:00:00' date: '(Y-M-D) 2022-01-22 00:00:00' = 1642838400 epoch-seconds date: timezone: system default date: final: 1642838400.0 (epoch-seconds) date: final: (Y-M-D) 2022-01-22 08:00:00 (UTC) date: final: (Y-M-D) 2022-01-22 00:00:00 (UTC-08) src/date: output format: ‘%a %b %e %H:%M:%S %Z %Y’ Sat Jan 22 00:00:00 PST 2022 -- Darryl -Original Message- From: Andreas Schwab Sent: Wednesday, January 5, 2022 2:10 PM To: Darryl Okahata via GNU coreutils Bug Reports Cc: 53...@debbugs.gnu.org; Darryl Okahata Subject: Re: bug#53033: date has multiple "first saturday"s? On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote: > $ date -d "first saturday" > Sat Jan 8 00:00:00 PST 2022 > > Unless there is some weird definition of "first Saturday", shouldn't > this be the 1st (New Year's Day)? Try date --debug. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#53033: date has multiple "first saturday"s?
On Jan 05 2022, Darryl Okahata via GNU coreutils Bug Reports wrote: > $ date -d "first saturday" > Sat Jan 8 00:00:00 PST 2022 > > Unless there is some weird definition of "first Saturday", shouldn't this be > the 1st (New Year's Day)? Try date --debug. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#53033: date has multiple "first saturday"s?
(This has been verified to occur with 9.0.) $ date -d "first saturday" Sat Jan 8 00:00:00 PST 2022 Unless there is some weird definition of "first Saturday", shouldn't this be the 1st (New Year's Day)? Also, I ran this last week (I think on the 29th or the 30th), and it did properly report the 1st. Now that it's after the 1st, it's reporting the 8th. Side note: I'm happy that it reported Jan 1st as the "first Saturday" even though the date was still in December, but is there a way of getting the "first Saturday" for an arbitrary year/month? All my attempts just get the "invalid date" error. -- Darryl
bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates
On Wed, Dec 15, 2021 at 02:09:29PM -0800, Paul Eggert wrote: > On 12/15/21 12:39, Mike Marchywka wrote: > > $echo 2000 | date +%Y -f- > > 2021 > > How about this instead? The idea is to avoid > adding features if they can easily be > implemented with some other standard utility. > This way, you can write your shell scripts now > rather than waiting for a future fix (plus, it > keeps 'date' simpler). > > echo 2000 | sed 's/$/-07-01/' | date +%Y -f- > That is great until the input format is -MM-DD :) The point of using date was to get all the internal stuff that deals with ambiguous formats and probably a lot of other people do that too. The info documentation does point out how ambiguous the human readable dates are. I guess 2000 could also be ms since epoch. I am calling date from c++ and could just ias easily wrap it in another c++ program to deal with this but thought it was of more general interest and I did not want to make another kluge. Generally I agree with your approach but if date is going to be a swiss army knife for date conversions it makes some sense to allow user selection of ambiguity resolution doesn't it? Thanks. -- mike marchywka 306 charles cox canton GA 30115 USA, Earth marchy...@hotmail.com 404-788-1216 ORCID: -0001-9237-455X
bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates
On 12/15/21 14:24, Mike Marchywka wrote: if date is going to be a swiss army knife for date conversions it makes some sense to allow user selection of ambiguity resolution doesn't it? There are thousands of possible data conversions and I'm not sure we want to head down the road of trying to handle them all. That being said, this particular conversion might be worth the trouble. However, 'date' uses the same date parser that a lot of other GNU programs do. Surely if there's a change to be made to date parsing it should be made there, not just to 'date', so that all the other programs can use the new functionality.
bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates
On 12/15/21 12:39, Mike Marchywka wrote: $echo 2000 | date +%Y -f- 2021 How about this instead? The idea is to avoid adding features if they can easily be implemented with some other standard utility. This way, you can write your shell scripts now rather than waiting for a future fix (plus, it keeps 'date' simpler). echo 2000 | sed 's/$/-07-01/' | date +%Y -f-
bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates
I'm trying to implement the options shown below. I downloaded the coreutils source for my distro and don't expect a problem compling and implementing it. However, is there any interest in adding similar functions to the main code? I would imagine something like, date --option=four-digits-are-,invalid-output-blank-line My immediate concern is getting this to take the input as a year rather than HHMM and it would be easier to make date more versatile than put logic around it, $echo 2000 | date +%Y -f- 2021 not sure if anyone else would want that. Thanks. Mike Marchywka 306 Charles Cox Drive Canton, GA 30115 470-758-0799 404-788-1216 From: Mike Marchywka Sent: Wednesday, December 15, 2021 2:08 PM To: coordina...@translationproject.org Subject: the ubuntu "date" command info pointed me to you, question on modification I wanted to add an option to the linux date command to deal with pure number date stings - allowing for a 4 digit number to be a year instead of HHMM - which should be easy for me to do but I wanted to see how it integrates. Also, I wanted an output option, that I could write, to send an invalid message to stdout instead of stderr. How should I proceed? Thanks. Mike Marchywka 306 Charles Cox Drive Canton, GA 30115 470-758-0799 404-788-1216
bug#51288: Break date SYNOPSIS into two sections
On the 'date' man and info pages, SYNOPSIS date [OPTION]... [+FORMAT] date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] Synopses: date [OPTION]... [+FORMAT] date [-u|--utc|--universal] [ MMDDhhmm[[CC]YY][.ss] ] please break these down into: printing the date: date [OPTION]... [+FORMAT] setting the date: date [-u|--utc|--universal] [ MMDDhhmm[[CC]YY][.ss] ] date [-s|--set] DATESTR else the user in a panic to set the date, will try # date -s 10140110 date: cannot set date: Invalid argument Mon Jan 10 00:00:00 LMT 1014 Instead of $ date10140110 Only on (info "(coreutils) Setting the time") is the mystery revealed. P.S., on that page you should mention the MMDDhhmm... string again, not just its components.
bug#50115: date command arithmetic involving the epoch produces "invalid date"
Using `date --utc --date="..."` with a date specification that decrements by years that should result in epoch=0 (1969-12-31T23:59:59+00:00) produces an "invalid date" error message. The following commands should illustrate the problem: Notice that the only difference between the starting dates is 1 second. ```sh $ date -u -d "1970-12-31T23:59:59+00:00 - 1 year" date: invalid date ‘1970-12-31T23:59:59+00:00 - 1 year’ $ date -u -d "1970-12-31T23:59:58+00:00 - 1 year" Wed Dec 31 11:59:58 PM UTC 1969 ``` The dates are only considered invalid if they fall on epoch=0: ```sh $ date -u -d "1971-12-31T23:59:59+00:00 - 2 year" date: invalid date ‘1971-12-31T23:59:59+00:00 - 2 year’ $ date -u -d "1972-12-31T23:59:59+00:00 - 3 year" date: invalid date ‘1972-12-31T23:59:59+00:00 - 3 year’ ``` Going the other direction seems to work: ```sh $ date -u -d "1969-01-01T00:00:00+00:00 + 1 year" Thu Jan 1 12:00:00 AM UTC 1970 ``` It only seems to error when decrementing by years: ```sh date -u -d "1970-01-01T00:00:01+00:00 - 1 second" Thu Jan 1 12:00:00 AM UTC 1970 ``` It only seems to error when using --utc, because the following works (my time zone is America/Chicago): ```sh $ date -d "Wed Dec 31 06:00:00 PM CST 1970 - 1 year" +%s 0 ```
bug#48353: result of date is wrong if Etc/GMT is used
On 5/11/21 3:17 AM, Thomas Güttinger wrote: The date command inverts the sign if TZ is set with Etc/GMT. That's a feature, not a bug. The Etc zones are documented to use the opposite sign, to be consistent with POSIX settings like TZ='<+05>-5'. $ date -u; TZ='<+05>-5' date; TZ=Etc/GMT-5 date Tue May 11 19:07:34 UTC 2021 Wed May 12 00:07:34 +05 2021 Wed May 12 00:07:34 +05 2021
bug#48353: result of date is wrong if Etc/GMT is used
The date command inverts the sign if TZ is set with Etc/GMT. Example: TZ=':Etc/GMT+5' date Result: Di 11. Mai 05:08:48 -05 2021 Tested with version coreutils-8.28 and coreutils 8.32-1. Thomas Güttinger Linux Developer guettin...@igel.com<http://http//mailto:%7BE-mail%7D> www.igel.com<http://www.igel.com> Come join the IGEL community and Follow us<https://www.igel.com/follow-us-now/> IGEL Technology GmbH Forschungs- und Entwicklungsabteilung Hermanstr. 17 86150 Augsburg Germany IGEL Technology GmbH, Hermann-Ritter-Straße 110, 28197 Bremen, Germany Geschäftsführer: Jedediah Ayres (CEO), Matthias Haas (CTO) Amtsgericht Bremen: HRB 20636 VAT-ID: DE 219524359, WEEE-Reg.-No. DE 79295479
bug#48085: date -d greater than 23 years ago gives error invalid date
Well it seems that this might actually be related to timezone database files. My timezone is America/Indianapolis but I noticed when I set the timezone to America/New_York or UTC that this problem doesn't happen $ TZ=America/Indianapolis date -d "now - 9001 days" date: invalid date ‘now - 9001 days’ $ TZ=America/New_York date -d "now - 9001 days" Thu 05 Sep 1996 07:05:55 PM EDT $ TZ=UTC date -d "now - 9001 days" Thu 05 Sep 1996 11:05:59 PM UTC $ TZ=America/Metlakatla date -d "now - 9001 days" date: invalid date ‘now - 9001 days’ $ I found that last one after trying a for loop in /usr/share/zoneinfo/America So I'm not sure if this is a problem with coreutils or a change in the zoneinfo database. Any ideas? Mark
bug#48085: date -d greater than 23 years ago gives error invalid date
Further investigating this problem it appears that at least today it doesn't like going back past September 26th, 1997. But only when the time delta is specified in years months or days. You can go back further if it's specified in total amounts of hours minutes or seconds. $ date -d "now - 283 months" Sun 28 Sep 1997 03:42:05 PM EST $ date -d "now - 284 months" date: invalid date ‘now - 284 months’ $ date -d "now - 283 months - 2 days" Fri 26 Sep 1997 03:42:31 PM EST $ date -d "now - 283 months - 3 days" date: invalid date ‘now - 283 months - 3 days’ $ date -d "now - 8615 days" Fri Sep 26 03:52:30 PM EST 1997 $ date -d "now - 8616 days" date: invalid date ‘now - 8616 days’ $ date -d "now - 206804 hours" Wed Sep 24 07:54:15 PM EST 1997 $ date -d "now - 12408240 minutes" Wed Sep 24 08:03:50 PM EST 1997 $ date -d "now - 74459 seconds" Tue Sep 23 05:20:23 PM EST 1997 I don't see anything special about Sept 25th, 1997 in terms of it's numeric value: $ date -d "1997-09-25" +%s 875163600 Or the delta from now to then. 8615*86400 = 744336000 Very weird. I'll be curious to see what turns out to be the problem. I also found a system I'm running that has coreutils 8.30 and it did not have the problem, so that narrows the gap a bit. Mark
bug#48085: date -d greater than 23 years ago gives error invalid date
I ran the following expecting it to provide me with the date 35 years ago date -d "now - 35 years" Instead I received the error: date: invalid date ‘now - 35 years’ Testing it further I found that the break point is at 24 years: $ date --version date (GNU coreutils) 8.32 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. $ date -d "now - 23 years" Tue Apr 28 03:20:37 PM EST 1998 $ date -d "now - 24 years" date: invalid date ‘now - 24 years’ $ I compiled from the latest coreutils source and found it to have the same issue: $ cd coreutils/src/ $ ./date --version date (GNU coreutils) 8.32.143-62a7c Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. $ date "now - 23 years" date: invalid date ‘now - 23 years’ $ date -d "now - 23 years" Tue Apr 28 03:21:09 PM EST 1998 $ date -d "now - 24 years" date: invalid date ‘now - 24 years’ $ I found that this did work on a system running coreutils 8.23 so something seems to have broken since then. These are all Linux systems that I've tried this on. The system I tested on was a fresh Ubuntu 21.04 VM. Linux ubuntu2104 5.11.0-16-generic #17-Ubuntu SMP Wed Apr 14 20:12:43 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Thanks, Mark
bug#47476: relative date of -1 month shows the wrong month
Lars Nooden wrote:
> On March 29, 2021, if a relative date of '-1 month' is passed to 'date',
> then the output shows March instead of February.
The date manual includes this section on relative months.
The fuzz in units can cause problems with relative items. For
example, ‘2003-07-31 -1 month’ might evaluate to 2003-07-01, because
2003-06-31 is an invalid date. To determine the previous month more
reliably, you can ask for the month before the 15th of the current
month. For example:
$ date -R
Thu, 31 Jul 2003 13:02:39 -0700
$ date --date='-1 month' +'Last month was %B?'
Last month was July?
$ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'
Last month was June!
This exactly covers the initial bug report. Because March 29, 2021
minus 1 month results in the invalid date February 29, 2021 which not
being a leap year does not exist. What _should_ be the result if the
date one month ago does not exist? And the answer to that will mostly
depend upon what purpose the question was being asked.
When dealing with time in months it also depends upon what you are
needing done. If it is the 7th of the month and you want to generate
a date that is also the 7th but one month later or earlier then if it
is March 7th and generate February 7th then that will be fewer days
difference than if it is were June 7th and deciding May 7th is the
month early. Due to the nature of having a different number of days
in different months. But if that was what I wanted then I would
determine what was the month prior and generate a new datestamp using
the current day of the month.
[[Aside:
Off the top of my head and hopefully without a trivial bug. I welcome
corrections if I made a mistake in this. But this is still not
completely general purpose.
$ date "+%F %T"
2021-04-04 20:50:19
$ date "+%Y-$(date --date="$(date +%Y-%m-15) -1 month" +%m)-%d %H:%M:%S"
2021-03-04 20:50:54
*HOWEVER* that still does not handle the case of the original poster's
report about what happens on March 29, 2021 minus one month? It can't
be February 29th! Isn't that the same as March 1st?
]]
Perhaps instead of the code using 30 day months it should use the
number of days in the current month? Then on March 31, 2021 -1 month
since March has 31 days that would calculate February 28, 2021. Is
that better or worse?
$ date --date="2021-03-31 12:00 + -31 days" "+%F %T"
2021-02-28 05:00:00
Potentially worse! What happens on March 1, 2021 then?
$ date --date="2021-03-01 12:00 + -31 days" "+%F %T"
2021-01-29 05:00:00
In that case we skip over February entirely!
Chris Elvidge wrote:
> Pádraig Brady wrote:
> > The current FAQ (linked below) suggests the workaround of:
> >
> >date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B.'
> >
> > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
>
> It's noticeable that (on my system, CYGWIN-NT and/or Raspbian) 'date -d"now
> -1month"' gives a definitely wrong answer, but 'dateadd now -1mo' gives a
> somewhat more reasonable answer. dateadd is from the dateutils package,
> sometimes dadd and/or dateutils.dadd.
>
> $ date +"%Y-%m-%d %H:%M:%S"
> 2021-03-30 10:37:00
>
> $ date -d"now -1 month" +"%Y-%m-%d %H:%M:%S"
> 2021-03-02 09:37:17
So... Here is the problem with "now". Using "now" is problematic
*some* of the time. Not all of the time. Never when you are trying
it on the command line in the middle of the day. But there are
windows of time around DST time changes when it is problematic. If
you are getting the time now and it is the middle of the day say
around noon then that is far away from time changes. But almost every
seasonal time change there is a bug report from someone who has an
automated process that ran right at the same time as time change
giving them a surprising result and they are filing a bug that it gave
them the wrong answer, because there was no 2am that day, or maybe
there were two 2ams that day, or something.
That's why it is better to test for days using noon as a reference.
And why when checking for months it is better to test for months away
from the change of month. Really the 10th or the 20th would be as
good as the 15th but the 15th is in the middle of every month and why
it ended up getting into the FAQ recommendation.
> $ dateadd now -1mo -f"%Y-%m-%d %H:%M:%S"
> 2021-02-28 09:37:27
I don't know anything about dateadd and it is not part of GNU Coreutils.
Bob
bug#47476: relative date of -1 month shows the wrong month
On 29/03/2021 05:25 pm, Pádraig Brady wrote: On 29/03/2021 16:39, Lars Noodén wrote: Severity: normal Package: coreutils Version: 8.32-4 On March 29, 2021, if a relative date of '-1 month' is passed to 'date', then the output shows March instead of February. $ date; date -d '-1 month'; date -d '1 month ago'; date -d 'last month'; Mon 29 Mar 2021 06:35:43 PM EEST Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET The output shows March when it clearly should show February instead. This impairs the usefulness of the program a lot on certain days. This is a commonly reported issue. I agree the current operation is confusing. I'm working on a change to make the adjustment relative to the input resolution. I.e. operate on a month basis in this case rather than days etc. The current FAQ (linked below) suggests the workaround of: date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B.' cheers, Pádraig https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e It's noticeable that (on my system, CYGWIN-NT and/or Raspbian) 'date -d"now -1month"' gives a definitely wrong answer, but 'dateadd now -1mo' gives a somewhat more reasonable answer. dateadd is from the dateutils package, sometimes dadd and/or dateutils.dadd. $ date +"%Y-%m-%d %H:%M:%S" 2021-03-30 10:37:00 $ date -d"now -1 month" +"%Y-%m-%d %H:%M:%S" 2021-03-02 09:37:17 $ dateadd now -1mo -f"%Y-%m-%d %H:%M:%S" 2021-02-28 09:37:27 -- Chris Elvidge
bug#47476: relative date of -1 month shows the wrong month
On 29/03/2021 16:39, Lars Noodén wrote: Severity: normal Package: coreutils Version: 8.32-4 On March 29, 2021, if a relative date of '-1 month' is passed to 'date', then the output shows March instead of February. $ date; date -d '-1 month'; date -d '1 month ago'; date -d 'last month'; Mon 29 Mar 2021 06:35:43 PM EEST Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET The output shows March when it clearly should show February instead. This impairs the usefulness of the program a lot on certain days. This is a commonly reported issue. I agree the current operation is confusing. I'm working on a change to make the adjustment relative to the input resolution. I.e. operate on a month basis in this case rather than days etc. The current FAQ (linked below) suggests the workaround of: date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B.' cheers, Pádraig https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
bug#47476: relative date of -1 month shows the wrong month
Severity: normal Package: coreutils Version: 8.32-4 On March 29, 2021, if a relative date of '-1 month' is passed to 'date', then the output shows March instead of February. $ date; date -d '-1 month'; date -d '1 month ago'; date -d 'last month'; Mon 29 Mar 2021 06:35:43 PM EEST Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET Mon 01 Mar 2021 05:35:43 PM EET The output shows March when it clearly should show February instead. This impairs the usefulness of the program a lot on certain days.
bug#45695: Date does not work for dates before 1970
zed991 wrote: > On linux, I can use date +%s --date "31 Dec 1969" > The result is -9 > A negative number Which is correct for dates before the 0 time: Thu, 01 Jan 1970 00:00:00 + https://en.wikipedia.org/wiki/Unix_time > But when I try it on Windows (using GNUWin32) it gives me an error - > "invalid date" > > I downloaded date for windows from this link - > http://gnuwin32.sourceforge.net/packages/coreutils.htm > > Is there any fix for Windows? According to that page the last update of the GnuWin project was 2015-05-20 therefore one might think that project is no longer updating now more than five years later. Perhaps it would be good to look for a different MS-Windows port of the software? The usual recommendation is to install Cygwin which generally is a more reliable port of the software. Although I understand that it might be a little heavy for many users. But whichever port to Microsoft you find look to see that it has been updated in the last few years. Generally the GNU Project is all about the source and use on Free(dom) Software systems. Generally most of us are not using Microsoft and therefore it makes it hard for us to help. It really needs a Microsoft person to champion the cause and to keep that system updated. Since this is not a bug in the GNU Coreutils software itself but in the windows port of it I am going to go ahead and close the ticket with this message. But if you have updates about this please send an update to the bug ticket as it would help us know what to say in the future to other Microsoft users. And other people searching the archive will benefit from your experience with it. Bob
bug#45695: Date does not work for dates before 1970
On Wed, 6 Jan 2021, at 16:34, zed991 wrote: > On linux, I can use date +%s --date "31 Dec 1969" > The result is -9 > A negative number > > But when I try it on Windows (using GNUWin32) it gives me an error - > "invalid date" > > I downloaded date for windows from this link - > http://gnuwin32.sourceforge.net/packages/coreutils.htm That specific page refers to coreutils 5.3.0, which was published in 2005. The gnuwin32 website in general doesn't appear to have been updated in over 10 years. My personal recommendation to run coreutils on Windows is WSL2, but there are other options (cygwin etc.) Cheers, Phil
bug#45695: Date does not work for dates before 1970
On linux, I can use date +%s --date "31 Dec 1969" The result is -9 A negative number But when I try it on Windows (using GNUWin32) it gives me an error - "invalid date" I downloaded date for windows from this link - http://gnuwin32.sourceforge.net/packages/coreutils.htm Is there any fix for Windows?
bug#45057: Date has issues with some months in Norwegian
Thanks for the answer. I'll take more time with info next time.
On Sat, 5 Dec 2020 at 21:00, Philip Rowlands
wrote:
> On Sat, 5 Dec 2020, at 15:00, Odne Hellebø wrote:
>
> > But this doesn't work for months may, october, and desember
> > export LANG=nn_NO.utf8
> > for i in {01..12}
> > do
> > mnd=$(date -d "2020-$i-01" +%B)
> > date -d "01-${mnd:0:3}-2020" +%B
> > done
>
> This is documented behaviour:
>
> https://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html
>
> """
> In the current implementation, only English is supported for words and
> abbreviations like ‘AM’, ‘DST’, ‘EST’, ‘first’, ‘January’, ‘Sunday’,
> ‘tomorrow’, and ‘year’.
> """
>
> The reason only mai / okt / des fail is that the other months match in
> English / Norwegian when considering the first three letters.
>
>
> Cheers,
> Phil
>
> januar
> februar
> mars
> april
> mai
> juni
> juli
> august
> september
> oktober
> november
> desember
>
>
>
>
bug#45057: Date has issues with some months in Norwegian
On Sat, 5 Dec 2020, at 15:00, Odne Hellebø wrote:
> But this doesn't work for months may, october, and desember
> export LANG=nn_NO.utf8
> for i in {01..12}
> do
> mnd=$(date -d "2020-$i-01" +%B)
> date -d "01-${mnd:0:3}-2020" +%B
> done
This is documented behaviour:
https://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html
"""
In the current implementation, only English is supported for words and
abbreviations like ‘AM’, ‘DST’, ‘EST’, ‘first’, ‘January’, ‘Sunday’,
‘tomorrow’, and ‘year’.
"""
The reason only mai / okt / des fail is that the other months match in English
/ Norwegian when considering the first three letters.
Cheers,
Phil
januar
februar
mars
april
mai
juni
juli
august
september
oktober
november
desember
bug#45057: Date has issues with some months in Norwegian
This works fine
export LANG=en_GB.utf8
for i in {01..12}
do
mnd=$(date -d "2020-$i-01" +%B)
date -d "01-${mnd:0:3}-2020" +%B
done
But this doesn't work for months may, october, and desember
export LANG=nn_NO.utf8
for i in {01..12}
do
mnd=$(date -d "2020-$i-01" +%B)
date -d "01-${mnd:0:3}-2020" +%B
done
It is also worth noting the difference when your not taking a
substring of the month, works fine with english and more fails with
norwegian.
bug#44959: date error message should say -I
Hi Padraig, On 11/30/20 10:31 PM, Pádraig Brady wrote: > For my reference, if we were to give explicit diagnosis of the leading '='. > we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ... I'd also rather keep it like it is, but if we change something: we could advance past the '=' character in the option arg value ... at least in the case where only enumeration or numeric values are expected (which obviously aren't too many). Have a nice day, Berny
bug#44959: date error message should say -I
On 30/11/2020 17:22, Pádraig Brady wrote: On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote: Well OK, but when and when not to use the "=" is not revealed by the otherwise detailed error messages. So unless the user checks the manual, they will never "get it". If we were to recognize "-I seconds", it should just be for diagnostic help. I.e. we should minimize the combinations of valid inputs, for compatibility, consistency, and simplicity. I'll have a look at improving diagnostics in this area. This is one of the reasons we avoid args to short options, and new short options in general. Optional args to short options are rare in coreutils: $ grep -- '-[[:alpha:]]\[[A-Z]' man/*.1 | sed 's/,.*//' man/date.1:\fB\-I[FMT]\fR man/od.1:\fB\-w[BYTES]\fR man/pr.1:\fB\-e[CHAR[WIDTH]]\fR man/pr.1:\fB\-i[CHAR[WIDTH]]\fR man/pr.1:\fB\-n[SEP[DIGITS]]\fR man/pr.1:\fB\-s[CHAR]\fR man/pr.1:\fB\-s[CHAR]\fR turns off line truncation of all 3 column man/pr.1:\fB\-S[STRING]\fR Non option args to short options as less rare: $ grep 'B\\-[^\].*=' man/*.1 For my reference, if we were to give explicit diagnosis of the leading '='. we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ... cheers, Pádraig
bug#44960: date --expose-flags
On 30/11/2020 13:21, 積丹尼 Dan Jacobson wrote:
I got this brilliant idea.
Let's say one likes the output of
$ date --iso-8601=seconds
2020-11-30T21:15:47+08:00
but wants to know "how you did it?"
Hmmm, no assistance from
$ date --iso-8601=seconds --debug
2020-11-30T21:15:50+08:00
Ah, if only there were a:
$ date --iso-8601=seconds --expose-flags
date +%Y-%m-%dT%H:%M:%S%z
Then one needn't use trial and error to figure out the template being
used behind the scenes!
A useful idea.
I'll add that with the following.
thanks,
Pádraig
commit 17af226bd80db3376e9137384c1ba14a8d94c434 (HEAD -> master)
Author: Pádraig Brady
Date: Mon Nov 30 19:06:59 2020 +0000
date: with --debug, output the format used
* src/date.c (main): The format can be determined from
--options or the locale, so it's useful to output
the format string being used.
Addresses https://bugs.gnu.org/44960
diff --git a/src/date.c b/src/date.c
index c33fa3fc5..20af782df 100644
--- a/src/date.c
+++ b/src/date.c
@@ -505,6 +505,9 @@ main (int argc, char **argv)
}
}
+ if (parse_datetime_flags & PARSE_DATETIME_DEBUG)
+error (0, 0, _("using date format %s"), quote (format));
+
char const *tzstring = getenv ("TZ");
timezone_t tz = tzalloc (tzstring);
bug#44959: date error message should say -I
On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote: Well OK, but when and when not to use the "=" is not revealed by the otherwise detailed error messages. So unless the user checks the manual, they will never "get it". If we were to recognize "-I seconds", it should just be for diagnostic help. I.e. we should minimize the combinations of valid inputs, for compatibility, consistency, and simplicity. I'll have a look at improving diagnostics in this area. cheers, Pádraig
bug#44959: date error message should say -I
Well OK, but when and when not to use the "=" is not revealed by the otherwise detailed error messages. So unless the user checks the manual, they will never "get it".
bug#44959: date error message should say -I
On 30/11/2020 01:40 pm, Bernhard Voelker wrote: On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote: $ date -I=seconds date: invalid argument ‘=seconds’ for ‘--iso-8601’ Hmm, first of all, 'date' 8.32 outputs more than the above: $ date -I=seconds date: invalid argument '=seconds' for '--iso-8601' Valid arguments are: - 'hours' - 'minutes' - 'date' - 'seconds' - 'ns' Try 'date --help' for more information. Hey, that is a valid argument for --iso-8601. (But not for -I, so say that instead.) ... date (GNU coreutils) 8.32 From the above error message and from the --help output, one can see that the -I option does not require the argument to be appended with "=FMT" but just "FMT": $ date --help | grep -- -I -I[FMT], --iso-8601[=FMT] output date/time in ISO 8601 format. So, I'd say 'date' works as expected: $ date -Iseconds 2020-11-30T14:38:35+01:00 Have a nice day, Berny Is -I the only option that doesn't accept a space separator between it and its argument? Is that because it doesn't require an argument? Could/Should the argument after -I be parsed and used if it is one of date hours minutes seconds ns? (Could it also parse for mins secs?) But used as a separate option if not parsed as an argument? Is this too difficult? Cheers -- Chris Elvidge
bug#44959: date error message should say -I
On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:
> $ date -I=seconds
> date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hmm, first of all, 'date' 8.32 outputs more than the above:
$ date -I=seconds
date: invalid argument '=seconds' for '--iso-8601'
Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
Try 'date --help' for more information.
> Hey, that is a valid argument for --iso-8601. (But not for -I, so say
> that instead.)
...
> date (GNU coreutils) 8.32
>From the above error message and from the --help output, one can see that
the -I option does not require the argument to be appended with "=FMT" but
just "FMT":
$ date --help | grep -- -I
-I[FMT], --iso-8601[=FMT] output date/time in ISO 8601 format.
So, I'd say 'date' works as expected:
$ date -Iseconds
2020-11-30T14:38:35+01:00
Have a nice day,
Berny
bug#44960: date --expose-flags
date +%Y-%m-%dT%H:%M:%S%z ^I meant %:z > Then one needn't use trial and error (Driving my point home.)
bug#44960: date --expose-flags
I got this brilliant idea. Let's say one likes the output of $ date --iso-8601=seconds 2020-11-30T21:15:47+08:00 but wants to know "how you did it?" Hmmm, no assistance from $ date --iso-8601=seconds --debug 2020-11-30T21:15:50+08:00 Ah, if only there were a: $ date --iso-8601=seconds --expose-flags date +%Y-%m-%dT%H:%M:%S%z Then one needn't use trial and error to figure out the template being used behind the scenes! date (GNU coreutils) 8.32
bug#44959: date error message should say -I
$ date -I=seconds date: invalid argument ‘=seconds’ for ‘--iso-8601’ Hey, that is a valid argument for --iso-8601. (But not for -I, so say that instead.) Here is a real invalid argument: $ date --iso-8601=secondsz date: invalid argument ‘secondsz’ for ‘--iso-8601’ date (GNU coreutils) 8.32
bug#44865: date recalculation error
Ruder Laplace wrote: > Greetings, > > I think I catched a bug related to the day-light saving gap: > *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"* > Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 > GNU/Linux > mié nov 25 10:30:29 CET 2020 > lun jun 1 *12*:00:00 CEST 2020 > > As far as I think it should work, the expected result should be: lun jun 1 > *11*:00:00 CEST 2020 > "One hour after 10" is 11, not 12. You can check how date interprets your string using --debug: $ date -d "2020/06/01 11:00:00 +1 hour" --debug date: warning: value 2020 has 4 digits. Assuming /MM/DD date: parsed date part: (Y-M-D) 2020-06-01 date: parsed time part: 11:00:00 UTC+01 date: parsed relative part: +1 hour(s) date: input timezone: parsed date/time string (+01) date: using specified time as starting value: '11:00:00' date: starting date/time: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01' date: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01' = 1591005600 epoch-seconds date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns), date: new time = 1591009200 epoch-seconds date: timezone: system default date: final: 1591009200.00000 (epoch-seconds) date: final: (Y-M-D) 2020-06-01 11:00:00 (UTC) date: final: (Y-M-D) 2020-06-01 13:00:00 (UTC+02) Mo 1. Jun 13:00:00 CEST 2020 As you can see, it assumes that the "+1" indicates the timezone, which is 1 hour behind your local zone, thus 11:00 there would actually be 12:00 in your time zone. The "hour" alone is then used as a +1 hour adjustment, resulting in 13:00 CEST. Commands that work as you expected: $ date -d "2020/06/01 11:00:00 1 hour" --debug $ date -d "2020/06/01 11:00:00 +1 +1 hour" --debug $ date -d "2020/06/01 11:00:00 CEST +1 hour" --debug $ date -d "+1 hour 2020/06/01 11:00:00" --debug rainer
bug#44865: date recalculation error
Greetings, I think I catched a bug related to the day-light saving gap: *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"* Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux mié nov 25 10:30:29 CET 2020 lun jun 1 *12*:00:00 CEST 2020 As far as I think it should work, the expected result should be: lun jun 1 *11*:00:00 CEST 2020 "One hour after 10" is 11, not 12. I'm not sure if it has something to do to be right now in UTC+1 and the other time un UTC+2, but I don't remember having any trouble while in DL saving while on UTC+2. To me, the intuitive way is the one the program worries about whether DL saving was/will be ON on the specified time. *date --version* date (GNU coreutils) 8.30 Copyright (C) 2018 Free Software Foundation, Inc. *lsb_release -a* No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster Thanks for your time, Ruder Laplace.
bug#43828: invalid date converting from UTC, near DST
Martin Fido wrote: > I have tzdata version 2020a: > > $ apt-cache policy tzdata > tzdata: > Installed: 2020a-0ubuntu0.16.04 > Candidate: 2020a-0ubuntu0.16.04 > ... > > $ zdump -v Australia/Sydney | grep 2020 > Australia/Sydney Sat Apr 4 15:59:59 2020 UT = Sun Apr 5 02:59:59 2020 > AEDT isdst=1 gmtoff=39600 > Australia/Sydney Sat Apr 4 16:00:00 2020 UT = Sun Apr 5 02:00:00 2020 > AEST isdst=0 gmtoff=36000 > Australia/Sydney Sat Oct 3 15:59:59 2020 UT = Sun Oct 4 01:59:59 2020 > AEST isdst=0 gmtoff=36000 > Australia/Sydney Sat Oct 3 16:00:00 2020 UT = Sun Oct 4 03:00:00 2020 > AEDT isdst=1 gmtoff=39600 I see this is Ubuntu 16.04. I found a 16.04 system and I was able to recreate this exact problem there. However trying this on an 18.04 system and it is no longer an invalid date. Bob
bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06
On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote: > for some reason I get an error with one specific date but not with others: > > $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date > -d"$d" ); done; done > 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04 > 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04 > 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04 > 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04 > date: invalid date ‘2020-09-06’ > 2020-09-06 > 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03 The clue is the change in timezone offset from -04 to -03. The only location I could find which switched on 2020-09-06 was Chile, so we can reproduce the problem with: $ TZ=Chile/Continental date --debug -d 2020-09-06 date: parsed date part: (Y-M-D) 2020-09-06 date: input timezone: TZ="Chile/Continental" environment value date: warning: using midnight as starting time: 00:00:00 date: error: invalid date/time value: date: user provided time: '(Y-M-D) 2020-09-06 00:00:00' date:normalized time: '(Y-M-D) 2020-09-06 01:00:00' date: -- date: possible reasons: date:non-existing due to daylight-saving time; date:numeric values overflow; date:missing timezone date: invalid date ‘2020-09-06’ Notice that, in Chile's DST rules, the time jumps from 23:59:59 to 01:00:00: $ zdump -v Chile/Continental | grep 2020 Chile/Continental Sun Apr 5 02:59:59 2020 UT = Sat Apr 4 23:59:59 2020 -03 isdst=1 gmtoff=-10800 Chile/Continental Sun Apr 5 03:00:00 2020 UT = Sat Apr 4 23:00:00 2020 -04 isdst=0 gmtoff=-14400 Chile/Continental Sun Sep 6 03:59:59 2020 UT = Sat Sep 5 23:59:59 2020 -04 isdst=0 gmtoff=-14400 Chile/Continental Sun Sep 6 04:00:00 2020 UT = Sun Sep 6 01:00:00 2020 -03 isdst=1 gmtoff=-10800 Therefore there is no valid time "00:00:00", and this is the "non-existing due to daylight-saving time" case which date --debug reports. This is an FAQ, which often crops up twice per year: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Cheers, Phil
bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06
Hi, for some reason I get an error with one specific date but not with others: $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date -d"$d" ); done; done 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04 date: invalid date ‘2020-09-06’ 2020-09-06 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03 2020-10-05 Mon 05 Oct 2020 12:00:00 AM -03 2020-10-06 Tue 06 Oct 2020 12:00:00 AM -03 2020-10-07 Wed 07 Oct 2020 12:00:00 AM -03 Regards, Leo Wandersleb
bug#43828: invalid date converting from UTC, near DST
I have tzdata version 2020a: $ apt-cache policy tzdata tzdata: Installed: 2020a-0ubuntu0.16.04 Candidate: 2020a-0ubuntu0.16.04 ... $ zdump -v Australia/Sydney | grep 2020 Australia/Sydney Sat Apr 4 15:59:59 2020 UT = Sun Apr 5 02:59:59 2020 AEDT isdst=1 gmtoff=39600 Australia/Sydney Sat Apr 4 16:00:00 2020 UT = Sun Apr 5 02:00:00 2020 AEST isdst=0 gmtoff=36000 Australia/Sydney Sat Oct 3 15:59:59 2020 UT = Sun Oct 4 01:59:59 2020 AEST isdst=0 gmtoff=36000 Australia/Sydney Sat Oct 3 16:00:00 2020 UT = Sun Oct 4 03:00:00 2020 AEDT isdst=1 gmtoff=39600
bug#43828: invalid date converting from UTC, near DST
Martin Fido wrote: > I seem to have found a bug in the date utility, converting from UTC > to Sydney time. It returns invalid date for what should be perfectly > valid: > > $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z' > date: invalid date ‘2020-10-04T02:00:00Z’ > > $ TZ='Australia/Sydney' date -d '2020-10-04T02:59:59Z' > date: invalid date ‘2020-10-04T02:59:59Z’ This is more likely to be in the tzdata zoneinfo database rather than in date itself. Could you please report what version of tzdata you have on your system? Current on my system is tzdata version 2020b-1. And also this information too. $ zdump -v Australia/Sydney | grep 2020 Australia/Sydney Sat Apr 4 15:59:59 2020 UT = Sun Apr 5 02:59:59 2020 AEDT isdst=1 gmtoff=39600 Australia/Sydney Sat Apr 4 16:00:00 2020 UT = Sun Apr 5 02:00:00 2020 AEST isdst=0 gmtoff=36000 Australia/Sydney Sat Oct 3 15:59:59 2020 UT = Sun Oct 4 01:59:59 2020 AEST isdst=0 gmtoff=36000 Australia/Sydney Sat Oct 3 16:00:00 2020 UT = Sun Oct 4 03:00:00 2020 AEDT isdst=1 gmtoff=39600 > Note DST in Sydney changed 10 hours earlier: > > $ TZ='Australia/Sydney' date -d '2020-10-03T15:59:59Z' > Sunday 4 October 01:59:59 AEST 2020 > > $ TZ='Australia/Sydney' date -d '2020-10-03T16:00:00Z' > Sunday 4 October 03:00:00 AEDT 2020 Yes. And I think that is suspicious. Hopefully the zdump information will show that database is in need of an update and that is the root of the problem. I suspect that DST was moved at some point in time. > I have version 8.25: > > $ date --version > date (GNU coreutils) 8.25 I tried this on 8.13, 8.23, 8.26, and 8.32 and was unable to reproduce the problem on any of those versions of date. But I suspect the root cause is in the tzdata zoneinfo database. Bob
bug#43828: invalid date converting from UTC, near DST
On 10/6/20 4:24 AM, Martin Fido wrote: I have version 8.25: Seems to have been fixed by coreutils 8.30: $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z' Sun 04 Oct 2020 01:00:00 PM AEDT
bug#43828: invalid date converting from UTC, near DST
Hi, I seem to have found a bug in the date utility, converting from UTC to Sydney time. It returns invalid date for what should be perfectly valid: $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z' date: invalid date ‘2020-10-04T02:00:00Z’ $ TZ='Australia/Sydney' date -d '2020-10-04T02:59:59Z' date: invalid date ‘2020-10-04T02:59:59Z’ Note DST in Sydney changed 10 hours earlier: $ TZ='Australia/Sydney' date -d '2020-10-03T15:59:59Z' Sunday 4 October 01:59:59 AEST 2020 $ TZ='Australia/Sydney' date -d '2020-10-03T16:00:00Z' Sunday 4 October 03:00:00 AEDT 2020 I have version 8.25: $ date --version date (GNU coreutils) 8.25 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. Thanks, Martin.
bug#42470: Help text update suggestion for "date" util
Yes, I meant Pull Request when I said PR. Thank you for the information and for incorporating the suggested update! On Mon, Jul 27, 2020 at 4:18 PM Bernhard Voelker wrote: > [sorry, this one hung in my outbox ... not sure if this helps though] > > On 2020-07-25 17:07, Wes Novack wrote: > > For future reference, what is the PR process? > > Not exactly sure what you mean with "PR". > If you refer to the process of reporting bugs, making suggestions, sending > patches, etc., then please refer to the corresponding sections at: > https://www.gnu.org/software/coreutils/ > > If PR is meant as "(git) pull request": just plain patches are sent > to the mailing list(s). Please see: > https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking > > Have a nice day, > Berny >
bug#42470: Help text update suggestion for "date" util
[sorry, this one hung in my outbox ... not sure if this helps though] On 2020-07-25 17:07, Wes Novack wrote: > For future reference, what is the PR process? Not exactly sure what you mean with "PR". If you refer to the process of reporting bugs, making suggestions, sending patches, etc., then please refer to the corresponding sections at: https://www.gnu.org/software/coreutils/ If PR is meant as "(git) pull request": just plain patches are sent to the mailing list(s). Please see: https://git.savannah.gnu.org/cgit/coreutils.git/tree/README-hacking Have a nice day, Berny
