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 yyyy-mm-dd, but
UK/EU users are just as committed to thinking in little-endian
"dd/mm/yyyy" as American users are to thinking in middle-endian
"mm/dd/yyyy")
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
