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.

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.

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)

* reliability, accuracy, and precision are not guaranteed. Many systems may
not know their timezone or be synchronised with an atomic clock. Some
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.

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

* 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


I also think you *can* implement a clock using __DATE__ and __TIME__ because
the clock is not expected to be accurate. 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. However, in the interest of having short compile times,
implementations are encouraged to provide an intrinsic to return this
timestamp in the system clock's epoch.

Moreover, having a compiler intrinsic would allow the preprocessed output to
be stored in a build caching system such as ccache.

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