You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Lionel Lindemann <li...@proliber.com> on 2001/05/28 18:33:22 UTC
RFC822DateFormat() problem
Hello,
Since installing james version 1.2.1, I have encountered the following minor
problems :
* 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
* 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.
Re: RFC822DateFormat() problem
Posted by Harmeet <ha...@kodemuse.com>.
----- Original Message -----
From: "Harmeet" <ha...@kodemuse.com>
> As per the API <getRawOffset> does not account for timezone.
Errata: <getRawOffset> does not accout for daylight saving as Lionel wrote.
/**
* Gets unmodified offset, NOT modified in case of daylight savings.
* This is the offset to add *to* UTC to get local time.
* @return the unmodified offset to add *to* UTC to get local time.
*/
abstract public int getRawOffset();
Harmeet
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: RFC822DateFormat() problem
Posted by Administrateur des sites Proliber <ca...@proliber.com>.
>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
Re: RFC822DateFormat() problem
Posted by Harmeet <ha...@kodemuse.com>.
[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