What you really want to do is throw away all your code for trying to deal specially with timezones. The framework already handles your use case - date and time information is conveyed unambiguously between client and server, and setDefaultDisplayTimezone allows you to configure all client-side UI components to use a specific timezone for display and input.
If you want to continue with your current (unnecessary) approach, the only way to influence JSON serialization to do what you want is to simply convert the embedded Date instances to your own desired String format *before* you ask for JSON serialization, in which case they will remain unchanged.
But we highly recommend getting rid of your unnecessary custom date/time handling instead.
Announcement
Collapse
No announcement yet.
X
-
Is there anyway I can control the JSON format for the Between filter operator to only have the Date as the stored value?
Reason I ask because it causes problems with timezones for our particular application. I will attempt to explain...
Users in our system are defined to be in a specific TimeZone. So for example Joe can be defined to be in Central TZ and Jane can be defined to be in Pacific TZ. (Not my preference but the legacy application supports this)
To handle this we send all the Dates to the server as String (yyyy-MM-dd) so that no timezone information is contained and hence a Date is the same Date regardless of what timezone the user or browser is in. For DateTimes we send Date objects back/forth but we format/parse all our DateTimes to show TimeZone so that there is never any ambiguity w/r to the DateTime and we always display the DateTime in the User's specified TimeZone.
So a DateTime of say 2014-07-01 at 11:00 Central is stored in UTC as 2014-07-01 16:00:00. When this DateTime is displayed in the UI for Joe, he will see "2014-07-01 11:00:00 -0500" regardless of the browser timezone, so even if Joe is on a system in Pacific TimeZone, he will still see his DateTimes in Central Time) and Jane will see "2014-07-01 09:00:00 -0700" (again regardless of browser TimeZone)
This is all working fine and dandy until we come to filtering. The Date field filtering is working OK except for the Between since the Between is adding the Time information. Soon as Time information is added, TimeZone comes into play.
The TimeZone being used to set the time value for a Date Between criteria appears to be using our User's timezone probably due to our parsing/formatting which is ok (Joe's Between filter shows T05:00 and Jane's filter shows T07:00 on between date filters).
However, I am seeing very strange behaviour when the user and their system are different timezones. Seems like the browser timezone is coming into play somehow. Jane who is say on an Eastern TimeZone system, sets a between Date to say July 31 & Dec 31 and when the filter is loaded up in the FilterBuilder, the filter shows 2 different dates of Jan 1 on the input field and Jan 2 on the display/label field (see attached image) where the filter has the value of:
Code:{ "_constructor":"AdvancedCriteria", "operator":"and", "criteria":[ { "operator":"iBetweenInclusive", "fieldName":"tdate", "start":"2014-07-31T07:00:00.000", "end":"2015-01-01T07:59:59.999" } ] }
Code:{ "_constructor":"AdvancedCriteria", "operator":"and", "criteria":[ { "operator":"iBetweenInclusive", "fieldName":"tdate", "start":"2014-07-31T05:00:00.000", "end":"2015-01-01T05:59:59.999" } ] }
When using the Smart GWT server framework, "date" values are automatically transmitted with year, month and day preserved and time value ignored.
When sent or received in XML or JSON, date field values should be serialized in the XML Schema date format - YYYY-MM-DD - are expected to be received in the same format. Any time value present for a "date" field is ignored.
Thanks.
Leave a comment:
-
Yeah, we saw that, but we first had to clear up the confusion about not following your "defined" format (and course know where this string was from!).
Leave a comment:
-
Which is what I asked at the very beginning about the times.
"Is this because the Between is wanting to set the start of day and end of day of the two dates respectively?"
Leave a comment:
-
So again, the formatters you install on DateUtil affect user-visible values only and would not be expected to affect JSON serialization.
The values shown for betweenInclusive are as expected - this is how we generate criteria that meets the user's expectation of what it means to pick dates between a given day and another: that it should include everything from the beginning of the first day to the end of the second.
Leave a comment:
-
It is persisted as a string via:
Code:AdvancedCriteria criteria = filterBuilder.getCriteria(); String filter = criteria.toJSON();
Leave a comment:
-
That didn't actually answer the question - how was this particular JSON serialization obtained?
Leave a comment:
-
Sorry, this is the saved Filter criteria created by the FilterBuilder.
We allow creation and saving of different filters via the FilterBuilder and this is the saved filter for each type of filter operation we allow. (see attached image)Last edited by stonebranch1; 23 May 2014, 14:55.
Leave a comment:
-
What are we looking at here? Server logs? RestDataSource capture? JSONEncoder serialization?
Note that none of the above representations would be affected by settings on DateUtil, if that's what you were expecting. DateUtil settings affect only values shown to end users.
Leave a comment:
-
AdvancedCriteria Date format inconsistent.
In testing out my filtering using Date fields (you previously addressed an issue with parsing/formatting of DateTime for me http://forums.smartclient.com/showthread.php?t=30218) I found one case where the stored value is not adhering to my format. When I use the between operator it is storing the dates in the ISO 8601 format rather than my defined format.
Code:"criteria":[ { "fieldName":"tdate", "operator":"equals", "value":"2014-10-13" }, { "operator":"iBetweenInclusive", "fieldName":"tdate", "start":"2014-12-01T05:00:00.000", "end":"2015-01-01T04:59:59.999" }, { "fieldName":"tdate", "operator":"notEqual", "value":"2014-05-31" }, { "fieldName":"tdate", "operator":"lessThan", "value":"2016-05-01" }, { "fieldName":"tdate", "operator":"lessOrEqual", "value":"2015-06-04" }, { "fieldName":"tdate", "operator":"greaterThan", "value":"2014-05-01" }, { "fieldName":"tdate", "operator":"greaterOrEqual", "value":"2014-05-13" }, { "operator":"isNull", "fieldName":"tdate" }, { "operator":"notNull", "fieldName":"tdate" } ]
Tags: None
Leave a comment: