GNU bug report logs - #71986
RFC: date @ to support ms.

Previous Next

Full log

View this message in rfc822 format

From: Richard Neill <rn214 <at> cam.ac.uk>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 71986 <at> debbugs.gnu.org
Subject: bug#71986: RFC: date @ to support ms.
Date: Tue, 9 Jul 2024 02:19:50 +0100

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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.