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 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.
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.
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#61528: date doesn't parse negative years
Hello, I noticed that date doesn't accept negative years, such as in the date: -0001-01-02 (i.e. 2nd Jan 2 BC). It's also somewhat puzzling that even through date will convert a timestamp in that year to an output string, it won't parse that string as valid (i.e. the last 2 lines below). date +%Y-%m-%d -d '0001-01-02' -> 0001-01-02 date +%Y-%m-%d -d '-01-02' -> -01-02 date +%Y-%m-%d -d '-0001-01-02' -> date: invalid date ‘-0001-01-02’ date +%Y-%m-%d -d @-62135510325 -> 0001-01-02 date +%Y-%m-%d -d @-62167132725 -> -01-02 date +%Y-%m-%d -d @-62198668725 -> -001-01-02 date +%Y-%m-%d -d '-001-01-02' -> date: invalid date ‘-001-01-02’ My reading of ISO_8601 is that these are allowed in formats -MM-DD where is a 4-6 digit number which may be positive, zero or negative. https://en.wikipedia.org/wiki/ISO_8601 Note that we should treat year 0 is also 1 BC, while -1 AD is 2 BC. https://en.wikipedia.org/wiki/Year_zero Thanks very much. P.S. cal doesn't work with years 0 and below either.
[bug #22109] Enhancement request: tr should be able to take multiple consecutive actions
URL: http://savannah.gnu.org/bugs/?22109 Summary: Enhancement request: tr should be able to take multiple consecutive actions Project: GNU Core Utilities Submitted by: richardneill Submitted on: Friday 25/01/08 at 07:08 Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: It would be nice if tr could take multiple consecutive actions in a single command. For example, instead of writing echo hello | tr h i | tr -s l | tr -d o #result: iel it would be nice to allow: echo hello | tr h i -s l -d o where the operations are applied consecutively. Thanks, Richard ___ Reply to this item at: http://savannah.gnu.org/bugs/?22109 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #5971] RFE: a trashcan command
Follow-up Comment #3, bug #5971 (project coreutils): Agreed - it's no longer required now that coreutils bug 5477 has been fixed. That said, might I suggest appending something like the following to the man page of rm, so that the hint is more widely available: -- Unthinking use of rm is dangerous, (especially on systems where it isn't aliased to rm -i, or without current backups). A trashCaN command, cn, may be implemented as a bash alias: alias cn=mv --backup=numbered -- ~/your-trash-directory [In recent KDE/GNOME, the trash directory is located in ~/.local/share/Trash/files/] -- ___ Reply to this item at: http://savannah.gnu.org/bugs/?5971 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
