Would an alternative be to provide the conversion to system_clock from
of __DATE__ and __TIME__ in a compile-time manner? Compilers that use
local time for __DATE__ and __TIME__ also know their offset from UTC.
The part that is missing is communicating this information to the language.

I appreciate that __DATE__ and __TIME__ are C macros which C++ adopts,
rather than C++ outright, so this may not be the right place to propose
a __TIMEZONE__ macro. However, an alternative that would lie within
C++'s remit would be a compile_time_clock that is required to provide:

     full constexpr usage, including now(),
     time_points that are equivalent to __DATE__and __TIME__, and
     the ability to cast its time_points to system_clock's / utc_clock's
via clock_cast.

Those who need reproducibility can achieve it without any extra work, as
the existing approaches for __DATE__ and __TIME__ would be directly
passed on to compile_time_clock.

Stewart

On 07/03/2025 01:58, Howard Hinnant via Std-Proposals wrote:
> If we could change the C++ standard to say that __DATE__ and __TIME__ are UTC, then the user could write this clock themselves. And that user-written clock could even return a system_clock::time_point.
>
> On macOS __DATE__ and __TIME__ are in the local time zone. And that blows a user-written clock out of the water unless the user can somehow inject the current local UTC offset into the build system.
>
> The advantage of basing it to on a UTC __DATE__ and __TIME__ is that the existing infrastructure for manipulating __DATE__ and __TIME__ remains and could manipulate this chrono::time_point.
>
> Howard
>