Created attachment 28605 [details] A diff file of the changes When performing automatic tests of the PDF output and using diff, having the dates swap between UST and DST caused these tests to fail due to the differing date sizes in each generated file. At present a Z would be added for Universal, while a +hh'mm' would be added for DST. After studying the specification, in order to keep the size of dates constant it is acceptable to replace the Z with a +00:00 which results in the same date, but maintains file sizes regardless of when the tests are run. Due to duplications in date code between the FOP and XGC proects, both have been moved to a single utility class in the XGC project. The code has also been tidied up.
Dear rmeyer, Thanks for your contribution. ISO/IEC 32000-1:2008 (aka PDF1.7) [1] Section 7.9.4 states: <quote> Date values used in a PDF shall conform to a standard date format, which closely follows that of the international standard ASN.1 (Abstract Syntax Notation One), defined in ISO/IEC 8824. A date shall be a text string of the form: (D:YYYYMMDDHHmmSSOHH'mm) where: YYYY shall be the year MM shall be the month (01–12) DD shall be the day (01–31) HH shall be the hour (00–23) mm shall be the minute (00–59) SS shall be the second (00–59) O shall be the relationship of local time to Universal Time (UT), and shall be denoted by one of the characters PLUS SIGN (U+002B) (+), HYPHEN-MINUS (U+002D) (-), or LATIN CAPITAL LETTER Z (U+005A) (Z) (see below) HH followed by APOSTROPHE (U+0027) (') shall be the absolute value of the offset from UT in hours (00–23) mm shall be the absolute value of the offset from UT in minutes (00–59) The prefix D: shall be present, the year field (YYYY) shall be present and all other fields may be present but only if all of their preceding fields are also present. The APOSTROPHE following the hour offset field (HH) shall only be present if the HH field is present. The minute offset field (mm) shall only be present if the APOSTROPHE following the hour offset field (HH) is present. The default values for MM and DD shall be both 01; all other numerical fields shall default to zero values.A PLUS SIGN as the value of the O field signifies that local time is later than UT, a HYPHEN-MINUS signifies that local time is earlier than UT, and the LATIN CAPITAL LETTER Z signifies that local time is equal to UT. If no UT information is specified, the relationship of the specified time to UT shall be considered to be GMT. </quote> IIUC, you propose to use "+00'00" instead of "Z". I'm wondering if that is consistent with the above language [PLUS SIGN signifies local time is later than UT]. Also, I'm wondering if you couldn't simply use "Z00'00", since this language doesn't exclude this usage. [I'm not sure about interoperability with this approach though.] I also wonder why you place a single quote (apostrophe) after the 'mm field in testDateFormattingPDF(). Finally, we will need a ICLA [2] on file to apply a patch if we can obtain consensus on applying the patch. Regards, Glenn [1] http://www.iso.org/iso/p.24__main_focus.pdf [2] http://www.apache.org/licenses/icla.txt
It is my interpretation also that Z00'00 (or Z00'00') is the right way to do it. The specs are open to interpretation but that is the way I understood it when I read it. I know that Adobe Reader has no problem with it too. Now, regarding the last ' after minutes, the third edition (1.4) spec says it should be there while the 3200-1:2008 says it shouldn't... I had never noticed it until now....
(In reply to comment #2) > It is my interpretation also that Z00'00 (or Z00'00') is the right way to do > it. The specs are open to interpretation but that is the way I understood it > when I read it. I know that Adobe Reader has no problem with it too. I'm checking with Adobe on this point (using Z00'00 instead of +00'00).
(In reply to comment #3) > (In reply to comment #2) > > It is my interpretation also that Z00'00 (or Z00'00') is the right way to do > > it. The specs are open to interpretation but that is the way I understood it > > when I read it. I know that Adobe Reader has no problem with it too. > > I'm checking with Adobe on this point (using Z00'00 instead of +00'00). I posed two questions to Adobe's PDF Architects (and editors of ISO/IEC32000): (1) is it legal to use +00'00 as an alternative for Z (even though it is not "later than UT")? (2) is it legal to use Z00'00 as an alternative for Z (this doesn't seem to be disallowed, though might infer that Z00'01 would be illegal)? Their initial response is as follows: <quote> The specification is intended to be read quite literally. It says that + is used for later (not equal) and – is used for earlier (not equal) and Z is used for equal. Although it only implies it, the Z is not intended to have digits following it. Answer to (1) No. Answer to (2) No, but not so clear in the specification. </quote> This indicates that, despite the intent of this bug report, it would be inadvisable to make the proposed change. I would suggest that the automatic tests you refer to be changed instead in order to account for the difference. If I receive some new information that suggest this bug be re-opened, I will do so; however, in the mean time, I am moving to resolved+wontfix. Thanks rmeyer for proposing the suggested change, even though we will not at present commit it.