This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: FYI: Patch: java.text.SimpleDateFormat

From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
To: Mark Wielaard <mark at klomp dot org>
Cc: Guilhem Lavaux <guilhem at kaffe dot org>,Michael Koch <konqueror at gmx dot de>,java-patches at gcc dot gnu dot org
Date: Sun, 28 Sep 2003 15:57:22 +1200
Subject: Re: FYI: Patch: java.text.SimpleDateFormat

On Sunday, Sep 28, 2003, at 11:04 Pacific/Auckland, Mark Wielaard wrote:

Hi,

On Sat, 2003-09-27 at 22:21, Bryce McKinlay wrote:

Can you give me a pointer to the failing mauve test?


Without the patch the following four mauve tests fail:
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: CDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EST (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: PDT (number 1)

Thanks Mark.

The real problem here is that setTimeZone() was being called on the underlying calendar. This is not necessary since the ZONE_OFFSET field has the same effect, without overwriting the timezone which the user set and "sticking" across a calendar.clear() call. The cloning approach only worked by chance, since it reset the calendar's timezone to GMT which just happened to be what the test case expected.

I'm checking in this patch to libgcj & classpath.

Regards

Bryce.

Attachment: Calendar.patch.txt
Description: Text document

References:
- Re: FYI: Patch: java.text.SimpleDateFormat merge from classpath
  - From: Mark Wielaard

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]