Consider adding native support for SOURCE_DATE_EPOCH to %Y copyright placeholder

[jayaddison]

In a recent bugthread at lmfit/uncertainties#312, a project is considering switching from a copyright config value that contains an em-dash en-dash to one that instead uses a simple ASCII hyphen -- in order to enable Sphinx's copyright substitution logic, that in turn supports reproducible builds.

I had momentarily suggested that the project could instead begin using the %Y placeholder in their copyright confval -- a feature added in Sphinx v8.1.0 -- hoping that this change alone would solve their problems.

However: I had forgotten that the %Y placeholder does not natively support the SOURCE_DATE_EPOCH reproducible build timestamp environment variable.

In other words: it's possible to use %Y in combination with the existing substitution logic -- but the limitations of the latter (e.g. em-dash will not pattern-match) continue to apply.

I wonder whether we could/should enable SOURCE_DATE_EPOCH natively when string-replacing the %Y value -- in preference to the system clock year that we currently use unconditionally -- when that env var is configured.

Edit: en-dash, not em-dash - thank you, @wshanks.

[wshanks]

Minor correction -- the Uncertainties case is regarding switching from en dash to hyphen, not em dash to hyphen. I mention this because the Wikipedia entry for en dash lists "to connect symmetric items, such as the two ends of a range" as the first use case.

[AA-Turner]

If %Y doesn't support SOURCE_DATE_EPOCH, that's an oversight. I had thought it did though, but I might be misremembering.

[jayaddison]

I thought so too, but it seems not at the moment. Perhaps there could have been some unusual interaction between it and the subsequent substitution logic that meant it's problematic?