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
