[ 
https://issues.apache.org/jira/browse/MIME4J-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Allison updated MIME4J-312:
-------------------------------
    Description: 
Over on Apache Tika, I was recently trying to upgrade from 0.8.4 to 0.8.6.

We used to have a unit test
{noformat}
               //format correctly handled by mime4j if no leading whitespace
                "      Sun, 14 May 2016 20:32:00 EST",
{noformat}
We added special handling to deal with the leading space if mime4j returned a 
null date, and this was a test of our special handling.

In 0.8.6, mime4j is now returning a date (bypassing our special handling), but 
it is ignoring the timezone, and we get "2016-05-14T20:32:00Z".

I'm frankly not sure if the above unit test is valid for the rfc for dates, but 
I can confirm that with or without the leading space, mime4j is now ignoring 
the timezone when not in the format {{+/-hh:mm}}, e.g. EST.

If we remove the comma, we get the correct date: 2016-05-15T01:32:00Z.

{noformat}
               //format correctly handled by mime4j if no leading whitespace
                "      Sun 14 May 2016 20:32:00 EST",
{noformat}

  was:
Over on Apache Tika, I was recently trying to upgrade from 0.8.4 to 0.8.6.

We used to have a unit test
{noformat}
               //format correctly handled by mime4j if no leading whitespace
                "      Sun, 14 May 2016 20:32:00 EST",
{noformat}
We added special handling to deal with the leading space if mime4j returned a 
null date, and this was a test of our special handling.

In 0.8.6, mime4j is now returning a date (bypassing our special handling), but 
it is ignoring the timezone, and we get "2016-05-14T20:32:00Z".

I'm frankly not sure if the above unit test is valid for the rfc for dates, but 
I can confirm that with or without the leading space, mime4j is now ignoring 
the timezone when not in the format {{+/-hh:mm}}, e.g. EST.


> Slight change in date parsing in 0.8.6?
> ---------------------------------------
>
>                 Key: MIME4J-312
>                 URL: https://issues.apache.org/jira/browse/MIME4J-312
>             Project: James Mime4j
>          Issue Type: Improvement
>            Reporter: Tim Allison
>            Priority: Trivial
>
> Over on Apache Tika, I was recently trying to upgrade from 0.8.4 to 0.8.6.
> We used to have a unit test
> {noformat}
>                //format correctly handled by mime4j if no leading whitespace
>                 "      Sun, 14 May 2016 20:32:00 EST",
> {noformat}
> We added special handling to deal with the leading space if mime4j returned a 
> null date, and this was a test of our special handling.
> In 0.8.6, mime4j is now returning a date (bypassing our special handling), 
> but it is ignoring the timezone, and we get "2016-05-14T20:32:00Z".
> I'm frankly not sure if the above unit test is valid for the rfc for dates, 
> but I can confirm that with or without the leading space, mime4j is now 
> ignoring the timezone when not in the format {{+/-hh:mm}}, e.g. EST.
> If we remove the comma, we get the correct date: 2016-05-15T01:32:00Z.
> {noformat}
>                //format correctly handled by mime4j if no leading whitespace
>                 "      Sun 14 May 2016 20:32:00 EST",
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to