Date: Fri, 07 Mar 2025 00:20:33 +0000
On Thursday, March 6th, 2025 at 15:16, Thiago Macieira <thiago_at_[hidden]> wrote:
>
>
> On Thursday, 6 March 2025 14:42:13 Pacific Standard Time Nikolaos D. Bougalis
> wrote:
>
> > People embed timestamps in their programs ALL THE TIME and there are many
> > legitimate reasons to do so (some compilers actually do it automatically
> > for you). They just do it using the preprocessor (via TIME and DATE
> > or TIMESTAMP) or using custom build steps or binary post-processing. I
> > don't think providing a tool to developers that allows them to use modern
> > C++ and the language of std::chrono to achieve those goals is a bad thing.
> >
> > Generally, I think that your criticisms, interpreted more broadly, is
> > severely limiting. I certainly agree that any tool can be misused, but I
> > don't think that, by itself, is a good enough reason to deny use of that
> > tool.
>
>
> I am calling DATE and TIME a misfeature. They should not have been
> added to the language. Therefore, I disagree that we should add a feature that
> "allows modern C++" for them.
I don't know that I agree about them being a "misfeature" and don't care to have that argument, but given your position, I can certainly understand why you'd feel as you do about this proposal. Still, I think it's important that we have conversations which challenge our preconceived notions, and I hope that this can be such a conversation on both sides.
> You're right that people can get timestamps in other ways and embed them into
> the programs. That's fine; but that also means that they can do what you're
> asking for in the same ways. Just use your buildsystem to create the UUIDs,
> for example.
Sure, they can. Just as people can run Microsoft's resource compiler tool to "compile" resources and produce a header file, or they can post-process a compiled binary to insert a timestamp or a version number or what-have-you. But that distracts from the question of whether having the ability to do this in C++ is a useful tool to offer to developers.
> In any case, if withdrawing the paper is not a path you want to pursue, I
> recommend you add to it:
>
> * implementations are encouraged to have a mechanism to configure what time
> point is returned by this function, so as to support reproducible and
> deterministic builds, such as SOURCE_DATE_EPOCH environment variable (link to
> https://reproducible-builds.org/ for more information)
If I were being pedantic, I'd argue that it's possible to just roll back the system clock, and in some ways easier. But I don't think it's a bad idea to encourage implementations to provide such a mechanism.
> * reliability, accuracy, and precision are not guaranteed. Many systems may
> not know their timezone or be synchronised with an atomic clock. Some
Nothing in my proposal should really be construed as mandating an accurate clock anymore than the standard can mandate `std::chrono::system_clock` to be accurate. All my proposal requires is to effectively return a time_point at compile time. I was doing some embedded development the other day and `std::chrono::system_clock` always starts on January 1, 2018 at 00:00:00 when you reset the device, because that's what the microcontroller is configured. I believe that's perfectly compliant with the standard already.
> compilers may choose to tell you that the current time is the source file's
> modification time, which may be stored in a filesystem that does not support
> sub-second time resolution.
I don't think that's a problem, per se, although I think that implementations should make a best effort to return the time as reported by the operating system, which is all the standard really requires for `std::chrono::system_clock` really.
> * software cannot depend on the date returned changing at all. A compliant
> compiler is allowed to return a fixed date, either intentionally or because the
> build environment is misconfigured (e.g., unable to obtain a time after boot -
> my coffee maker has been showing "12:00" for the past 3 days). Therefore,
> software cannot depend on this value to generate unique identifiers because
> they may not be unique at all.
I understand that you are trying to be helpful, and I am trying to read your suggestions with that in mind, but I can't help but feel that you're also trying to water the proposed functionality down to what amounts to homeopathic levels.
As I mentioned before, I don't think the standard can really mandate that a compliant implementation of `std::chrono::system_clock` return an accurate (as in "yep, it's that o-clock right now, plus or minus 97 microseconds!") time anyways, or even that the date changes at all. In fact, because this clock can be adjusted by the operating system at any moment and in effectively any way, such a "clock" would already be standard-compliant in my view. But I don't think we should encourage implementations to do such a thing.
Even if your coffee maker is misconfigured and showing "12:00" for the past three days, I'm betting it knows the seconds since boot anyways. Having an clock that can return meaningful durations is a useful thing, even if it cannot return "correct" time.
> * software cannot depend on this date being earlier than the value returned by
> now() when run in a non-constexpr setting, because either the build
> environment or the runtime one may be misconfigured
Sure. See previous point.
> I also think you can implement a clock using DATE and TIME because
> the clock is not expected to be accurate.
Sure, you can implement a clock but never changes, and it will be right twice a day on some timezone. But as I said before, the question is whether such a thing is _useful_.
> Since any value it returns is, by
> definition, a correct value, there's no test you can write to say it's invalid.
> So you could implement it by just parsing DATE and TIME; timezones are
> completely irrelevant.
Sure, you could do it. It would be a non-steady clock (which the standard does allow!) but it wouldn't really be a useful clock. If this was a real-world analogy, I'm asking for us to provide people with clocks and your response basically amounts to: "let's print out a picture of a clock and give them that... what do they need a clock for?"
The key point of the C++ standard (or any standard really) is that it provides guarantees that those who build on top of that standard can rely on.
The C++ standard cannot and does not mandate a reliable system clock any more than it mandates, say, what the underlying implementation of `std::random_device` is. All it mandates is certain characteristics. Nothing in this proposal changes those characteristics. But it does aim to deliver concrete and well-defined behavior to solve a specific problem--or rather, what I perceive to be a specific problem; ymmv.
While I agree that we should be clear about what "well-defined" means in this context and should be clear about what `std::chrono::system_clock::now()` does in the context of a constant expression and about the limitations, I don't think we should hollow the proposal out so completely as to basically have it no longer serve a purpose.
Thanks for the feedback.
Nik Bougalis
>
>
> On Thursday, 6 March 2025 14:42:13 Pacific Standard Time Nikolaos D. Bougalis
> wrote:
>
> > People embed timestamps in their programs ALL THE TIME and there are many
> > legitimate reasons to do so (some compilers actually do it automatically
> > for you). They just do it using the preprocessor (via TIME and DATE
> > or TIMESTAMP) or using custom build steps or binary post-processing. I
> > don't think providing a tool to developers that allows them to use modern
> > C++ and the language of std::chrono to achieve those goals is a bad thing.
> >
> > Generally, I think that your criticisms, interpreted more broadly, is
> > severely limiting. I certainly agree that any tool can be misused, but I
> > don't think that, by itself, is a good enough reason to deny use of that
> > tool.
>
>
> I am calling DATE and TIME a misfeature. They should not have been
> added to the language. Therefore, I disagree that we should add a feature that
> "allows modern C++" for them.
I don't know that I agree about them being a "misfeature" and don't care to have that argument, but given your position, I can certainly understand why you'd feel as you do about this proposal. Still, I think it's important that we have conversations which challenge our preconceived notions, and I hope that this can be such a conversation on both sides.
> You're right that people can get timestamps in other ways and embed them into
> the programs. That's fine; but that also means that they can do what you're
> asking for in the same ways. Just use your buildsystem to create the UUIDs,
> for example.
Sure, they can. Just as people can run Microsoft's resource compiler tool to "compile" resources and produce a header file, or they can post-process a compiled binary to insert a timestamp or a version number or what-have-you. But that distracts from the question of whether having the ability to do this in C++ is a useful tool to offer to developers.
> In any case, if withdrawing the paper is not a path you want to pursue, I
> recommend you add to it:
>
> * implementations are encouraged to have a mechanism to configure what time
> point is returned by this function, so as to support reproducible and
> deterministic builds, such as SOURCE_DATE_EPOCH environment variable (link to
> https://reproducible-builds.org/ for more information)
If I were being pedantic, I'd argue that it's possible to just roll back the system clock, and in some ways easier. But I don't think it's a bad idea to encourage implementations to provide such a mechanism.
> * reliability, accuracy, and precision are not guaranteed. Many systems may
> not know their timezone or be synchronised with an atomic clock. Some
Nothing in my proposal should really be construed as mandating an accurate clock anymore than the standard can mandate `std::chrono::system_clock` to be accurate. All my proposal requires is to effectively return a time_point at compile time. I was doing some embedded development the other day and `std::chrono::system_clock` always starts on January 1, 2018 at 00:00:00 when you reset the device, because that's what the microcontroller is configured. I believe that's perfectly compliant with the standard already.
> compilers may choose to tell you that the current time is the source file's
> modification time, which may be stored in a filesystem that does not support
> sub-second time resolution.
I don't think that's a problem, per se, although I think that implementations should make a best effort to return the time as reported by the operating system, which is all the standard really requires for `std::chrono::system_clock` really.
> * software cannot depend on the date returned changing at all. A compliant
> compiler is allowed to return a fixed date, either intentionally or because the
> build environment is misconfigured (e.g., unable to obtain a time after boot -
> my coffee maker has been showing "12:00" for the past 3 days). Therefore,
> software cannot depend on this value to generate unique identifiers because
> they may not be unique at all.
I understand that you are trying to be helpful, and I am trying to read your suggestions with that in mind, but I can't help but feel that you're also trying to water the proposed functionality down to what amounts to homeopathic levels.
As I mentioned before, I don't think the standard can really mandate that a compliant implementation of `std::chrono::system_clock` return an accurate (as in "yep, it's that o-clock right now, plus or minus 97 microseconds!") time anyways, or even that the date changes at all. In fact, because this clock can be adjusted by the operating system at any moment and in effectively any way, such a "clock" would already be standard-compliant in my view. But I don't think we should encourage implementations to do such a thing.
Even if your coffee maker is misconfigured and showing "12:00" for the past three days, I'm betting it knows the seconds since boot anyways. Having an clock that can return meaningful durations is a useful thing, even if it cannot return "correct" time.
> * software cannot depend on this date being earlier than the value returned by
> now() when run in a non-constexpr setting, because either the build
> environment or the runtime one may be misconfigured
Sure. See previous point.
> I also think you can implement a clock using DATE and TIME because
> the clock is not expected to be accurate.
Sure, you can implement a clock but never changes, and it will be right twice a day on some timezone. But as I said before, the question is whether such a thing is _useful_.
> Since any value it returns is, by
> definition, a correct value, there's no test you can write to say it's invalid.
> So you could implement it by just parsing DATE and TIME; timezones are
> completely irrelevant.
Sure, you could do it. It would be a non-steady clock (which the standard does allow!) but it wouldn't really be a useful clock. If this was a real-world analogy, I'm asking for us to provide people with clocks and your response basically amounts to: "let's print out a picture of a clock and give them that... what do they need a clock for?"
The key point of the C++ standard (or any standard really) is that it provides guarantees that those who build on top of that standard can rely on.
The C++ standard cannot and does not mandate a reliable system clock any more than it mandates, say, what the underlying implementation of `std::random_device` is. All it mandates is certain characteristics. Nothing in this proposal changes those characteristics. But it does aim to deliver concrete and well-defined behavior to solve a specific problem--or rather, what I perceive to be a specific problem; ymmv.
While I agree that we should be clear about what "well-defined" means in this context and should be clear about what `std::chrono::system_clock::now()` does in the context of a constant expression and about the limitations, I don't think we should hollow the proposal out so completely as to basically have it no longer serve a purpose.
Thanks for the feedback.
Nik Bougalis
Received on 2025-03-07 00:20:45