Page MenuHomeFreeBSD

strftime: Add support for %N (nanoseconds)
Changes PlannedPublic

Authored by 0mp on Nov 2 2021, 9:57 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 24 2024, 4:52 PM
Unknown Object (File)
Feb 6 2024, 6:15 AM
Unknown Object (File)
Jan 16 2024, 4:19 AM
Unknown Object (File)
Dec 20 2023, 6:44 AM
Unknown Object (File)
Nov 25 2023, 4:01 PM
Unknown Object (File)
Nov 18 2023, 2:01 PM
Unknown Object (File)
Nov 18 2023, 11:46 AM
Unknown Object (File)
Nov 18 2023, 11:25 AM
Subscribers

Details

Reviewers
None
Group Reviewers
manpages
Summary

This patch makes it possible to use the %N conversion specification
to output nanoseconds, similarly to some other date(1) implementations.

Test Plan
  • build the world with the patched libc
  • run date +%N

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 42516
Build 39404: arc lint + arc unit

Event Timeline

0mp requested review of this revision.Nov 2 2021, 9:57 AM
lib/libc/stdtime/strftime.c
298

I'm not sure if that's the right clock to use.

This is something quite weird. strftime(3) prints its argument (struct tm), in various formats. Your patch adds printing for the current time.

Which other implementations do that?

0mp planned changes to this revision.Nov 2 2021, 10:56 AM
In D32799#740090, @kib wrote:

This is something quite weird. strftime(3) prints its argument (struct tm), in various formats. Your patch adds printing for the current time.

Which other implementations do that?

Ha, good catch. There are no such implementations I guess. I'll take a look at the function once again.

I took another look at the problem and it looks like modifying strftime to support %N for nanoseconds is not easy. The reason is that the interface has only second precision (via struct tm). In theory, we could extend struct tm to include nanoseconds but it is not something other libc implementations are doing / document. Also, adding additional fields to struct tm (documented in ctime(3)) sounds like a bad idea to me as it seems quite intrusive.

My ultimate goal is to add support for nanoseconds to date(1). Perhaps there is another way to implement this feature.