#780 [PDF] incorrect timestamp calculation when writing PDF metadata

[bughunter2]

When writing a PDF, the CreationDate and ModDate timestamp fields contain the wrong timestamps.

GraphicsMagick is taking the local time and applying a timezone correction to it. So the timezone correction is effectively applied twice.

Proof:

$ gm convert -size 200x200 xc:blue output.png

$ LC_ALL=C date -u
Mon Oct 12 14:56:03 UTC 2026

$ LC_ALL=C date
Mon Oct 12 16:56:03 CEST 2026

$ gm convert output.png output.pdf

$ pdfinfo output.pdf
Title:           output
Producer:        GraphicsMagick 1.3.45 2024-08-27 Q16 http://www.GraphicsMagick.org/
CreationDate:    Mon Oct 12 18:56:03 2026 CEST
ModDate:         Mon Oct 12 18:56:03 2026 CEST
Custom Metadata: no
Metadata Stream: no
Tagged:          no
UserProperties:  no
Suspects:        no
Form:            none
JavaScript:      no
Pages:           1
Encrypted:       no
Page size:       200 x 200 pts
Page rot:        0
File size:       1326 bytes
Optimized:       no
PDF version:     1.2

Expected behavior:

I would have expected the PDF metadata to contain the Mon Oct 12 16:56:03 2026 CEST timestamp instead.

Note that the Atril Document Viewer also shows the problematic timestamps in the PDF metadata.
So it appears that it's really a bug in GraphicsMagick, rather than elsewhere.

[Bob Friesenhahn]

I have replicated your issue. If one opens the PDF and looks at its text, one can see that the CreationDate and ModDate are similar to "D:20261012133504" and the time zone is not specified.

Use 'pdfinfo -rawdates output.pdf' to see the unmodified dates.

It seems that pdfinfo (I have 26.01.0) is assuming that unmarked dates are UTC and is converting to the local time zone. This is in spite of Google's AI overview saying that pdfinfo uses raw date information (no time zone information) literally. Google says that many PDF viewers assume that unmarked dates are in the local time zone.

My personal preference would be to store the timestamp in UTC and mark it as such, and next after that would be to use local time and add a time zone offset from UTC (e.g. +HH:MM or -HH:MM) at the end of the string. The reason why UTC is preferable is that all modern computer clocks use UTC and it is independent of location. However, converting to and from local time requires that the computer time be set properly and that the computer knows its current time zone.

The latest ImageMagick is still doing the same thing that GraphicsMagick does.

[Bob Friesenhahn]

To summarize, what you are seeing is produced/invented by recent pdfinfo. Add the -rawdates option to see the actual data from the file.

[Bob Friesenhahn]

Google AI says:

The preferred and most complete form for a PDF CreationDate (and other PDF date fields) is the local time accompanied by its time zone offset from UTC.
The formal PDF specification (ISO 32000-1) defines the syntax as follows:
D:YYYYMMDDHHmmSSOHH'mm'
Where:
• D: is the required prefix.
• YYYYMMDDHHmmSS represents the local year, month, day, hour, minute, and second.
• O is the relationship indicator to Universal Time (UTC), which can be +, -, or Z.
• HH'mm' is the absolute value of the offset in hours and minutes

It is suggested to use strftime() with the %z format specifier. I am not sure how portable this is.

[bughunter2]

Both Adobe Reader and Mozilla Firefox assume that the timestamp is in UTC and convert it to local time, causing the wrong timestamp to show (too far into the future).

MS Edge takes another approach, showing the same value as pdfinfo -rawdates, which is (in the original example), this value: D:20261012165603.

[Bob Friesenhahn]

This issue is addressed by Mercurial changeset 18190:3273551fd0f7 "coders/pdf.c (WritePDFImage): Use strftime() to format PDF dates, including the time zone offset from UTC." and the code will appear in today's development snapshot build.

Thank you very much for reporting the issue!

[bughunter2]

No worries, thanks!