Bug in iso8601_to_pdf_date_string() causes minutes to be dropped from timezone offset
While writing tests for librsvg that involve parsing PDF files created by cairo, I found that the CreationDate in PDF files created by Cairo lacks the minutes in the timezone offset. This is what the CreationDate property looks like:
20200211085039+00'
According to the PDF spec, this is acceptable, because everything after the four-digit year is optional. However the code in cairo doesn't make it look like this is intentional. Instead I think that there's a bug that causes the minutes to be dropped. With this bug fixed the date would become
20200211085039+00'00'
That seems to be more in line with what the PDF spec suggests:
For example, December 23, 1998, at 7:52 PM, U.S. Pacific Standard Time, is represented by the string
D:199812231952-08'00'
Note also that the current output would actually be wrong for timezone offsets with non-zero minutes.
I believe that the current behaviour is a bug in iso8601_to_pdf_date_string
https://gitlab.freedesktop.org/cairo/cairo/blob/master/src/cairo-pdf-interchange.c#L1617 and will open a pull request to fix it.
Actually the PDF spec also strongly recommends that the prefix D:
is included. Cairo currently doesn't do that, but that's another issue.