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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71986 in the body.
You can then email your comments to 71986 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Neill <rn214 <at> cam.ac.uk>
To: bug-coreutils <at> gnu.org
Subject: RFC: date @ to support ms.
Date: Sun, 7 Jul 2024 20:46:45 +0100

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

Message #8 received at 71986 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Richard Neill <rn214 <at> cam.ac.uk>, 71986 <at> debbugs.gnu.org
Subject: Re: bug#71986: RFC: date @ to support ms.
Date: Mon, 8 Jul 2024 12:33:51 +0100

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

Message #11 received at 71986 <at> debbugs.gnu.org (full text, mbox):

From: Richard Neill <rn214 <at> cam.ac.uk>
To: Pádraig Brady <P <at> draigBrady.com>,
 Richard Neill <rn214 <at> cam.ac.uk>, 71986 <at> debbugs.gnu.org
Subject: Re: bug#71986: RFC: date @ to support ms.
Date: Mon, 8 Jul 2024 16:56:51 +0100

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

Message #14 received at 71986 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Richard Neill <rn214 <at> cam.ac.uk>
Cc: 71986 <at> debbugs.gnu.org
Subject: Re: bug#71986: RFC: date @ to support ms.
Date: Mon, 08 Jul 2024 18:33:10 +0200

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 I suggest that it would be nice if date had an input format that would
> let me specify that the value is in ms?

$ date --date='@1720378861.258' --rfc-3339=ns
2024-07-07 21:01:01.258000000+02:00

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #17 received at 71986 <at> debbugs.gnu.org (full text, mbox):

From: Richard Neill <rn214 <at> cam.ac.uk>
To: Andreas Schwab <schwab <at> linux-m68k.org>, Richard Neill <rn214 <at> cam.ac.uk>
Cc: 71986 <at> debbugs.gnu.org
Subject: Re: bug#71986: RFC: date @ to support ms.
Date: Mon, 8 Jul 2024 20:18:13 +0100

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

Message #20 received at 71986 <at> debbugs.gnu.org (full text, mbox):

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

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.


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

Message #23 received at 71986 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #28 received at 71986-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Richard Neill <rn214 <at> cam.ac.uk>
Cc: 71986-done <at> debbugs.gnu.org
Subject: Re: bug#71986: RFC: date @ to support ms.
Date: Tue, 9 Jul 2024 14:39:15 +0200

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 "$IP_JSON|.ts")
DATE=$(date -d @$((TS / 1000)))


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

You're welcome; closing the bug report.

Previous Next

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