> Is it actually truncated elsewhere, or is the resolution just in seconds anyway?

 

Of my five examples, only the XFCE clock did not have sub-second format codes. The others all featured milliseconds, microseconds, and/or nanoseconds.

Every example (other than C++'s std::chrono) I've seen where the time type is sub-second, the seconds formatter is still integer-truncated. I just looked at a few more, eg QT (https://doc.qt.io/qt-6/qml-qtqml-qt.html#formatDateTime-method), which continue this pattern.
GNOME clock (via GLib) even references strftime() but still has sub-second codes and truncated-integer seconds.

 

 

 

> Unheard of, I think.

Any type that: [internally stores seconds and subseconds in different member integers] and [whose "seconds" integer is of a different type than that returned from floor<seconds>(t)] would count. This includes <time.h>'s "tm" type. If you wanted to implement a format-capable 'clock' wrapper struct for "tm" you'd have an example. But still unlikely and not important.

 

 

 

> And not all time points and durations come from clocks anyway. Formatting of chrono types isn't just for formatting values that come straight from clocks.

 

Part of my issue related to file timestamps. Another part was creating directories to sort files based on arbitrary timestamp format, which could theoretically end up creating a directory for every used nanosecond if the clock's precision changed.

 

 

 

> > That's a good point. And "%t"s already used (why? isn't \t sufficient? (same for \n vs "%n"))

 

> Because strftime supports them.

 

I see. IMHO it's unfortunate how many C++ design decisions seem based on legacy issues.
Also, Isn't that just the same consistency argument I'm making? A: strftime uses %t=tab. B: most software on earth AFAICT uses truncated-integer seconds (mostly via %S).

 

 

 

> I don't read Howard's SO comment as particularly supportive of the idea, but maybe I'm wrong. Providing a link explaining how to submit a proposal is not necessarily support for the proposal :-)

 

I agree. I probably shouldn't have worded it like that.

 

 

 

> The work to implement it is not the issue here. It makes the chrono formatter code (slightly) larger and slower, for every call to std::format, even for users who don't need the new feature. I'm not sure it's worth it, when you can already do it using a cast. Your mileage may vary.

 

There's constexpr-cleverness going on in the format-string evaluation, so the generated binary code shouldn't (given a decent compiler and well written header code) be any larger or slower for users who don't use "%s", nor should the runtime libraries be affected. You can see this by the fact an invalid format string fails at compile time instead of runtime, that you can't pass a non-constexpr format string, and that the changes only need be made in a header with no runtime library rebuild.

 

I just compiled a test (via GCC, using "%S" but not "%s") on both my patched and non-patched chrono_io.h, and the output binaries are (according to diff -s) 100% identical.

 

It does, however, use up a valuble conversion specifier character. But I'd argue that that applies more to "%t" and "%n".
It also might slow down compilation by a few negligible nanoseconds.

 

 

 

> Lastly, is there any hope for a proposal to add the ^^ operator?

 

This would be a far more important proposal. I don't know if it's been proposed before (there's plenty of discussion about it, but I didn't find a proposal), but it would require a lot more work to implement, from preprocessors to parsers to optimizers. But the permanent effects are only positive AFAICImagine.

 

Should I write it?