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 "Hussein Jafferjee (Jira)" <mi...@james.apache.org> on 2022/07/04 18:15:00 UTC
[jira] [Comment Edited] (MIME4J-312) Slight change in date parsing in 0.8.6?
[ https://issues.apache.org/jira/browse/MIME4J-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17562261#comment-17562261 ]
Hussein Jafferjee edited comment on MIME4J-312 at 7/4/22 6:14 PM:
------------------------------------------------------------------
All of our timezone related tests are failing for the same reason mentioned here.
For example, from the header `Tue, 20 Nov 2012 17:41:03 -0500`, we get a time object at 17:31:03 UTC.
Edit: I think this comment can be safely ignored. I checked out the project and the tests failed on my machine in the same way, but then later realized the new tests do "
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));", which I wasn't doing before (and wasn't required in the old version?)
was (Author: JIRAUSER292243):
All of our timezone related tests are failing for the same reason mentioned here.
For example, from the header `Tue, 20 Nov 2012 17:41:03 -0500`, we get a time object at 17:31:03 UTC.
> 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.10#820010)