time_point%S flag as specified in the
+<chrono> library is existing code%S is a good design
+This paper is written to express strong opposition to changing the
+meaning of %S as proposed in P2945R0. To be perfectly clear, this paper expresses no
+objection to adding syntax to specify precision to %S.
+This would not break any code. The only objection is to changing the
+meaning of %S from representing seconds exactly, to
+representing only the integral part of seconds.
+
+The proper way to change a standard is to deprecate the old behavior, +and provide new syntax for the new behavior. Let both behaviors +coexist for a few cycles, then remove the deprecated specification. +
++Doing otherwise risks introducing run-time errors to existing code by +simply upgrading to a new version of C++. Such run-time errors have +the potential for raising safety and security issues. +
+ +%S flag as specified in the
+<chrono> library is existing code
++It has been shipping in MSVC for over a year now. +
++It has been implented in gcc 14.0.0. +
+
+%S has been documented by the standard, by books, by
+countless informal articles and postings, and by my date library.
+
+%S has 7 years of positive field experience with this
+syntax and behavior in my date library.
+
%S is a good design
+
+The design of %S follows the principles first laid down
+by the C++11 version of <chrono>.
+<chrono> does not implicitly throw away
+information. This is true in conversion of units, and it remains true
+in formatting. All information is preserved unless truncating
+behavior is explicitly requested. And when it is explicitly
+requested, there exists options on which way to truncate: towards
+zero, towards negative infinity, towards postive infinity, or to
+nearest.
+
+<chrono> was precision-neutral in C++11, and
+remains so a decade later in C++23. From N2661, written 2008-06-11:
+
++ ++This paper proposes a solution that is precision neutral. +
+
+No single precision is promoted above others or given special
+priviledges. It is not up to <chrono> to decide
+that one precision is better than another. That decision is up to the
+OS which talks directly to the hardware. And up to the client, who
+knows what precision is best for their application.
+<chrono> is just a middleman to make the syntax
+between the OS and the client portable.
+
+Clients often change the OS’s precision to their specification’s +precision at the point of input, such as wrapping a call to now: +
+ +
+auto
+GetCurrentTime()
+{
+ using namespace std::chrono;
+ return floor<milliseconds>(system_clock::now());
+}
+
+And then traffic in those time_points throughout their
+library or application. There may be many points of both formatting
+and parsing involved throughout their application. And at each point
+they don’t have to worry about synchronizing their parse and format
+statements with their specification’s precision. They can just ask
+for the time: “%F %T” (etc.). And when their
+specification changes, there is no pain point. Formatting and parsing
+by default automatically adjust.
+
+<chrono> does not (and should not) carry all of
+this respect for the client around and then when the client gets ready
+to create a logging statement suddenly say: Oh, you probably want the
+precision a bunch of committee members decided upon. No,
+<chrono> should give the client the preicsion he
+has already asked for (as the default, of course there should be a way
+to change it).
+
+Clients also value symmetry between the parsing and formatting strings
+so that they only have to learn one micro-language and not two.
+During parsing %S takes its precision from the type being
+parsed, and reads up to that amount of precision from the input
+stream. A piece-wise redesign of <chrono> without
+an in-depth knowledge of the entire library is foolhardy at best. And
+in this case also disruptive and dangerous.
+
+%S does not need to have identical functionality to other
+languages. There are many ways in which <chrono>
+differs from other date time libraries. These differences are what
+makes the <chrono> solution superior, in
+safety, functionality and performance.
+