|
From: | Richard Neill |
Subject: | bug#71986: RFC: date @ to support ms. |
Date: | Mon, 8 Jul 2024 16:56:51 +0100 |
User-agent: | Mozilla Thunderbird |
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 1720378861999Sun 07 Jul 2024 20:01:02 IST cheers, Pádraig
Thanks for your comment. I know that we CAN do this the hard way, butit'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
[Prev in Thread] | Current Thread | [Next in Thread] |