fpdf2 icon indicating copy to clipboard operation
fpdf2 copied to clipboard

CreationDate metadata shows wrong timezone offset for UTC

Open stevesimmons opened this issue 1 year ago • 3 comments

Dates such as the PDF metadata's CreationDate have the general format "D:".

The datetime format strings in PDFDate.serialize() (included below) are correct for non-UTC: the timezone is shown as "+01'00'" or "-01'00'" for times ahead/behind of UTC.

However for UTC, the code in PDFDate.serialize() is given on line 318 of fpdf.syntax as f"D:{self.date:%Y%m%d%H%M%SZ%H'%M'}". This incorrectly takes the timestamp's hour and seconds as the timezone.

I think in this UTC case, the serialized date should either finish at the "Z", or have a timezone of "+00'00'". Printing "Z00'00'" for UTC looks wrong (I've only ever seen "Z" terminated strings", and printing "Z15:22" (my current time) looks very wrong indeed.

The incorrect line of fpdf.syntax is here:

class PDFDate:
    ...
    def serialize(self, _security_handler=None, _obj_id=None):
        if self.with_tz:
            assert self.date.tzinfo
            if self.date.tzinfo == timezone.utc:
                out_str = f"D:{self.date:%Y%m%d%H%M%SZ%H'%M'}"   # This should finish at 'Z'                            
                # out_str = f"D:{self.date:%Y%m%d%H%M%SZ}"   # Instead finish at 'Z' like this            
                # out_str = f"D:{self.date:%Y%m%d%H%M%S+00'00'}"   # Or make UTC explicit with "+00'00'"
else:
                out_str = f"D:{self.date:%Y%m%d%H%M%S%z}"   
                out_str = out_str[:-2] + "'" + out_str[-2:] + "'"
        else:
            out_str = f"D:{self.date:%Y%m%d%H%M%S}"

stevesimmons avatar Sep 09 '24 14:09 stevesimmons

Thank you for reporting this bug @stevesimmons 👍

Your analysis seems accurate to me.

Would you like to sumbit a Pull Request in order to fix this?

We already have a unit test for this case in test/metadata/test_set_date.py I guess it should be fixed. FYI, we have some documentation on how to regenerate reference PDF files used in unit tests there: https://py-pdf.github.io/fpdf2/Development.html#assert_pdf_equal-writing-new-tests

Lucas-C avatar Sep 09 '24 17:09 Lucas-C

@allcontributors please add @stevesimmons for bug

Lucas-C avatar Sep 09 '24 17:09 Lucas-C

@Lucas-C

I've put up a pull request to add @stevesimmons! :tada:

allcontributors[bot] avatar Sep 09 '24 17:09 allcontributors[bot]

Hi @stevesimmons,

I noticed that the issue regarding the incorrect timezone offset for the CreationDate metadata (#1261) is marked as open, and I wanted to check if it has been fixed in any recent updates.

If it's still open, I would love to contribute to this issue. Could you provide any guidance on how best to proceed or if there are any existing discussions I should review?

Thank you!

Shenile avatar Oct 17 '24 11:10 Shenile

I noticed that the issue regarding the incorrect timezone offset for the CreationDate metadata (#1261) is marked as open, and I wanted to check if it has been fixed in any recent updates.

Yes, this issue is still open!

If it's still open, I would love to contribute to this issue. Could you provide any guidance on how best to proceed or if there are any existing discussions I should review?

Great, you are welcome! Are you planning to contribute as part of Hacktoberfest?

A starting point would be to read this page: https://py-pdf.github.io/fpdf2/Development.html

Then you could fork this repository, create a dedicated branch (say issue-1261), fix PDFDate.serialize() in fpdf/syntax.py and run the unit tests. test/metadata/test_set_date.py should then fail, and you will have to regenerate the associated reference PDF file. Once you have done that, you can add a mention of this fix in CHANGELOG.md and create a Pull Request from your branch!

Lucas-C avatar Oct 17 '24 11:10 Lucas-C

I noticed that the issue regarding the incorrect timezone offset for the CreationDate metadata (#1261) is marked as open, and I wanted to check if it has been fixed in any recent updates.

Yes, this issue is still open!

If it's still open, I would love to contribute to this issue. Could you provide any guidance on how best to proceed or if there are any existing discussions I should review?

Great, you are welcome! Are you planning to contribute as part of Hacktoberfest?

Yes, I am planning to contribute as part of Hacktoberfest!

A starting point would be to read this page: https://py-pdf.github.io/fpdf2/Development.html

Then you could fork this repository, create a dedicated branch (say issue-1261), fix PDFDate.serialize() in fpdf/syntax.py and run the unit tests. test/metadata/test_set_date.py should then fail, and you will have to regenerate the associated reference PDF file. Once you have done that, you can add a mention of this fix in CHANGELOG.md and create a Pull Request from your branch!

I created a branch named issue-1261, fixed the PDFDate.serialize() method in fpdf/syntax.py, and ran the unit tests. As expected, the test in test/metadata/test_set_date.py failed, so I regenerated the associated reference PDF file. I also added a mention of this fix in CHANGELOG.md.

I’ve submitted the pull request and look forward to your feedback!

Shenile avatar Oct 18 '24 11:10 Shenile

PR #1290 has been merged to fix that.

While the fix has not been released in a new version published on Pypi, you can test that it works for you using:

pip install git+https://github.com/py-pdf/fpdf2.git@master

Lucas-C avatar Nov 21 '24 12:11 Lucas-C

This fixup has been included in the new release published today: https://github.com/py-pdf/fpdf2/releases/tag/2.8.2

Lucas-C avatar Dec 16 '24 12:12 Lucas-C