Add PHP_BUILD_DATE constant

[cmb69]

This information can be occasionally useful, and would otherwise need to be parsed from phpinfo() output.

However, maybe more importantly we unify the build date between what is given by php -v and php -i, since these compilation units are not necessarily preprocessed within the same second.

---

This came up in #16560. While I don't mind a new PHP_BUILD_DATE constant, for me it's more important to unify the dates.

Note that I'm not sure if the format is standardized; I believe so, though. The test will show.

[bukka]

Isn’t this going to be problematic for reproducible builds?

[cmb69]

Isn’t this going to be problematic for reproducible builds?

Well, we have this anyway (not the constant, but using __DATE__ and __TIME__). Either we drop that altogether, or we maybe we want to make it configurable.

[bukka]

So I have done a little bit checking and it's actually fine as both clang (16+) and gcc (7+) will set __DATE__ and __TIME__ macros from SOURCE_DATE_EPOCH env var during the build. There were actually issues in past where those two were problematic (before the SOURCE_DATE_EPOCH support in compilers) but it should be all good now.

[bukka]

The reason why I mentioned it before is that if DATE and TIME were not safe for repro builds, then it wouldn't be a good idea to expose it as user space constant. But that's not the case so all good. :)

[vrubleg]

Is there any good reason why it's a string in such inconvenient format instead of a unix timestamp that you could directly use with date()?

[cmb69]

It's what compilers give us. You can use strtotime() or such to parse it.