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.
Ok, that's seem right. I was considering calendar like if it was given by an external user. Apparently you got the point.
Regards, Guilhem.
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
