[BUG] incorrect timestamps applied to metadata in content.opf

[Hasimir]

When the metadata is generated for the content.opf file in a new EPUB (either EPUB 2.0 or 3.0) the date and time stamp needs to be in UTC (aka Zulu time). Sometimes the dc:date element only contains the date component without the timestamp and that's usually fine, but normally both the dc:date and the meta dcterms:modified element use the full datetime in ISO standard format. With the dc:date remaining unchanged and always set to the original file generation date or date and time, while the dcterms:modified date and time is updated with each change to the EPUB; Like this: 2016-06-02T05:25:39Z.

The problem is that the transformation scenario is not actually using UTC when writing the timestamp, it's using the system's local time and just changing the timezone field to say "Z" in order to match the format the epubchecker validator will try to match.

For systems configured to use UTC all the time, this is not a problem and it is a reduced issue for those running the plugin who live behind the international dateline (i.e. the Americas) as the mismatch will just make it appear that a newly generated file is a few hours old. For people east of England and west of the international dateline (i.e. most of Europe, Africa, the Middle East and the entirety of asia and Australasia) the result is that files appear to have been made in the future. Though the IDPF validator does not currently check the timestamps, it is possible that it may do this at some point in the future and create unnecessary validation failures.

In the past this limitation has been caused by a reliance on XSLT 1.0. An example of which is visible in Accessible EPUB 3.

Here in Melbourne this means that EPUBs would appear to have been created 10 hours in the future (or 11 hours during daylight savings time). This is not optimal for situations where that timestamp might be relevant for ascertaining content ownership or if the validator is updated to to actually check the time(s) saved into the file.

The preferred solution would be to replace the current function used with XSLT 1.0 to one that leverages either XSLT 2.0 or 3.0. Otherwise the only options for a platform independent solution are directly in Java or to use another interpreted language that has been designed for the JVM; such as Jython or Scala.

[Hasimir]

The test project created for #69 includes a demonstration of this error as it includes a generated EPUB 3 file with a detached GPG signature file. The GPG signature can show that the file could not possibly have been created at the timestamp it uses ... well, not without breaking a 4096-bit RSA and 512-bit SHA2.

To verify the signature on the file, my key is: 0x321E4E2373590E5D

It can also be found in many of my github projects, on the MIT keyserver and the SKS keyserver pool.

[drmacro]

I see the problem. Will investigate.

[drmacro]

Hasimir says:

As mentioned on dita-users the previous fix to convert localtime to UTC is an odd half-fix. Specifically the time conversion does correctly calculate the difference between the system time which the OT runs on and UTC, including adjusting the date where necessary. However the time is only ever recorded as a 12 hour clock and not a 24 hour clock. So any UTC time between 13:00Z and 23:59Z loses 12 hours.

I am not certain what happens with 00:00Z since I haven't run a transformation at exactly that time. I'm also not certain if this is an issue with XSLT or Java itself. It is, however, less of a worry than the situation prior to the half-fix since it does at least prevent the generation of a timestamp in the future from the point of the transformation which was previously the case for those of us ahead of UTC (i.e. from Europe to Asia and Oceania). It is also not picked up by epubcheck.

[Hasimir]

Fix tested with OT 1.8.5 and works as expected.