Subject: Re: bug#71986: RFC: date @ to support ms.

From: Richard Neill <[email-masked]>
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=[email-masked]'
>>
>> 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