ASP.NET AJAX Date serialization and timezones

[=?Utf-8?B?U3R1?=]

I have a ASP.NET Ajax app (using client library) calling ASP.NET Ajax-enabled
web services. We are making use of the javascript proxies generated by
ASP.NET Ajax.

The problem we have is that the UTC dates sent by the browser are being
adjusted for timezones by the server, but we do not want dates adjusted for
timezones.

For example, the user enters the date of a transaction as '25 May 2007'.
That ends up as a javascript Date() instance represented as 'Fri May 25
00:00:00 UTC+0100 2007'. This seems fine. But when it ends up in the web
service code, the 1 hour has been subtracted and the date has become
{24/05/2007 23:00:00}. We are not insterested in the time, only the date, and
the date is now wrong.

Is there a way in javascript to get rid of the timezone information from the
date instance? Or is there a way to configure the JSON
serialisation/deserialisation to ignore the timezone? I have hundreds of
objects in the system that use dates, so ideally I want to be able to solve
this "in one place" - custom processing of each date property sends shivers
down my spine.

I'd be grateful for any help!

Stu

[Walter Wang [MSFT]]

Hi Stu,

I've carefully reviewed your question and I'm currently consulting your
question within our internal discussion list. In the meanwhile, would you
please elaborate more on how can I reproduce the issue on my side? I'm
interested in the detailed setup or steps on your side. Thanks.
Sincerely,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?U3R1?=]

Hi Walter,

My Date and Time settings:
Current timezone: GMT Standard Time
Auto adjust for daylight savings: true

My regional settings are:
Standards and fomats: English (United Kingdom)
Location: United Kingdom

To repro this:
- Set your regional and date time settings as above.
- Setup an ASP.NET AJAX web service with a web method that accepts a
DateTime parameter
- Put a breakpoint inside that method.
- Reference that web service from an ASP.NET AJAX web form.
- In client JavaScript for the web form create a variable to hold a date:
var myDate = new Date(2007, 5 - 1, 29); // months are zero-based
- add a "debugger;" statement directly after this variable assignment.
- After the debugger statement, setup a call to the web service passing
myDate as the parameter.
- Run the page in Debug mode and invoke your javascript.
- When it breaks in the javascript, inspect myDate and observe that its
string representation is "Tue May 29 00:00:00 UTC+0100 2007".
- Continue execution
- When it breaks in the web service, observe that the the value of the date
parameter has been reduced by one hour: 28/05/2007 23:00:00
- in the immediate window invoke .ToLocalTime() on the date parameter.
Observe that the date is restored to the orginal 29/05/2007 00:00:00.

There are actually two issues here:
1. This is all on my dev machine - so why on earth does my browser report
UTC+1 and my web service just UTC?
2. Regardless of my machine discrepancy, in production we will have users
all over the world. When they enter a date into a form I can't have the dates
being adjusted for timezone differences.

I notice that there are attributes to constrain XML Serialization of a
DateTime to only use the Date part. Is there anything similar for JSON
serialization?
I do not want to perform .ToLocalTime() in all web services in the system,
as we are bound to miss something - and these dates are crucial.

Is there any elegant way to make sure that a DateTime instance on the server
will always have the same actual date and time values as the original
JavaScript Date() instance?

Let me know if you need any more information.

Many thanks

Stu

[Walter Wang [MSFT]]

Hi Stu,

Thank you very much for your detailed repro steps. I can now clearly see
the issue you described.

I hope I've understood your objective correctly: your objective is to get
client-side date part on server-side so that you can use it to generate
some string representation and return it back to client.

I think this is unfortunately not possible if you're transferring a
DateTime type parameter, this is because only a UTC datetime gets
transferred and the client-side timezone information is not transferred to
server.

Nikhil Kothari has once discussed how the Date gets serialized in JSON:

#Nikhil Kothari's Weblog : Wishful Thinking - Date Literal Syntax for JSON
http://www.nikhilk.net/DateSyntaxForJSON.aspx

#Nikhil Kothari's Weblog : JSON Serialization of Dates (Take 2)
http://www.nikhilk.net/DateSyntaxForJSON2.aspx

So far I'm not aware of any way to customize how ASP.NET AJAX library
serializes/deserializes JSON objects. I'm afraid you will have to pass the
year/month/day parts separately to the server if you want to generate a
string representation based on these information.
Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Walter Wang [MSFT]]

Hi Stu,

Have you seen my last reply?

I understand you may have some concerns with this issue, you're welcome to
submit your feedback at
http://connect.microsoft.com/Main/co...ContentID=2220 which
is monitored by our product team. Thank you for your understanding.
Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?U3R1?=]

Hi Walter,

Thanks for looking into this and sorry for my late reply (I have been on
holiday).

I understand why the code works like it does for date+time combinations.
However, my requirement is to work with a date only (regardless of the the
time), and I believe this is such a common scenario that it is really
unacceptable to use the work around of using strings instead of DateTime
fields.

If I have an Employee class with a Birthday property, I would want to use a
Date type (I'm not interested in the time). However, the big problem is that
the .NET framework does not have a native Date type. So, I use DateTime type.
I don't want to use strings because I want to take advantage of strong typing
and I don't want to lose the date-related services provided by the DateTime
class.

If it was just a one off case of Employee.Birthd ay then a workaround
wouldn't seem so bad. But I have hundreds of Dates in my application! For
that reason I also don't want to implement an additional Timezone parameter
for each date property.

There are only two solutions that I think would be acceptable:

a) provide a Date type in the framework (I realise this would be a huge
change - but really useful)

b) somewhere in the ASP.NET Ajax framework provide a way of flagging a
DateTime property on a server class so that when the object is sent back to
the server the framework doesn't change the date part due to timezone
transformation. Surely this can't be too difficult.

An attribute would be perfect, e.g.

[IgnoreTime]
public DateTime IssueDate
{
get { ... }
set { ... }
}

The Ajax framework is great, I just really hope someone can find a way to
support this scenario without reverting to strings or timezone parameters.

Many thanks for your help so far,

Stu

[Walter Wang [MSFT]]

Hi Stu,

I fully understand your concern on this question. Your feedback on the
DateTime data type is great. Please feel free to submit them on our connect
site: http://connect.microsoft.com/Main/co...ContentID=2220

For now, the best workaround would have to be storing the client-side
timezone information of each user on the server separately. For example,
many forum software will have a timezone information in every user's
profile and this will help the server to better format the date in the
forum.

You could either store this timezone information in Session or using
ASP.NET 2.0 Profile and update it whenever a user login. On the
server-side, when a DateTime variable is passed from client to server,
server-side code can first determine if the DateTime is a UTC time and
convert it back to a local time using the user's client-side timezone
information.

You can use following class to help you convert the UTC time to a local
time using a specified timezone since DateTime.ToLoca lTime() always uses
server-side timezone information.

#.Net Zone: Convert local time to Timezone.
http://staceyw.spaces. live.com/blog/cns!F4A38E96E59 8161E!931.entry

I understand this answer still not a perfect one for your scenario since
you're already having many existing code using DateTime information.
However, based on my research so far, the client-side JSON serialization
seems always using the UTC format to pass the client-side Date object to
the server. Creating a customized JavaScriptConve rter for the DateTime
class can only affect the way of how server passes back a DateTime and not
vice versa.

Regards,
Walter Wang (wa****@online. microsoft.com, remove 'online.')
Microsoft Online Community Support

=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?U3R1?=]

Walter, thanks very much for your help on this.

I will certainly provide feedback to the connect site.

Thanks again

Stu