You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Tim Allison (Jira)" <mi...@james.apache.org> on 2021/12/01 17:21:00 UTC

[jira] [Created] (MIME4J-312) Slight change in date parsing in 0.8.6?

Tim Allison created MIME4J-312:
----------------------------------

             Summary: 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


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.



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