It isn't, but I'm also not advocating for the usage of __TIME__, __DATE__
Just pointing out that the solution is not fit for the suggested purpose, i.e. getting the build time.
If it is fit, it has undesirable consequences.
I.e better solution found elsewhere.

________________________________
From: Tom Honermann <tom_at_[hidden]>
Sent: Monday, March 10, 2025 11:59:26 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

On 3/10/25 5:16 AM, Tiago Freire via Std-Proposals wrote:
Ps. Now that I think about it, what happens to build cache? What if now() is generated by the compiler does it mean that every single source file needs to be rebuild every single time (because it could change at every time you compile it)?
When you build it again it is technically a new build time, right?

How is that different from the status quo given the existence of __TIME__, __DATE__, and __FILE__ (for relocatable builds)?

Tom.

From: Tiago Freire <tmiguelf_at_[hidden]><mailto:tmiguelf_at_[hidden]>
Sent: Monday, March 10, 2025 10:13 AM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]><mailto:wittmeier_at_[hidden]>
Subject: RE: [std-proposals] constexpr support for std::chrono::system_clock

This is how I think it should ideally work:
1. Generate that as a pre-compilation stage.
2. The compiler receives those as a constant that never changes during the compilation process, even across different TUs.
Preferably Tooling, not compiler features. Agreement between what ALL compilation units see, not just what 1 unit sees. Consistent regardless of compiler vendor.
Implying that a constexpr now() (if it exists) would always give the same result no matter when and how it is used in a translation unit, probably set externally (so that all TUs can agree) which leads to the conclusion that the compilation time is generated in a previous stage outside the compiler, not by the compiler.


From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Monday, March 10, 2025 9:52 AM
To: std-proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock


Let's have some use cases:



I want to print the date and time my program was compiled.

I want to have a modern time zone aware C++ interface.

I want the printout be formatted (processed) at compile time.



What changes in the proposal would make this possible without going into problems with

 - non-reproducible constexpr: We need just one point of time for the program (what about multiple TU? Each TU gets its own now() 'instance'?)

 - reproducible builds: compiler flags?
-----Ursprüngliche Nachricht-----
Von: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Gesendet: Mo 10.03.2025 08:35
Betreff: RE: [std-proposals] constexpr support for std::chrono::system_clock
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>;

I would expect not to have to think about if the conditional branching is decided when the function is evaluated or if a decision needs to be taken every single time it is called in a constexpr context.

I don’t want to have to think about if my conditions hold true or change based on whatever else the compiler decided it has done before somewhere else unrelated.

I don’t want to think what conditionally evaluated branch was active before and that it could be different now, and what does that mean at runtime vs compile time.



While __TIME__ has the benefit of at least being an in-place replacement at pre-processing stages, now() would not be that.

And while “std::source_location” is concerning, it has at least some sort of consistency that can be reasoned about.

This breaks everything.

Think of template expansion, think of unevaluated branches, think of how many more rules you would need to enforce in order for different compiler vendors to produce consistent results when asked (a <= b).

And then realize that the motivation for this can be done with much better results if you don’t touch the compiler.

Non-deterministic constexpr functions are evil, they are a terrible idea. Please don’t do this.





From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Monday, March 10, 2025 12:05 AM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock



What do you expect?



Even if it is valid, it would not be functional.



As was pointed out, constexpr functions are not necessarily evaluated in any order.



So it makes no sense to measure a time duration.



So even if now() changes its value, the second now() could be evaluated before the first.



Or possibly the compiler could cache the value from a previous compilation run and use the cached value for either or both.



As now() is not constexpr at the current standard, the code could be made valid or not.



It probably would only make sense, if now() always returns the same value for each translation unit. Any other result would tempt to make time measurements.





-----Ursprüngliche Nachricht-----
Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Mo 10.03.2025 00:02
Betreff: Re: [std-proposals] constexpr support for std::chrono::system_clock
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>;

I thought that I needed to make a decision before presenting 1 of 2 types of gadgets that broke things in different ways, but after thinking about it.





extern uint32_t g0;

constexpr auto g1 = now();



constexpr uint32_t foo(uint32_t var)

{

  if constexpr ( now() - g1 > nanoseconds(3) )

 {

return var + 1;

 }

else

{

 return var - 1;

}

}



uint32_t const g2 = foo(g0);



Is this valid?













________________________________

From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Sunday, March 9, 2025 4:30:57 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Lénárd Szolnoki <cpp_at_[hidden]<mailto:cpp_at_[hidden]>>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock




On 7 March 2025 01:14:17 GMT, Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>>> In looking, it seems to me that making
>>> std::chrono::system_clockusable in
>>> constexpr contexts is pretty simple and invokes marking one function as
>>> constexpr: now.
>>
>> Please don't.
>
>+1

+1

This is an ODR footgun among other concerns about reproducible builds. The following is instant ODR violation, if appears in multiple TUs and the clock is not faked:

inline constexpr auto x = std::chrono::system_clock::now();

>
>Also this strikes me as a good way to violate ODR.
>
>Cheers,
>Jeremy
>
>On Mar 6 2025, at 4:00 pm, Thiago Macieira via Std-Proposals
><std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>
>> 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_clockusable 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.
>>
>> --
>> 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]<mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
 Std-Proposals mailing list
 Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals