[ 
https://issues.apache.org/jira/browse/WICKET-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973044#action_12973044
 ] 

Andera Del Bene commented on WICKET-3249:
-----------------------------------------

Well, what you said is right but as Martin Grigorov  pointed out DateTimeField 
uses "new StyleDateConverter(false)" so  it shouldn't apply the timezone 
difference.

Anyway, in the same test method dateField value is 'Sat Nov 06 23:00:00 CET' 
when we would expect ''Sat Nov 06 08:00:00 CET''. These 23 hours seem a wrong 
value. 
As I said before I think that this could be due to a problem in method 
convertToObject of class DataConverter.
The patch I've attached solve this problem using code suggested here: 
http://joda-time.sourceforge.net/userguide.html#Changing_TimeZone 

Bye.

> DateConverter improperly converts time, causing different results between 
> DateField and DateTimeField
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-3249
>                 URL: https://issues.apache.org/jira/browse/WICKET-3249
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-datetime
>    Affects Versions: 1.4.6
>            Reporter: Tauren Mills
>            Priority: Minor
>         Attachments: DatePickerTest.java, fix-WICKET-DateConverter.patch, 
> TestDateConverter.java
>
>
> With a DateTimeField and a DateField in a wicket form, submit the following:
> DateTimeField:     [   11/06/2010  ] date,  [ 0 ] hour,  [ 0 ] min
> DateField:              [   11/06/2010  ] date
> Those should result in the same value. But look at the converted Date values, 
> and you'll see this:
> dateTimeField:   2010-11-06T07:00:00Z
> dateField:  2010-11-06T23:00:00Z
> The dateTimeField value is what I'd expect - the UTC value of midnight in my 
> timezone on 11/6/2010.  It look like dateField is just wrong and that 
> DateConverter isn't dealing with timezone conversions properly. Here's the 
> scenario:
> * Server OS, Java, and Database are all configured to use UTC timezone.
> * Web client is configured in America/Los_Angeles timezone (currently 
> UTC-08:00, or PST).
> * Currently logged in member has profile configured to use 
> America/Los_Angeles timezone.
> * Application WebClientInfo has timezone set from the user's profile, like 
> such:
>               ClientInfo ci = Session.get().getClientInfo();
>               
> ((WebClientInfo)ci).getProperties().setTimeZone(TimeZone.getTimeZone(member.getTimezone()));
> Anywhere that dates are handled in the application with DateLabel or 
> DateTimeField, they seem to be properly converted by Wicket to and from 
> America/Los_Angeles time to UTC time for storage in the database. Examining 
> the database shows a 7 or 8 hour difference between the time in the UI and 
> the time in the database (depending on DST or not).
> However, when using org.apache.wicket.extensions.yui.calendar.DateField, 
> dates are getting converted/persisted incorrectly. I just traced through 
> DateConverter.convertToObject() to see what was happening. Assume it is 
> currently 2010-12-10 00:43 PST(-8). My client timezone is set to PST (-8), as 
> is my profile timezone. I specify 2010-11-06 in the DateField. It does this:
> 1. Creates a Joda value using DateMidnight right now in UTC (the date/time 
> right now in UTC, setting the time portion to midnight UTC. This will be a 
> time before now, not after now, as midnight is the first instant of a day, 
> not the last instant of a day). 2010-12-10T00:00:00Z
> 2. Converts this Joda value to the client's timezone.  
> 2010-12-09T16:00:00-08:00
> 3. Joda parses the submitted text value into the Joda value.  
> 2010-11-06T16:00:00-07:00
> 4. Converts the Joda value to the server's timezone.  2010-11-06T23:00:00Z
> The value should result in 2010-11-06T07:00:00Z, which converts to 
> 2010-11-06T00:00:00-08:00, or midnight on 11/6 in the PST timezone, but it 
> doesn't. Or am I missing something and there is a reason for this? It seems 
> like a bug to me.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to