views:

205

answers:

1

Hi there,

I've got a WCF service which receives records with datetime values, and saves them to an Azure SQL db, using Entity Framework 3.5, SP1. Running it locally, the records get saved to the database, all is well

However, my IIS hosting is in a different timezone. When I upload the site to there and call the same service (with the exact same connection string, to the Azure SQL db), the records still get saved, but the time has moved back 5 hours.

I've checked Fiddler, to watch the data going out, and it's in my local time. I've used the same service inside Azure hosting, and that saved fine too. I've got the same data going to another WCF service on the same host being saved with Linq2SQL, and that saves fine.

The only difference then is Entity Framework - I'm guessing that my timezone information (GMT) is sent with the datetime, and so when the server in Eastern Seaboard time receives it, it converts it to the local time, 5 hours earlier.

In a way, this is accurate, because at the moment (13:48), it is 5 hours earler - 08:48, but that's not what I want it to save to the database, I want it to save 13:48. Like I asked it to, so it makes sense when I query it

This is probably really simple, and everyone else knows the answer, but I am a little puzzled. I'd really appreciate it if someone could point me in the right direction.

many thanks

Toby

+2  A: 

You could try changing the DateTimeKind on the client side value to Unspecified. That way WCF and the Entity Framework won't have enough information to try and be clever about converting it.

DateTime.SpecifyKind
DateTimeKind


Following up on this not working and your comment in the question...

Firstly, what are you trying to do - do you want the values stored in the database to be in the client's timezone - in your case UK time - or do you want it to be stored in UTC? In my experience the best solution is to save it as UTC otherwise you will really confuse things if you have multiple clients in different timezones.

Assuming you do want to store it as UTC then you need to convert it to UTC on the client side before passing it over the network (DateTime.ToUniversalTime) you then need to make sure that the server recognizes it as UTC (it should do this automatically, but you may want to call SpecifyKind after receiving it just to be sure). The Entity Framework should then store this in the database unaltered - as you describe in your comment.

Now the trick is to realise that the time you get back to the client when you retrieve the data will be in UTC. So when UK time no longer lines up with UTC it will appear wrong. So, make sure you call DateTime.ToLocalTime on any values you get back from the server before displaying them to the user.

At least that's the approach I would take.

(Oh, and as a fellow UK developer I find it really useful to set the time on my client PC to anything but UK time when doing this kind of work - otherwise you'll introduce bugs that you won't pick up on until we shift over to BST. In my experience this tends to happen after you've gone live)

Martin Harris
cheers - I'll give that a go now ...
TobyEvans
nope - that didn't make a difference, using any of the settings. I set the DateTimeKind to Unspecified, UTC and Local - it always saved it as the local time. To make sure that I was using the code I thought I was (and not a cached version), I wrapped the date conversion into a Helper method that also created a new date out of the old one, and changed whether I wanted milliseconds or not:Thanks, but not the answer unfortunately ...
TobyEvans
Hi - yep that explains it nicely. I'll have to think about just dates (to represent whole days/months/years) though - they need to stay the same, and I don't want them slipping back an hour to the previous day/month during BST. cheers
TobyEvans