P2945 R1 Additional format specifiers for time_point

[wg21bot]

P2945R0 Additional format specifiers for time_point (Barry Revzin)

[ben-craig]

P2945R0: Additional format specifiers for time_point

P2945R0: Additional format specifiers for time_point

2023-08-22 Library Evolution Telecon Minutes

Champion: Barry Revzin

Chair: Ben Craig

Minute Taker: Inbal Levi

Does this paper have:

• Examples? YES
• Field experience?
  • Implementation experience? SOME, Implemented in some way, but not in this format
  • Usage experience? YES, In other languages
  • Deployment experience?
• Performance considerations? N/A
• Discussion of prior art? YES
• Changes Library Evolution previously requested? First review
• Wording? YES
• Breaking changes? YES
• Feature test macro? NO
• Freestanding?
• Format and/or iostream support? YES
• Hash support? N/A
• Allocator support? N/A

Summary

Request to keep %OS around
Needs a feature test macro

POLL: Change format's std::chrono::time_point and other chrono %S time specifiers to only show a whole number of seconds

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	4	1	1	1

Attendance: 13

# of Authors: 1

Author Position: SF

Outcome: Weak Consensus

WA+SA: I don't see there being sufficient motivation for a breaking change

POLL: Recommend implementations apply the %S change to older standards modes

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	4	1	0	1

Attendance: 13

# of Authors: 1

Author Position: SF

Outcome: Consensus

Next Steps

Return with an updated paper

[AraHaan]

I would like to suggest a few changes:

• I would like for a feature test macro for this to be added, this is so people using different versions of the C++ language itself (and the standard library that selectively enables things or disables things based on the C++ language version passed into the compiler itself) not having this would mean that consumer code cannot use it as a way to know if their compiler added support for it as well or if it has been shipped yet for them (example being how MSVC, GCC, and LLVM works at different times and has different stages of compatibility). As such as a author that writes open source code as well as personal programs in C++ and other programming languages they quickly comes need for testing which feature is supported and selectively use them where possible to achieve better more performant code. I do appreciate the effort here but I feel like something like this for ANY form of breaking change is best no matter if it's just for: source, binary, or even runtime breaking. That is sadly how I feel though as people tend to format time_point's differently and based on their compiler if they tried using these when they are not implemented can result in UB (Undefined Behavior). As such doing the feature test macro would help prevent that sort of issue as well and return the program back to being well defined.
• Why? I would like to ask why is this change needed as well? Can't the user be tasked with formatting the time_point's however they please themselves? Is this a way to make it easier for them and act like a shortcut for others to use that makes it harder to write it in a way that is not well defined? There needs some clarity in this and the reasons why.

[frederick-vs-ja]

That is sadly how I feel though as people tend to format time_point's differently and based on their compiler if they tried using these when they are not implemented can result in UB (Undefined Behavior).

I don't see why this can happen for P2945. There'll be only compilation failures or exceptions to be thrown.

After all, I think you should directly consult the author or open an issue in his repo instead of adding comments here.