On Friday, Sep 5, 2003, at 02:42 Europe/London, Dain Sundstrom wrote:
I fixed it. In MailDateFormatTest, you are parsing a date into a Date object and then loading it into a Calendar to test that the parse was correct. The problem is when you create the Date object you lose you time zone information, so when you create the Calendar it creates it in the machine timezone. I'd bet you are in BST so it worked for you, but in any other timezone it fails. I change the test to explicitly set the timezone on the new Calendar.
| had a nasty feeling that timezones may be the issue. Don't you just love unit (and international) testing that catches these glitches before they go live :-)
Well done.
I was personally surprised at workings of Calendar. I suggest when ever we do Calendar tests we put the timezone somewhere in the middle of the Pacific Ocean.
Yeah, good plan. What about -0300 as a time zone -- does that exist anywhere? Or, alternatively, -0330, because timezones don't always have to be on the hour boundary ...
Alex.
If I'm not mistaken,
-0300 is Greenland and most of Brazil, and
-0330 is Newfoundland, Canada's easternmost province,
but
-1100 covers the Pacific Ocean just west of Hawaii and I don't think the International Date Line comes into play.
-0200 might be useful, just nips the east coast of Brazil and squeezes between Iceland and Greenland
