On Fri, 7 Mar 2025, 00:20 Nikolaos D. Bougalis via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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


Er, no. You don't want to change the clock for the whole system just to get
a single compilation to use a different reported "time". If you change the
system clock you will affect the file timestamps of the compiler output,
and might be unable to login or use cryptographic certificates that rely on
dates. It also requires root access. I should be able to have two different
users building software without both of them needing to globally alter the
entire system's clock!


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

I think Thiago's suggestions are good. It should be clear that a compile
time clock has even weaker requirements than at runtime.



>
>