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
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
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.
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
yo
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
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, 2
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 loca
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
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
.
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 n
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
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
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
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'
wi
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
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 tha
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
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/coreutil
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'
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 "202
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/Ri
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/core
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 fr
?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
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-existing
/u
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 per
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
es 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
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 las
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 `
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 -
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 f
$ 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
> > 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
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 not
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 f
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: usi
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
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_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 leadi
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 u
%-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 there was
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
ep 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
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.
re?
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&quo
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
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'
20
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 h
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
rom: 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 implem
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 th
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 utilit
$ 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)
(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
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
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-
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:
printin
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='&
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>
w
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: in
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.
$ da
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.
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
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
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'
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
Thi
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 "20
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 pa
s,
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:
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:
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".
1 - 100 of 1206 matches
Mail list logo