On Thursday, 6 March 2025 16:20:33 Pacific Standard Time Nikolaos D. Bougalis
> But that distracts from the question of whether having the ability to do
> this in C++ is a useful tool to offer to developers.

Indeed, but I feel that the use-cases for it are too narrow and misleading,
while the fall out could be big.

> > * 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.

Indeed, and for strict reproduceability, it might be necessary to LD_PRELOAD a
module that overrides gettimeofday() and clock_gettime(), in case the
buildsystem is creating the time string or value to supply to the compilation.


> > * 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.

Right. I was just being thorough. This point was to support the fact that you
can just parse __DATE__ and __TIME__, because it's going to give you a value
that is as correct as any.

> > * 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.

It wasn't the intention when I wrote the bullet points. But I did realise that
was the outcome when I finished the email.

Either way, the fact is that software cannot depend on the uniqueness or
monotonicity of the value returned by this function, unless the developer
controls the environment in question (compiler vendor and version, OS, boot
sequence, etc.). Therefore, I do suggest you water down your use-case of
unique IDs. Don't suggest in any way that they are unique; instead, you can
suggest that they are better than nothing, to be used as a fallback in case a
better solution isn't available at runtime.

> 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.

That's the steady_clock but you aren't suggesting we use it.

> > 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_.

That was not the point here. My point is that you can get a reasonably-close
current time_point using __DATE__ and __TIME__, in spite of those not
including the timezone. Assuming the OS's date is correct in the first place,
the result of this will be correct to within -12h/+14h30.

> 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?"

My argument is that it's *as* useful as the expected implementation of
returning the system_clock::now() at the time the compiler evaluated the
expression or, more likely, at the time that the compiler created __DATE__ and
__TIME__.

> 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.

But they can't rely on anything here! That's my whole point: given that
environments can be misconfigured and given that reproduceability will exist
allowing the compilers to lie, the value that the function returns may bear no
resemblance to reality.

And it's not unreasonable to have an implementation that, by default, provides
a fixed date. For example, for some industries due to regulation, software
developers may be required to provide attestation through reproduceability. So
I could see companies targeting the medical industry (such as Green Hills)
simply deciding that midnight on May 20, 1875 is a correct date. That would
make it both perfectly reproducible and also reveal where it attempted to
violate this requirement by saying it's been 150 years since it was compiled.

> 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.

Right. And you're not proposing a constexpr std::random_device (yet, anyway).

I understand that you're not calling for a change of the characteristics. But
I am calling into question at least one of the motivations, because it relies
on those very characteristics having changed.

> 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.

I think the proposal text should be clear on the limitations. Even if that
portion of the proposal does not end up in the standard text itself, the
proposal will be read by compiler implementors and other software developers,
which may inform them on what to do and not do.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering