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
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"
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
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
20
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
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
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-
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-8
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?
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
.
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
=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
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
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-existin
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
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
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&q
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
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
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
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
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
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
$ 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 p
> > 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
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
> >
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
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
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
d
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:
Sorry, my oversite,
It was the transition from Greenwich Mean Time to British Summer time
27th March.
Martin Hughes
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:0
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 mut
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, --refe
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
oes 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_fm
%r has a space at the end that makes me insanely angry fix it
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
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
%-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
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 t
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 int
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
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.
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:
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 wee
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
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
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
ever 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
roulx
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.
&
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 tha
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
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 util
$ 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
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
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 dat
(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 t
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 standa
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
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
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
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
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 betwee
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;
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.co
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
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 &quo
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
Co
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, ‘2
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
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
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
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 (us
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 downloa
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.h
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
>
> "
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
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
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
d 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
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
A
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.
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".
On 30/11/2020 01:40 pm, Bernhard Voelker wrote:
On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:
$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hmm, first of all, 'date' 8.32 outputs more than the above:
$ date -I=seconds
date: invalid argument '=seconds' for '--iso
On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:
> $ date -I=seconds
> date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hmm, first of all, 'date' 8.32 outputs more than the above:
$ date -I=seconds
date: invalid argument '=seconds' for '--iso-8601'
Valid arguments are:
-
date +%Y-%m-%dT%H:%M:%S%z
^I meant %:z
> Then one needn't use trial and error
(Driving my point home.)
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=second
$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)
Here is a real invalid argument:
$ date --iso-8601=secondsz
date: invalid argument ‘secondsz’ for ‘--iso-8601’
date (GNU coreutils) 8.32
Ruder Laplace wrote:
> Greetings,
>
> I think I catched a bug related to the day-light saving gap:
> *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
> Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
> GNU/Linux
> mié nov 25 10:
Greetings,
I think I catched a bug related to the day-light saving gap:
*uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
GNU/Linux
mié nov 25 10:30:29 CET 2020
lun jun 1 *12*:00:00 CEST 2020
As far
toff=36000
> Australia/Sydney Sat Oct 3 16:00:00 2020 UT = Sun Oct 4 03:00:00 2020
> AEDT isdst=1 gmtoff=39600
I see this is Ubuntu 16.04. I found a 16.04 system and I was able to
recreate this exact problem there. However trying this on an 18.04
system and it is no longer an invalid date.
Bob
On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote:
> for some reason I get an error with one specific date but not with others:
>
> $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
> -d"$d" ); done; done
> 2020-08-05 Wed 05 Aug 2020
Hi,
for some reason I get an error with one specific date but not with others:
$ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
-d"$d" ); done; done
2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
2020-08-07 F
I have tzdata version 2020a:
$ apt-cache policy tzdata
tzdata:
Installed: 2020a-0ubuntu0.16.04
Candidate: 2020a-0ubuntu0.16.04
...
$ zdump -v Australia/Sydney | grep 2020
Australia/Sydney Sat Apr 4 15:59:59 2020 UT = Sun Apr 5 02:59:59 2020
AEDT isdst=1
Martin Fido wrote:
> I seem to have found a bug in the date utility, converting from UTC
> to Sydney time. It returns invalid date for what should be perfectly
> valid:
>
> $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z'
> date: invalid date ‘2020-10-04T02:00:
On 10/6/20 4:24 AM, Martin Fido wrote:
I have version 8.25:
Seems to have been fixed by coreutils 8.30:
$ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z'
Sun 04 Oct 2020 01:00:00 PM AEDT
Hi,
I seem to have found a bug in the date utility, converting from UTC to Sydney
time. It returns invalid date for what should be perfectly valid:
$ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z'
date: invalid date ‘2020-10-04T02:00:00Z’
$ TZ='Australia/Sydney' date -d '2020
Yes, I meant Pull Request when I said PR. Thank you for the information and
for incorporating the suggested update!
On Mon, Jul 27, 2020 at 4:18 PM Bernhard Voelker
wrote:
> [sorry, this one hung in my outbox ... not sure if this helps though]
>
> On 2020-07-25 17:07, Wes Novack wrote:
> > For
[sorry, this one hung in my outbox ... not sure if this helps though]
On 2020-07-25 17:07, Wes Novack wrote:
> For future reference, what is the PR process?
Not exactly sure what you mean with "PR".
If you refer to the process of reporting bugs, making suggestions, sending
patches, etc., then
1 - 100 of 1059 matches
Mail list logo
