What do you think about applying the client time zone to the date parser? By
doing so java.util.Date and MutableDateTime can come along nicely.
Attila
----------%<----------%<----------%<----------
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
1053997)
+++
wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
(working
copy)
@@ -18,7 +18,6 @@
import java.text.DateFormat;
import java.text.ParseException;
-import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.Locale;
@@ -363,7 +362,20 @@
{
log.error(">>> convertDateNew()");
// This is what I get from field.getConvertedInput()
- Date dateFieldInput = (dateStr != null ?
DateFormat.getDateInstance().parse(dateStr) : null);
+ Date dateFieldInput;
+ if (dateStr != null)
+ {
+ DateFormat dateFormat = DateFormat.getDateInstance();
+ if (tzClient != null)
+ {
+ dateFormat.setTimeZone(tzClient);
+ }
+ dateFieldInput = dateFormat.parse(dateStr);
+ }
+ else
+ {
+ dateFieldInput = null;
+ }
// Default with "now"
if (dateFieldInput == null)
@@ -371,18 +383,12 @@
dateFieldInput = new Date();
}
- // 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,
+ MutableDateTime date = new MutableDateTime(dateFieldInput,
DateTimeZone.forTimeZone(tzClient));
+ if (minutes != null)
+ {
+ date.set(DateTimeFieldType.minuteOfHour(), minutes);
+ }
// Use the input to create a date object. Ignore the timezone provided by
dateFieldInput and
// use tzClient instead. No re-calculation will happen. It should be the
same as above.
@@ -398,7 +404,11 @@
date.set(DateTimeFieldType.halfdayOfDay(), halfday);
date.set(DateTimeFieldType.hourOfDay(), hours % 12);
}
- log.error("2. halfday adjustments: " + date.getMillis() + " " + date);
+ else if (hours != null)
+ {
+ date.set(DateTimeFieldType.hourOfDay(), hours % 24);
+ }
+ log.error("2. hours/halfday adjustments: " + date.getMillis() + " " +
date);
Date rtn = new Date(date.getMillis());
log.error("3. final date: " + rtn.getTime() + " " + rtn);
----------%<----------%<----------%<----------
2010/12/30 Juergen Donnerstag <[email protected]>
> tested it. Don't think it's true. Joda considers the timezones and
> recalculates.
>
> -Juergen
>
> On Thu, Dec 30, 2010 at 2:12 PM, Attila Király
> <[email protected]> wrote:
> > 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."
> >
>
--
"I would rather write programs to write programs than write programs."
