On Fri, Sep 20, 2024 at 09:09:33PM +0100, Gavin Smith wrote: > > SOURCE_DATE_EPOCH would give the user a chance to override the value > and is a standard variable that users might be familiar with, unlike > any other variable or option that we might invent.
To me SOURCE_DATE_EPOCH is for reproducible builds and should not be used for publication dates, this is very different. > I really don't see what is wrong with using the current date for > dcterms:modified by default. Hardly anyone is going to notice or > care that it does not correspond to the last date that the manual > sources were modified. If we use the current date, the dcterms:modified, in theory, should never be set in the past of the current date for the same publication identifier. The current specification https://www.w3.org/TR/epub-33/#sec-metadata-last-modified refers to the previous specification that explains the difference between the Unique Identifier, which does not change with each minor revision and the Release Identifier https://www.w3.org/publishing/epub32/epub-packages.html#sec-metadata-elem-identifiers-pid It is said, in particular "The sequential, chronological order inherent in the format of the timestamp also places EPUB Publications in order without requiring knowledge of the exact identifier that came before." The Release Identifier became the dcterms:modified metadata. I wanted to avoid such an irreversible setting automatically. That's why I preferred the automatic setting to be conditional to having the EPUB_STRICT customization variable set, until dcterms:modified/the publication date can be set explicitely. > However, people will notice and have noticed EPUB standard-noncompliance > and epubcheck failures. With EPUB_STRICT, dcterms:modified is automatically set, it should allow to have compliance without forcing to set a dcterms:modified value automatically. -- Pat
