Short answer is. No!
No way, ever!

If time stamps at the time of compilation is what you want, compilers already have mechanisms (albeit not standard) for that that doesn't touch a feature of the language.
It's usage may not be so wide spread because... well, nobody wants to do that.

There's no way that something that gives a different result every single time it's called should be constexpr.

End of discussion.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]socpp.org> on behalf of Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, March 6, 2025 10:43:47 PM
To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
Cc: Nikolaos D. Bougalis <nikb_at_[hidden]>
Subject: [std-proposals] constexpr support for std::chrono::system_clock

Hello everyone,

I've been doing a lot of constexpr-related stuff lately, and one of the things that I needed but didn't really have access to was a Clock​.

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

Obviously, there's a little more to it than this, in the sense that it will require some additional support by the compiler that the standard library implementers can use to get the current time.

Adding this functionality would give programmers an actual usable clock at compile time, that uses the already familiar language of std::chrono​ and enable (indeed, make trivial!) a number of use cases, some of which are currently impossible, including the timing the compilation of constexpr code to identify potential bottlenecks.

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!)

This is my first solo proposal, and I'd be very interested in hearing what everyone thinks.

Best regards,

Nik Bougalis