I think I’ve identified the main reason why you’re seeing this behavior and if I am correct you will only see this if you build with the UBA executor.
I can see some changes to UBA detour where it also now detours the `_time64` function. It returns 0 if the rules apply to the current program which includes the linker.
You can see this code was added for 5.8 in UBA detour. This would mean that the linker would get 0 time value instead of the expected real system time and be none the wiser. It also explains why we don’t see changes in the arguments being passed, it’s the detour dll doing the, detour for _time64.
__time64_t Detoured__time64(__time64_t* destTime)
{
DETOURED_CALL(_time64);
if (g_rules->Time64AlwaysReturnZero())
{
if (destTime)
*destTime = 0;
return 0;
}
return True__time64(destTime);
}
Given the comment in the CL, this was done with motivation to make builds deterministic. The side effect is the binary timestamp is also 0.
P4 change comment CL 52463492.
```
[UBA]
* Added option for time64 to always return 0 and changed so for cvtres.exe it always return 0. This to make output obj file be determinstic (there are no options to do it from the outside)
```
To fix this you would need to change the g_rule so it returns false, or remove the code and rebuilt `UbaDetour` which is done via UBT. There is a helper batch file to do this (which also add the -nouba args): “Engine\Source\Programs\UnrealBuildAccelerator\Deploy-Windows.bat”.
Hmm, I need to figure out how to handle this so timestamp can be added when desired. The reason I had to fix this uba side was because there was no option to disable it from command line causing our build caches to constantly store new dlls since they had a few bytes different holding the timestamp.