This will output the current time as the number of seconds since the epoch $ date +%s 1748280942 However, there is no option for milliseconds. GNU date on Linux supports milliseconds. $ pkg install coreutils $ gdate +%s.%3N 1748280955.153 It would be great if FreeBSD supports milliseconds as well.
Here is an example of time logging for `make buildworld' with seconds https://people.freebsd.org/~wosch/build-time/buildworld/buildworld.csv and here with milliseconds https://people.freebsd.org/~wosch/build-time/buildworld/buildworld-gdate.csv
So I was looking into this because it looks like an interesting first issue. Looking at the source code for date.c we have this: * The strftime_ns function is a wrapper around strftime(3), which adds support * for features absent from strftime(3). Currently, the only extra feature is * support for %N, the nanosecond conversion specification. So it seems that this behavior is expected, although I suppose you could always multiple nanoseconds by 10e3. The question then becomes what part of strftime to cover. I will take a deeper dive into the issue and try my hand at doing a patch.
OK so I just checked the man page for date in Linux (https://man7.org/linux/man-pages/man1/date.1.html) %N displays nanoseconds not milliseconds. So for both gdate and date in your examples you are requesting nanoseconds. It looks to me like the 3 in the command line is what is throwing the wrench in things. Under FreeBSD’s implementation, that will put 3 before the number of nanoseconds implying 3*10^6 nanoseconds. The issue is the for loop. I’d suggest the bug fix would be rewriting this to be more efficient. I’d have to look to see what that looks like. It seems gdate is reading the 3 as “first three digits” but I can’t find that as a documented feature in the man page, and FAIK is actually a bug in gdate…
Also I wonder if this is perhaps a bug for (tok = newformat; *tok != '\0'; tok++) If I’m reading this correctly, if newformat is not a null terminated string, this would create an infinite loop or some other memory violation…
(In reply to Dan Anderson from comment #3) Thanks for your analysis. For now I can live with nanoseconds instead milliseconds, and do the conversion ns->ms in a post step. -------------------------------------------------- commit eeb04a736cb9c07d191af886e25d5f198824658e Author: Mateusz Piotrowski <0mp@FreeBSD.org> AuthorDate: Sun Apr 21 23:25:32 2024 +0200 The format of %N is meant to be compatible with that of GNU date. -------------------------------------------------- so the open issue is that the FreeBSD date don't support %3N as GNU date. gdate '+%s.%3N' 1762786801.300 date '+%s.%3N' 1762786810.3N
Potentially relevant change in GNU date: https://github.com/coreutils/coreutils/commit/0cd39a246af30d141be2676f1b4c1fd6616dfec5
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=38839c872e7af6a1424009bf07d6b4450e9ca61d commit 38839c872e7af6a1424009bf07d6b4450e9ca61d Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-11-11 14:58:23 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-11-11 14:58:35 +0000 date: Improve nanosecond support Add support for a field width, which defaults to 9 if unspecified or zero. If the width is not exactly 9, we have to either cut off digits or append zeroes to make up the difference. If the width is a dash, we pick a width based on the clock's reported resolution. This brings us in line with GNU coreutils. PR: 287080 MFC after: 1 week Reviewed by: 0mp Differential Revision: https://reviews.freebsd.org/D53667 bin/date/date.1 | 50 ++++++++++-- bin/date/date.c | 148 ++++++++++++++++++++++++----------- bin/date/tests/format_string_test.sh | 2 + 3 files changed, 147 insertions(+), 53 deletions(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=758d7ce63a617a5bb1d18b5259216a753587e057 commit 758d7ce63a617a5bb1d18b5259216a753587e057 Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-11-11 14:58:23 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-11-19 10:56:50 +0000 date: Improve nanosecond support Add support for a field width, which defaults to 9 if unspecified or zero. If the width is not exactly 9, we have to either cut off digits or append zeroes to make up the difference. If the width is a dash, we pick a width based on the clock's reported resolution. This brings us in line with GNU coreutils. PR: 287080 MFC after: 1 week Reviewed by: 0mp Differential Revision: https://reviews.freebsd.org/D53667 (cherry picked from commit 38839c872e7af6a1424009bf07d6b4450e9ca61d) bin/date/date.1 | 50 ++++++++++-- bin/date/date.c | 148 ++++++++++++++++++++++++----------- bin/date/tests/format_string_test.sh | 2 + 3 files changed, 147 insertions(+), 53 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b0abbe05dfa144ff6ceabeb317e9493a13c0917d commit b0abbe05dfa144ff6ceabeb317e9493a13c0917d Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-11-11 14:58:23 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-11-19 10:57:39 +0000 date: Improve nanosecond support Add support for a field width, which defaults to 9 if unspecified or zero. If the width is not exactly 9, we have to either cut off digits or append zeroes to make up the difference. If the width is a dash, we pick a width based on the clock's reported resolution. This brings us in line with GNU coreutils. PR: 287080 MFC after: 1 week Reviewed by: 0mp Differential Revision: https://reviews.freebsd.org/D53667 (cherry picked from commit 38839c872e7af6a1424009bf07d6b4450e9ca61d) bin/date/date.1 | 50 ++++++++++-- bin/date/date.c | 148 ++++++++++++++++++++++++----------- bin/date/tests/format_string_test.sh | 2 + 3 files changed, 147 insertions(+), 53 deletions(-)