please file an ICLA per [1] and i'll apply the patch; thanks

[1] http://www.apache.org/licenses/icla.txt

Hi Robert, Glenn,

ICLA has been received by the Apache Secretary: http://people.apache.org/committer-index.html

Thanks,

Chris

Hi Glenn, Chris,

I was just about to post the fact I received the e-mail, but Chris just got there before me. Please let me know if there is anything else you need from me.

Best Regards,

Robert Meyer

(In reply to comment #3)
> Hi Glenn, Chris,
> 
> I was just about to post the fact I received the e-mail, but Chris just got
> there before me. Please let me know if there is anything else you need from
> me.
> 
> Best Regards,
> 
> Robert Meyer

test testDateFormattingISO8601 fails in the second assert below

String s = XMPSchemaAdapter.formatISO8601Date(dt, TimeZone.getTimeZone("GMT"));
assertEquals("2008-02-07T15:11:07Z", s);
assertEquals(dt, DateFormatUtil.parseISO8601Date(s));

with the following output

Testcase: testDateFormattingISO8601 took 0.01 sec
        FAILED
expected:<Thu Feb 07 07:11:07 PST 2008> but was:<Thu Feb 07 15:11:07 PST 2008>
junit.framework.AssertionFailedError: expected:<Thu Feb 07 07:11:07 PST 2008> but was:<Thu Feb 07 15:11:07 PST 2008>
        at org.apache.xmlgraphics.util.DateFormatUtilTestCase.testDateFormattingISO8601(DateFormatUtilTestCase.java:45)

i am running on MacOS X 10.6.8 and my current time zone is -8:00 (US/PDT)

I am running the build on my home Windows machine and am getting failing tests also, whereas the code was written, compiled and successfully passed the test suite on my work Linux PC. I have spent several hours on it this evening but have failed to identify and resolve the issue. I initially suspected that it was because the date being formatted in the string wasn't including the offset, but am still getting failing tests even with numerous changes and consulting the existing code. I will resume my investigation once I get back in the office which due to the bank holiday will now be Tuesday.

Try changing line 144 of DateFormatUtil.java from:
String dateFormat = (date.contains("Z")) ? "'Z'" : "Z";
to
String dateFormat = (date.contains("Z")) ? "+0000" : "Z";

I suppose that contrary to Linux, Mac and Windows systems assume local time when no time zone information is present in the date to parse.

HTH,
Vincent

(In reply to comment #6)
Sorry, managed to confuse myself. The pattern should always have a "Z" (unquoted), and the date to parse should be modified if it contains a 'Z'. In formatDateToParse:

if (date.contains("Z")) {
    date = date.replace("Z", "+0000");
} else {
    /* the current code */
}

Something like that.

Vincent

Created attachment 28742 [details]
Fix for existing patch code failing on Junit test

Thanks Vincent. After reading your first comment I came up with a near identical solution to your second comment and have now submitted this against the patch.

I have now changed the bug state bakc to NEW from NEEDINFO

patch applied at http://svn.apache.org/viewvc?rev=1336053&view=rev

thanks Robert! please verify and close this bug if satisfied

(In reply to comment #8)
> Created attachment 28742 [details]
> Fix for existing patch code failing on Junit test
> 
> Thanks Vincent. After reading your first comment I came up with a near
> identical solution to your second comment and have now submitted this
> against the patch.

possible problem: ISO/IEC 32000:2008 Section 7.9.4 (aka PDF 1.7) specifies

A date shall be a text string of the form

(D:YYYYMMDDHHmmSSOHH'mm)

note that there is no delimiter after the mm field of the GMT offset; i notice your code adds a delimiter

Hi Glenn,

The code I submitted has not changed the output from the existing method as that also included a delimiter after the date:

    //Taken from PDFInfo.java in FOP

    protected String formatDateTime(Date time, TimeZone tz) {
        ...
            sb.append(Integer.toString(offsetMinutes));
            sb.append('\'');
        ...
    }


Reading Luis's comment on the existing patch I put submitted:

"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...."

After talking to Vincent, he suggested that FOP follows PDF specification 1.4, but I am certainly willing to change the patch to meet the latest specification if required.

(In reply to comment #12)
> After talking to Vincent, he suggested that FOP follows PDF specification
> 1.4, but I am certainly willing to change the patch to meet the latest
> specification if required.

Note that there is a new option config (see [1]):
  renderer[@mime="application/pdf"]/version

This should be taken into account if format is version dependent.

[1] http://xmlgraphics.apache.org/fop/trunk/configuration.html#pdf-renderer

> Note that there is a new option config (see [1]):
>   renderer[@mime="application/pdf"]/version
> 
> This should be taken into account if format is version dependent.
> 
> [1] http://xmlgraphics.apache.org/fop/trunk/configuration.html#pdf-renderer

I agree with what you are both saying and it would be beneficial to implement such a change in the future. I will open a new ticket for this as I feel the current patch has fulfilled its original purpose.

I have verified the code and will now close the issue. A new ticket (53208) been created relating to support for PDF Reference 1.7.

(In reply to comment #15)
> I have verified the code and will now close the issue. A new ticket (53208)
> been created relating to support for PDF Reference 1.7.

sounds good