I saw the new build passes on Hudson. I think MutableDateTime date = new MutableDateTime(dateFieldinput, DateTimeZone.forTimeZone(tzClient)); should have the same effect as the below seen block because the timezone part of java.util.Date is not used by joda.
+ // Get year, month and day ignoring any timezone of the Date object + Calendar cal = Calendar.getInstance(); + cal.setTime(dateFieldInput); + int year = cal.get(Calendar.YEAR); + int month = cal.get(Calendar.MONTH) + 1; + int day = cal.get(Calendar.DAY_OF_MONTH); + int iHours = (hours == null ? 0 : hours % 24); + int iMins = (minutes == null ? 0 : minutes); + + // Use the input to create a date object with proper timezone + MutableDateTime date = new MutableDateTime(year, month, day, iHours, iMins, 0, 0, + DateTimeZone.forTimeZone(tzClient)); Attila Király 2010/12/29 Juergen Donnerstag <[email protected]> > though you are right in what you are saying about joda caching the > timezone, I don't think it is the root cause. > > Looking at the logs everything is fine until step 4 (actually 5) when > the hour is set based on the input provided. It is set to 0 which is > what I provided. The problem is that the timezone of the mutable date > is not yet set. The timezone should be, as you suggested, be set when > the mutable date is created. > > =========== testDates1() ================= > >>> convertDate() > 1. dateFieldInput: 1288998000000 Sat Nov 06 00:00:00 CET 2010 > 2. mutable date: 1288998000000 2010-11-05T19:00:00.000-04:00 > 3. secs = 0: 1288998000000 2010-11-05T19:00:00.000-04:00 > 4. AM/PM: 1288998000000 2010-11-05T19:00:00.000-04:00 > 4. hours: 1288929600000 2010-11-05T00:00:00.000-04:00 > > -Juergen > > > On Wed, Dec 29, 2010 at 9:40 PM, Attila Király > <[email protected]> wrote: > > Guess I could not send an attached file. I am putting the patch here. > Sorry > > for the noise. > > > > ---------------------%<----------------------%<--------------------- > > Index: > > > wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java > > =================================================================== > > --- > > > wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java > > (revision > > 1053723) > > +++ > > > wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java > > (working > > copy) > > @@ -134,6 +134,43 @@ > > } > > > > /** > > + * Tests joda & jvm default time zone handling > > + */ > > + public void testJodaTimeDefaultTimeZone() > > + { > > + TimeZone origJvmDef = TimeZone.getDefault(); > > + DateTimeZone origJodaDef = DateTimeZone.getDefault(); > > + > > + // lets find a timezone different from current default > > + String newId = null; > > + for (String id : TimeZone.getAvailableIDs()) > > + { > > + if (!id.equals(origJvmDef.getID())) > > + { > > + newId = id; > > + break; > > + } > > + } > > + > > + assertNotNull(newId); > > + > > + TimeZone.setDefault(TimeZone.getTimeZone(newId)); > > + > > + TimeZone newJvmDef = TimeZone.getDefault(); > > + DateTimeZone newJodaDef = DateTimeZone.getDefault(); > > + > > + // if this fails we are under security manager > > + // and we have no right to set default timezone > > + assertNotSame(origJvmDef, newJvmDef); > > + > > + // this should be true because joda caches the > > + // default timezone and even for the first > > + // lookup it uses a System property if possible > > + // for more info see org.joda.time.DateTimeZone.getDefault() > > + assertSame(origJodaDef, newJodaDef); > > + } > > + > > + /** > > * > > * @throws ParseException > > */ > > > > ---------------------%<----------------------%<--------------------- > > > > Attila Király > > > -- "I would rather write programs to write programs than write programs."
