bug#72023: feature request for date(1): strptime-style format
I agree strptime()-style input format specification is badly missing in GNU date. Most other implementations support it: - BSD with -f since 1997 (on FreeBSD at least; see also -v for adjustments) - ast-open's with -p since 2004 (also via standard getdate() DATEMSK) - busybox' with -D since 2006 - toybox' with -D since 2014 It's a regular occurrence on usenet or unix.stackexchange.com to see it mentioned that if you need to parse arbitrary date formats, you need to switch to another date implementation or use shell builtin facilities such as zsh's strftime builtin or ksh93's printf %T or resort to perl/ruby/python... Assaf Gordon did propose a patch in https://lists.gnu.org/archive/html/coreutils/2019-07/msg00053.html Both -p and -D are unassigned ATM AFAICT so could be used here. busybox and toybox mostly copied the GNU API, so it would make sense for GNU date to use -D for that so they don't become misaligned. While strptime() is not perfect, it's still better IMO than having to rely on the current -d behaviour which mostly accepts only US-English time specs and whose rules to parse times are not crystal clear. -- Stephane
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
Fair enough... I was worried you were objecting to the whole concept, not just that one function -Original Message- From: Paul Eggert Sent: Wednesday, July 10, 2024 12:23 PM To: Yagnatinsky, Mark : IT (NYK) ; 72...@debbugs.gnu.org Subject: Re: bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess CAUTION: This email originated from outside our organisation - egg...@cs.ucla.edu Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. On 7/10/24 15:12, mark.yagnatin...@barclays.com wrote: > Re: strptime is mistake: you think that particular function is bad Yes, though I lack the time to go into details right now. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. __
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
On 7/10/24 15:12, mark.yagnatin...@barclays.com wrote: Re: strptime is mistake: you think that particular function is bad Yes, though I lack the time to go into details right now.
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
Re: strptime is mistake: you think that particular function is bad, or the whole idea of "here is a string describing the format, please parse accordingly" is a bad idea? -Original Message- From: Paul Eggert Sent: Wednesday, July 10, 2024 8:57 AM To: Yagnatinsky, Mark : IT (NYK) ; 72...@debbugs.gnu.org Subject: Re: bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess CAUTION: This email originated from outside our organisation - egg...@cs.ucla.edu Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. On 7/10/24 13:59, mark.yagnatinsky--- via GNU coreutils Bug Reports wrote: > BSD date has this flag Unfortunately it uses -f for the flag, and -f already has a well-established different meaning in GNU 'date'. We could add it to GNU date under a different (long) option name, though we'd still be incompatible with BSD 'date'. Again, if someone wants to write the code and (just as important) documentation, and also the tests, go for it. I tend to think strptime is a mistake, so I'm not likely to volunteer. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. __
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
On 7/10/24 13:59, mark.yagnatinsky--- via GNU coreutils Bug Reports wrote: BSD date has this flag Unfortunately it uses -f for the flag, and -f already has a well-established different meaning in GNU 'date'. We could add it to GNU date under a different (long) option name, though we'd still be incompatible with BSD 'date'. Again, if someone wants to write the code and (just as important) documentation, and also the tests, go for it. I tend to think strptime is a mistake, so I'm not likely to volunteer.
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
Re: other dates: BSD date has this flag, and needs it, because it mostly refuses to guess. Re: strptime... I didn't mean it has to literally be that function. I just want some way to say what format the input is in. -Original Message- From: Paul Eggert Sent: Wednesday, July 10, 2024 6:45 AM To: Yagnatinsky, Mark : IT (NYK) ; 72...@debbugs.gnu.org Subject: Re: bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess CAUTION: This email originated from outside our organisation - egg...@cs.ucla.edu Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. I'm dubious. I've never had much luck with strptime, as in practice it has its own glitches that are even worse than what 'date' currently uses. For example, it's dicey in non-C locales, and it mishandles time zones and daylight saving transitions even in the C locale. That being said, if someone can write the code and documentation and test cases it might be a good thing to have - particularly if some other 'date' implementation is already doing that sort of thing and people have had good experience with it. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. __
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
I'm dubious. I've never had much luck with strptime, as in practice it has its own glitches that are even worse than what 'date' currently uses. For example, it's dicey in non-C locales, and it mishandles time zones and daylight saving transitions even in the C locale. That being said, if someone can write the code and documentation and test cases it might be a good thing to have - particularly if some other 'date' implementation is already doing that sort of thing and people have had good experience with it.
bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess
I suspect this has been requested many times over the decades but I haven't found anything in the issue tracker so... The date command lets you choose my output format, but for input it tries to figure it out without hints. For interactive use, this is great. For usage in scripts, this is less than ideal, because that means you need to understand the heuristics to have confidence that your script will do what you want. For instance, this page: https://www.gnu.org/software/coreutils/manual/html_node/Pure-numbers-in-date-strings.html says that "If the decimal number is of the form mmdd [...] is read as the year" I stared at that sentence for a bit in confusion, thinking to myself "but how could it possibly KNOW that the number is of the form mmdd??" I finally realized that what it's really saying is that "if the number is exactly 8 digits long, we ASSUME that the first four digits are the year". Thus, if you have an 8-digit number that you want to interpret differently then you should massage it before passing it to date. As it happens, I have an 8 digit number, and indeed the built-in assumptions happen to be a perfect fit for me. But I still don't like to rely on them if I don't have to, and would rather just tell it what I already know, instead of forcing date(1) to re-derive it. Thoughts? Mark. This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. __
bug#71986: RFC: date @ to support ms.
On 7/9/24 03:19, Richard Neill wrote: IP_JSON=$(curl https://whatsmyip.dev/api/ip) TS=$(echo $IP_JSON | jq '.ts' -r) TS=$(echo "$TS/1000" | bc) DATE=$(date --date @$TS) This is better, as it saves on subprocesses: IP_JSON=$(curl https://whatsmyip.dev/api/ip) TS=$(jq -nr "$IP_JSON|.ts") DATE=$(date -d @$((TS / 1000))) Anyway, I don't want to waste everyone's time, so if I haven't convinced you, I'll leave it here, and say thank you very much for your consideration. You're welcome; closing the bug report.
bug#71986: RFC: date @ to support ms.
Thanks, Paul,
On 09/07/2024 01:52, Paul Eggert wrote:
On 7/8/24 21:18, Richard Neill wrote:
Also, this is an increasingly common format to see as an input
In shell apps? News to me. I thought it was more of a Java and/or
JavaScript thing. Those languages love ms. POSIX, though, prefers ns.
For occasional use one can just use the shell, with no new option
needed. For your example:
$ ms=1720378861258
$ date -d@${ms%???}
Sun Jul 7 21:01:01 CEST 2024
But really, it's better to use a decimal point, as Andreas suggested.
Simple, clear, unambiguous, and no new option needed regardless of
whether the timestamps have ms or μs or ns resolution.
Let me give you an example, where the timestamp that is given as input
to the shell script is in the ms format. I run this from cron, hourly,
because my ISP likes changing address on me:
IP_JSON=$(curl https://whatsmyip.dev/api/ip)
IP=$(echo $IP_JSON | jq '.addr' -r)
TS=$(echo $IP_JSON | jq '.ts' -r)
TS=$(echo "$TS/1000" | bc)
DATE=$(date --date @$TS)
echo -e "IP: $IP\nTimestamp: $DATE" | ssh ME@MYSERVER "cat >
public_html/tmp/ip.txt"
for date-input, this:
date --date '1/2/2024'
is ambiguous
It's ambiguous without context, yes, but the manual documents it so that
provides the context.
https://www.gnu.org/software/coreutils/manual/html_node/Calendar-date-items.html
In GNU projects man pages are typically just quick summaries: for the
details you need the manual.
Sorry, I didn't mean "it's ambiguous what GNU date will do with the
format" - as you say, that's clearly documented.
I meant if (as a human), you see a date written in the "1/2/2024"
format, then it is ambiguous (locale-dependent) as to how it should be
interpreted, and it would be nice to have a way to tell date which of
the competing standards it should use.
(Aside: I try very hard to encourage everyone to write -mm-dd, but
UK/EU users are just as committed to thinking in little-endian
"dd/mm/" as American users are to thinking in middle-endian
"mm/dd/")
Anyway, I don't want to waste everyone's time, so if I haven't convinced
you, I'll leave it here, and say thank you very much for your consideration.
Regards
Richard
bug#71986: RFC: date @ to support ms.
On 7/8/24 21:18, Richard Neill wrote:
Also, this is an increasingly common format to see as an input
In shell apps? News to me. I thought it was more of a Java and/or
JavaScript thing. Those languages love ms. POSIX, though, prefers ns.
For occasional use one can just use the shell, with no new option
needed. For your example:
$ ms=1720378861258
$ date -d@${ms%???}
Sun Jul 7 21:01:01 CEST 2024
But really, it's better to use a decimal point, as Andreas suggested.
Simple, clear, unambiguous, and no new option needed regardless of
whether the timestamps have ms or μs or ns resolution.
for date-input, this:
date --date '1/2/2024'
is ambiguous
It's ambiguous without context, yes, but the manual documents it so that
provides the context.
https://www.gnu.org/software/coreutils/manual/html_node/Calendar-date-items.html
In GNU projects man pages are typically just quick summaries: for the
details you need the manual.
bug#71986: RFC: date @ to support ms.
On 08/07/2024 17:33, Andreas Schwab wrote: date --date='@1720378861.258' --rfc-3339=ns Thanks. The problem is that the input string (from elsewhere) is "1720378861258" i.e. it's "integer ms", not "seconds with a decimal". Also, this is an increasingly common format to see as an input Slightly relatedly, for date-input, this: date --date '1/2/2024' is ambiguous (most of the world sees this as 1st Feb; USA sees it as 2nd Jan). => so there are a few cases where date could benefit from a rule for how the --date field should be parsed, and if there isn't a flag, at least a clarification in the man page would be helpful. Thanks very much, Best wishes, Richard
bug#71986: RFC: date @ to support ms.
On Jul 07 2024, Richard Neill wrote: > I've noticed a lot of systems now return the timestamp in milliseconds > since the epoch, rather than seconds. This means that e.g. > > date --date='@1720378861258' > > will do something rather unexpected! > > May I suggest that it would be nice if date had an input format that would > let me specify that the value is in ms? $ date --date='@1720378861.258' --rfc-3339=ns 2024-07-07 21:01:01.25800+02:00 -- 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#71986: RFC: date @ to support ms.
Hello Pádraig,
On 08/07/2024 12:33, Pádraig Brady wrote:
On 07/07/2024 20:46, Richard Neill wrote:
Hello,
I've noticed a lot of systems now return the timestamp in milliseconds
since the epoch, rather than seconds. This means that e.g.
date --date='@1720378861258'
will do something rather unexpected!
May I suggest that it would be nice if date had an input format that
would let me specify that the value is in ms?
I know we can bodge it with bc, or by injecting the decimal, or trimming
off the last 3 chars, but that seems inelegant, and requires extra
thinking (and hence bugs) from the programmer.
date --date='@1720378861.258'
Perhaps one of these syntaxes might be suitable?
date --date='@ms1720378861258'
date --date='@@1720378861258'
date --epoch-ms --date='@1720378861258'
Yes this has some merit, but given we can leverage numfmt
to convert / round, I'm not sure it's warranted. Consider for e.g.:
$ ms2date() { date --date=@$(numfmt --to-unit=1K --round=nearest
"$1"); } $ ms2date 1720378861999
Sun 07 Jul 2024 20:01:02 IST
cheers,
Pádraig
Thanks for your comment.
I know that we CAN do this the hard way, but
it's certainly not obvious, and that sort of function takes a few
minutes for everyone to figure out and puzzle over - and then longer to
test - and there's also a (minor) performance bug if we had lots of
these to deal with.
In my view, the point of the GNU coreutils (with all the extended
options) is that it should be a "batteries included" approach, where
there is an obvious way to do everything.
"date" does currently aim to support all the standard input/output
formats, and even the obscure ones like "a week on Tuesday". So a
timestamp-in-ms is surely one that should be included.
If not, may I suggest that at least the man page should be updated to
document your alternative.
Thanks,
Richard
bug#71986: RFC: date @ to support ms.
On 07/07/2024 20:46, Richard Neill wrote:
Hello,
I've noticed a lot of systems now return the timestamp in milliseconds
since the epoch, rather than seconds. This means that e.g.
date --date='@1720378861258'
will do something rather unexpected!
May I suggest that it would be nice if date had an input format that
would let me specify that the value is in ms?
I know we can bodge it with bc, or by injecting the decimal, or trimming
off the last 3 chars, but that seems inelegant, and requires extra
thinking (and hence bugs) from the programmer.
date --date='@1720378861.258'
Perhaps one of these syntaxes might be suitable?
date --date='@ms1720378861258'
date --date='@@1720378861258'
date --epoch-ms --date='@1720378861258'
Yes this has some merit, but given we can leverage numfmt
to convert / round, I'm not sure it's warranted. Consider for e.g.:
$ ms2date() { date --date=@$(numfmt --to-unit=1K --round=nearest "$1"); } $
ms2date 1720378861999
Sun 07 Jul 2024 20:01:02 IST
cheers,
Pádraig
bug#71986: RFC: date @ to support ms.
Hello, I've noticed a lot of systems now return the timestamp in milliseconds since the epoch, rather than seconds. This means that e.g. date --date='@1720378861258' will do something rather unexpected! May I suggest that it would be nice if date had an input format that would let me specify that the value is in ms? I know we can bodge it with bc, or by injecting the decimal, or trimming off the last 3 chars, but that seems inelegant, and requires extra thinking (and hence bugs) from the programmer. date --date='@1720378861.258' Perhaps one of these syntaxes might be suitable? date --date='@ms1720378861258' date --date='@@1720378861258' date --epoch-ms --date='@1720378861258' Thanks very much, Richard
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 (&input_line, &input_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 (&line, &buflen, 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 -> 0000-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 (&argc, &argv);
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 &#x
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 (&refstats);
}
- 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 ? &when : NULL;
if (set_datestr)
datestr = set_datestr;
- valid_date = parse_datetime2 (&when, datestr, NULL,
+ valid_date = parse_datetime2 (&when, 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, &tm)) + goto offse
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, &dayincr)
- || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
-dayincr, &dayincr)
- || INT_ADD_WRAPV (dayincr, tm.tm_mday, &tm.tm_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, &dayincr)
+ || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
+ dayincr, &dayincr)
+ || INT_ADD_WRAPV (dayincr, tm.tm_mday, &tm.tm_mday)))
{
tm.tm_isdst = -1;
Start = mktime_z (tz, &tm);
}
- if (Start == (time_t) -1)
+ if (tm.tm_yday < 0)
{
if (debugging (&pc))
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, &tm);
- if (Start == (time_t) -1)
+ if (tm.tm_wday < 0)
{
if (debugging (&pc))
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 (&result, p, &now));
+ 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
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 s
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.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?
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.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?
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.00000 (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 +0000 -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 +
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".
