I consider it a given that the macros C++ inherits from C: __DATE__ and __TIME__ are not intrinsically evil nor dangerous to use.

Can these macros be used to make evil code? Of course they can. What can’t. The real question is: are they useful?

I posit that the answer is yes. But they have fundamental problem: The time zone they are computed in is known only to the compiler, and not published. Therefore __DATE__ and __TIME__ do not really represent an instant in time. If they had been specified to be UTC, then they would represent an instant in time, and be more useful.

This proposal fixes the problem this problem with __DATE__ and __TIME__. system_clock is UTC (Unix Time to be precise), at run time or at (the proposed) compile time. And there is no other portable method to get the compile time in UTC.

If one could portably get UTC from __DATE__ and __TIME__, then it would be simple to just build a user-defined chrono clock around that and use it. But we can’t.

Nik’s paper contains motivating use cases for needing the time at compile time. I don’t see any arguments refuting those motivations. And I have not seen calls in the last 40 years to never use __DATE__ and __TIME__ because of:

> Please make your software reproducible: it should be bitwise exactly identical
> if it is compiled by the same compiler.


If __DATE__ and __TIME__ were designed today, it would look like Nik’s proposal.

Howard

On Mar 6, 2025, at 5:16 PM, Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> czw., 6 mar 2025 o 23:00 Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>> On Thursday, 6 March 2025 13:43:47 Pacific Standard Time Nikolaos D. Bougalis
>> via Std-Proposals wrote:
>>> In looking, it seems to me that making std::chrono::system_clock usable in
>>> constexpr contexts is pretty simple and invokes marking one function as
>>> constexpr: now.
>>
>> Please don't. Your software should not depend on the time it was compiled at
>> and should not change depending on that.
>>
>> std::chrono::system_clock::time_point now = {};
>> if (!std::is_constant_evaluated()))
>> now = std::chrono::system_clock::now();
>>
>>> Less exotic use cases include the ability to generate time-based UUIDs at
>>> compile time, to seed random number generators at compile time, potentially
>>> warn when old code is compiled (not that there's anything wrong with that!)
>>
>> Please make your software reproducible: it should be bitwise exactly identical
>> if it is compiled by the same compiler.
>>
>
> Isn't this even worse? could this cause ODR violations?
> As same inline function depend on time and two TU process it
> a couple of seconds apart, now both TU will have code generated
> differently.
>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals