I'm working on a fairly large application and am running into a serious problem with DatePicker and time zones. When data is saved to the server a full datetime string is sent like so: ExpirationDate: "2014-10-17T04:00:00.000Z". This gets materialized on my WebApi service in UTC format.
This cases many problems.
1. If I am storing the results in the database as a Date field (without the time) any comparison to the existing value fails. "2014-10-17" == "2014-10-17T04:00:00.000Z" always fails. This means I have to convert to local time on the server and drop the time.
2. If I am storing the results as a datetime2 field in the database then again, I have to jump through the same conversion to drop the time.
All I am interested in is the date.
Having a full timestamp for DateTimePicker makes sense, yes. But for DatePicker it seems odd that I should have to convert the values to a flat date when that's what I'm expecting to begin with. Or at least not be able to configure the DatePicker to work only with date formats. I have a lot of view model classes to deal with and no time at the moment to create properties that 'wrap' this behavior.
This cases many problems.
1. If I am storing the results in the database as a Date field (without the time) any comparison to the existing value fails. "2014-10-17" == "2014-10-17T04:00:00.000Z" always fails. This means I have to convert to local time on the server and drop the time.
2. If I am storing the results as a datetime2 field in the database then again, I have to jump through the same conversion to drop the time.
All I am interested in is the date.
Having a full timestamp for DateTimePicker makes sense, yes. But for DatePicker it seems odd that I should have to convert the values to a flat date when that's what I'm expecting to begin with. Or at least not be able to configure the DatePicker to work only with date formats. I have a lot of view model classes to deal with and no time at the moment to create properties that 'wrap' this behavior.
2 Answers, 1 is accepted
0
Bryan
Top achievements
Rank 1
Rank 1
answered on 02 Oct 2014, 04:42 PM
My mistake. This seems to happen when using Grid editing based on DataType.Date fields. Seems like the data is stored as a javascript Date. Not sure how to get around this.
0
Bryan
Top achievements
Rank 1
Rank 1
answered on 02 Oct 2014, 05:20 PM
Hey all, quick update. My issue is related to javascript Dates, which always have a timezone offset. Wish I could edit or move this post since it doesn't really belong here. So for others out there encountering timezone problems and you want to remove them before being sent back to the web service give this a try:
Use the parameterMap function on the data source. Add code similar to this, which effectively removes the timezone offset and sends the datetime in local (undefined) format by removing the trailing 'Z'.
if (options.models) {
$(options.models).each(function () {
if (typeof this !== 'object')
return;
for(var field in this){
var data = this[field];
if (Object.prototype.toString.call(data) === '[object Date]') {
this[field] = new Date(data.valueOf() - data.getTimezoneOffset() * 60000).toJSON().substring(0, 23);
}
}
});
Use the parameterMap function on the data source. Add code similar to this, which effectively removes the timezone offset and sends the datetime in local (undefined) format by removing the trailing 'Z'.
if (options.models) {
$(options.models).each(function () {
if (typeof this !== 'object')
return;
for(var field in this){
var data = this[field];
if (Object.prototype.toString.call(data) === '[object Date]') {
this[field] = new Date(data.valueOf() - data.getTimezoneOffset() * 60000).toJSON().substring(0, 23);
}
}
});