I have a big timezone problem!

[pkfgimpy]

Hi,

I've released a product that utilizes a webservice that recieves a DateTime object as one of its input parameters.

I've only just recently found out that the DateTimes submitted to the webservice from users in other time zones is being changed based on the difference between the server timezone and the users time zone.

For instance, a user at 8:30 Atlantic Time ends up being stored in my database as 5:30 Mountain Time. I need it to be stored in my DB as 8:30, not 5:30.

I figured there would be a simple means to retrieve the TimeZone information from the DateTime object, but alas, this does not appear to be the case. As far as I can tell, I have no access to the timezone that the DateTime object was originally created in.

The timezone information is passed within the outgoing SOAP message. .NET automatically handles the serialization/deserialization of the timezone and modifies the DateTime object that my server recieves... it doesn't give me any chance to handle this.

I can fix this problem by updating the client code, but I'd prefer not to do that as I will have to issue a patch. I would much prefer handling this problem in my web service code.

Does anyone know if this is possible? Do I have access to the TimeZone information of the DateTime object that my WebService recieves?

Thanks.

[Athley]

I'm not sure this could be done entirely on the webservice side. If you take a look at the DateTime.Kind Property in the help you'll see what DataTime can work with. The way I read it is that you at least has to use the SpecifyKind() method on the client side to set it to universal time, and the convert it back to local in the webservice.

Try and see what result you get if you use the ToUniversalTime() method on the DateTime object in the webservice. If it always is the UCT (London time) you should be almost home safe. From there you could add or subtract the number of hours from where your based.

Maybe someone else has other suggestions?

/Leyan

[exterminator]

If you have no idea what timezone the webservice has been called from is, then probably the system is doing the right thing. It is converting the datetime to what is correct from its frame of reference and not from some other frame of reference that you don't have any idea about. Regards.

[pkfgimpy]

I understand what its doing, and it makes sense, it just seems kind of odd that .NET would make these adjustments automatically and then disregard the timezone information entirely.

Anyway, I've found a temporary solution for the problem. In the end though, I think I'm going to have to update the client.

Thanks for the advice.

[Andy Tacker]

Well, that's really a strange thing. Basically, when you are considering that the timestamp should be the local server time, than you should not get the datetime stamp from client. you should set the datetime as current server datetime prior to adding the data...

In this way, you would be free of certain overheads. and now if you need to display the datetime according to the client's datetime settings, you can consider coverting the server date time to UTC and displaying it in accordance with client's GMT.

simple? Enjoy @ CG.

[nabeelisnabeel]

The simplest solution for this problem I found is given below...

1- Before sending your data to webservice convert DateTime into Ticks.
2- On webservice end recieve LONG instead of DateTime.
3- Store this LONG ticks in database.
4- Whenever you will fethc this LONG ticks from database and send to client via webservice, you will convert Ticks into DateTime on cleitn end , and this way you will get exactly yhe time you need.

This constructor will help you....
DateTime obj = new DateTime(Long ticks);