[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    RE: RFC822DateFormat() problem
From:       "Administrateur des sites Proliber" <catchall () proliber ! com>
Date:       2001-05-29 9:40:15
[Download RAW message or body]

>In the code I have the diff seems to be
>-df = new SimpleDateFormat("EE, d MMM yyyy HH:mm:ss",Locale.US);
>+df = new SimpleDateFormat("EE, d MMM yyyy HH:mm:ss", Locale.ENGLISH);

Well, I'm using the latest release build, not the latest nightly build, so
this means it it has been fixed. In the release build, the code was :

df = new SimpleDateFormat("EE, d MMM yyyy HH:mm:ss");

Locale.US is stronger than Locale.ENGLISH. Locale.US is probably better,
btw.

Sorry, I should have checked the CVS. I'm not very accustomed to that.


For the second question, I'll leave it to the experts populating this list
;-)

Lionel

-----Original Message-----
From: Harmeet [mailto:harmeet@kodemuse.com]
Sent: Tuesday, May 29, 2001 6:19 AM
To: james-dev@jakarta.apache.org
Subject: Re: RFC822DateFormat() problem


[Lionel Lindemann]
> * p1: On a non-English system, the date string sent by the
> RFC822DateFormat() method was in the system language, resulting in an
error
> in the SMTP Date field

In the code I have the diff seems to be
-df = new SimpleDateFormat("EE, d MMM yyyy HH:mm:ss",Locale.US);
+df = new SimpleDateFormat("EE, d MMM yyyy HH:mm:ss", Locale.ENGLISH);

Do you see the same diff between your Code and James Code ?
Both Local.US and Local.ENGLISH seem to have the same language 'en', not
sure why the bug goes away.

[Lionel Lindemann]
> * p2: On a NT/2000 system, the time was not taking into account daylight
> savings. I guess this was also a problem on other systems, but I couldn't
> check.
>
> Attached is a modification proposition to the code, which aims to clear
> those two problems. I am not an expert in Java, nor in the James
> architecture, so please do check it carefully.

The Diff is.
-int min = TimeZone.getDefault().getRawOffset() / 1000 / 60;
+// p2: Used ZONE_OFFSET + DST_OFFSET instead of getRawOffset() to take into
account daylight savings
+GregorianCalendar rightNow = new GregorianCalendar();
+int min = (rightNow.get(rightNow.ZONE_OFFSET) +
rightNow.get(rightNow.DST_OFFSET)) / 1000 / 60;

As per the API <getRawOffset> does not account for timezone. Seems to be a
good fix to me. One nitpick though. The <min> calculation seems to be static
in nature. Do you think it would be a correct and better thing to move
calculation of <min> and the offset sting calculation to a  static
constructor ?

Harmeet


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]